tkaiser

Members
  • Content count

    4975
  • Joined

  • Last visited


Reputation Activity

  1. Like
    tkaiser got a reaction from gounthar in Is your SD-Card a fake? - check with SD Insight Android App   
    Why do you think so? Most probably it's just a fake card with Kingston printed on the surface and copied flash metadata from a Toshiba card. Kingston was pretty popular amongst fraudsters some time ago: https://www.bunniestudios.com/blog/?page_id=1022
     
    Also how should such an app help detecting fake flash that simply reads out some (faked) metadata, looks up in a database and then displays $something? Fake cards use faked metadata. It's pointless to trust in this metadata at all (see my above link).
     
    My personal take on avoiding faked flash:
    Only buy A1 rated cards any more (since for the 'SBC use case' buying anything else is just a mistake) Immediately after purchase check them with either F3 or h2testw. This test will not identify modern fakes who do not fake capacity any more but use real capacity but are made out of inferior components compared to genuine cards After flashing an Armbian image with Etcher the first thing to test is 'iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2' Why? Since fake cards suck wrt especially random IO performance. The result of such an iozone test might look like this:
    root@rock64:~# iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Iozone: Performance Test of File I/O Version $Revision: 3.429 $ Compiled for 64 bit mode. Build: linux Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins Al Slater, Scott Rhine, Mike Wisner, Ken Goss Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR, Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner, Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone, Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root, Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer, Vangel Bojaxhi, Ben England, Vikentsi Lapa. Run began: Thu Jul 19 12:36:21 2018 Include fsync in write timing O_DIRECT feature enabled Auto Mode File size set to 102400 kB Record Size 4 kB Record Size 16384 kB Command line used: iozone -e -I -a -s 100M -r 4k -r 16384k -i 0 -i 1 -i 2 Output is in kBytes/sec Time Resolution = 0.000001 seconds. Processor cache size set to 1024 kBytes. Processor cache line size set to 32 bytes. File stride size set to 17 * record size. random random kB reclen write rewrite read reread read write 102400 4 1272 1303 7799 7865 6380 140 102400 16384 9837 9640 15924 14124 15921 8077  
    The 4k number for random writes (here 140) must exceed 2000 since A1 specs require at least 500 IOPS with 4k block size, iozone reports KB/s and with 4K that means we need to multiply 500 IOPS with 4K to get at least 2000 KB/s displayed. So if iozone reports anything below 2000 here I immediately ask the seller for return/refund since the card sold is not compliant to A1 performance class. Of course it's important to buy SD cards only from sellers who have a 'no questions asked' return/refund policy.
  2. Like
    tkaiser reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Update: Everything working now. These issues are resolved:
     
    1) Constant hangs were due to the cheap wifi adapter. It would hang the ssh session after 5-10 minutes of use. Switched to a better one and it now works reliably
    2) GPIO didn't behave the same as other systems. I had to add lseek(handle, 0, SEEK_SET) before each read from a GPIO pin. I should have done it earlier, but other machines seem to work without needing that
    3) Now I need to solder a 3.5mm socket onto the analog audio out to hear the output...
     
    Here's a video of it in action:
     
    https://photos.app.goo.gl/zLZS3Pw3iABCXVkK9
     
  3. Like
    tkaiser reacted to Larry Bank in Testing NanoPi NEO Core for gaming potential   
    Today's project is trying to get my game emulator to run on the NanoPi NEO Core board. Lots of exposed I/O, but I'm getting random hangs and some odd behavior with the latest Armbian. In the photo is a ILI9342 (landscape version) 2.3" display and some ugly protoboards I created to allow reliable wiring + sockets for the Core board. I just updated my SPI_LCD project to include support for both the ILI9342 and the Core board's strange header: https://github.com/bitbank2/SPI_LCD
     
    I had to wire the USB-A socket to the header because the OTG port is not properly enabled (in the available Armbian build). If I spent some time messing with it, there's probably a bunch of patches to get it working, but soldering 4 wires seemed like the quicker fix for me.
     
    I'll keep you posted on my progress (if anyone is interested)
     
     

  4. Like
    tkaiser got a reaction from 5kft in Nanopi NEO2 CPU frequency issue   
    Just had a quick look: https://github.com/friendlyarm/u-boot/commits/5532d5e641a990595156e83952049dd34cf838c0/common/board_r.c ?
  5. Like
    tkaiser got a reaction from guidol in Nanopi NEO2 CPU frequency issue   
    Me neither. Maybe @guidol can help?
  6. Like
    tkaiser got a reaction from WarHawk_AVG in SD card performance   
    Since A1 or A2 rated cards are the only reasonable choice any more for SD and TF cards here a dynamic link to a German price comparison portal that allows for filtering of results. Only A1 rated cards with at least 10 years warranty shown: https://geizhals.de/?cat=sm_sdhc&xf=5531_10~5963_A1&sort=p#productlist (Google Translate version).
     
    At the time of this writing only some SanDisk A1 and Strontium A1 cards are listed there but I hope this will change soon.
     
    Please remember: Only with cards that claim to be compliant to A1 or A2 specifications it's ensured that random IO performance doesn't suck. It's important to have an eye on A1 and A2 logos since why buying SD cards any more that perform worse?
  7. Like
    tkaiser got a reaction from Tido in gotop   
    Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.
     
    With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)
     
    I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:
     
    root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C  
    This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.
     
    That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.
     
    That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...
  8. Like
    tkaiser reacted to 5kft in Nanopi NEO2 CPU frequency issue   
    Ah - thank you for this pointer!  This is great, exactly what I need!  
  9. Like
    tkaiser got a reaction from guidol in NanoPi K1 Plus to be released soon   
    With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
     
    As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.
  10. Like
    tkaiser got a reaction from switch in Librecomputer Renegade RK3328   
    Not relevant any more since it's 2018 (and we can buy A1 or even A2 rated cards). I added a dynamic link to the thread and adjusted first post accordingly:
     
     
    Wrt Renegade: Currently our settings prevent using the faster modes so we're stuck on DDR50 (that's where the ~23 MB/s max originate from). Once SD card issues are resolved we can enable the faster modes and then those better cards will perform way better with the Renegade (only a few other SBC implement higher speed modes, e.g. Tinkerboard, the ODROIDs or Le Potato). Please keep in mind that my SanDisk Extreme Pro from almost 4 years ago can not be compared to something called 'SanDisk Extreme' from 2018 (since all this stuff improves)
  11. Like
    tkaiser got a reaction from switch in Librecomputer Renegade RK3328   
    Yesterday you only showed numbers and picture of a 'normal' SanDisk 8GB card. Those are horribly slow when it's about random IO especially at 16K block size (the SanDisk Extreme you tested later is over 100 times faster here). Usually just this makes the difference when comparing 'apt install' or 'apt update/upgrade' performance since apt does a lot of random reads and writes (and issues sync calls with the latter to ensure changes are committed to storage in the appropriate order so a crash while installing or updating won't screw up the whole package management).
     
    See here for another nice report about 'random IO storage performance making the real difference'.
  12. Like
    tkaiser reacted to user283746 in Underclock Orange Pi Zero on mainline 4.14 kernel?   
    I'm an EE that did power optimization at Qualcomm a while back. I'll just say - if only it were that easy ! If everything lines up, yes, it's possible to drop power draw to ideal. But clearly the software (legacy vs new kernel) heavily influences actual physical temperatures on the same silicon/processor. So safe to assume the board (design, layout, components etc) is just about acceptable for this price point, even if not optimal.
     
    Without a specific deep-dive into this issue, our efforts here are like band-aids the minimize the thermal performance problem with 4.x kernels rather than solve the problem at the root cause itself. IMHO, these are all 'toys' so I don't see anyone 'caring' enough to root-cause this (vs say, if this was my product line). Tinker on!
  13. Like
    tkaiser reacted to Larry Bank in Animated GIF player for framebuffer and SPI LCD   
    I just released some new code on github to play animated GIF files directly on a Linux framebuffer or SPI LCD (using my SPI_LCD code). It doesn't have any 3rd party dependencies and can easily be made to run on systems with no operating system or file system. This is part of my imaging library that I've been working on for more than 20 years. I'm slowly releasing parts of it as open-source. This code was sliced out of a much larger project which supports a whole bunch of image formats.
     
    https://github.com/bitbank2/gif_play
     
    Comments/feedback welcome.
     
  14. Like
    tkaiser got a reaction from Igor_K in Pi-factor cases   
    Another one: https://forum.pine64.org/showthread.php?tid=6288
     

     
    What can be seen at the enclosure top is a L shaped rail to be combined with thermal pads to dissipate heat away from SoC (and DRAM most probably too?) to the enclosure top cover. I think on this prototype the height of the rail is not sufficient but hey... it's a prototype most probably to check position of this rail thing (if you check the post carefully you see that it's designed for more than one board  )
  15. Like
    tkaiser got a reaction from Tido in gotop   
    Actually it's nice. It simply suffers from what almost all other tools trying to display 'CPU utilization' in some way or the other also suffer from: ignoring reality.
     
    With cpufreq scaling 'CPU utilization' alone doesn't tell that much any more especially on systems where all this stuff happens very dynamically (e.g. TurboBoost on x86 where CPU cores clock from 1.2 GHz to 2.2 GHz when just one core is busy, but as soon as a second core processes stuff immediately downclock to 1.8 GHz and stuff like that. Same situation with ARM especially with big.LITTLE and/or on boards where a cheating firmware controls what's happening and the kernel not even has any clue at which clockspeeds the CPU cores are running --> fortunately only applies to Raspberry Pi and Amlogic SBC)
     
    I thought several times about an utility both being correct and providing nice looking output. But apart from enhancing RPi-Monitor with templates for some ARM SoC families our armbianmonitor approach is all we came up with. Ugly but at least providing real information and not illusions:
     
    root@rock64:~# armbianmonitor -m Stop monitoring using [ctrl]-[c] Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:25:43: 1392MHz 0.39 9% 2% 3% 0% 2% 0% 41.4°C 0/6 10:25:49: 600MHz 0.36 0% 0% 0% 0% 0% 0% 40.9°C 0/6 10:25:54: 1392MHz 0.41 2% 0% 1% 0% 0% 0% 45.5°C 0/6 10:25:59: 1392MHz 0.46 37% 9% 16% 0% 10% 0% 48.2°C 0/6 10:26:04: 1392MHz 0.50 29% 8% 10% 0% 11% 0% 48.2°C 0/6 10:26:09: 1392MHz 0.70 36% 8% 18% 0% 9% 0% 45.0°C 0/6 10:26:14: 1392MHz 1.37 40% 1% 0% 0% 38% 0% 44.1°C 0/6 10:26:19: 1392MHz 1.34 27% 3% 17% 0% 6% 0% 50.0°C 0/6 10:26:24: 1392MHz 1.31 25% 0% 24% 0% 0% 0% 51.7°C 0/6 10:26:29: 1392MHz 1.28 25% 0% 25% 0% 0% 0% 51.7°C 0/6 10:26:34: 1392MHz 1.26 26% 3% 22% 0% 0% 0% 51.2°C 0/6 10:26:39: 1392MHz 1.64 25% 6% 19% 0% 0% 0% 49.5°C 0/6 10:26:44: 600MHz 2.07 2% 2% 0% 0% 0% 0% 42.7°C 0/6 10:26:49: 1392MHz 1.98 24% 0% 0% 0% 22% 0% 47.7°C 0/6 Time CPU load %cpu %sys %usr %nice %io %irq CPU C.St. 10:26:55: 1392MHz 1.91 24% 0% 0% 0% 24% 0% 46.4°C 0/6 10:27:00: 1392MHz 1.83 22% 1% 10% 0% 10% 0% 46.4°C 0/6 10:27:05: 600MHz 1.69 0% 0% 0% 0% 0% 0% 44.1°C 0/6 10:27:10: 600MHz 1.55 2% 0% 1% 0% 0% 0% 44.1°C 0/6^C  
    This is a Rock64 running off a really crappy 4GB SD card (I got a bunch of them recently when replacing them with SanDisk Ultra A1 at a customer) doing an 'apt update'. We see cpufreq increasing, average load increasing and even overall %cpu utilization increasing. But by looking at %io we see that the whole system is often stuck in IO simply because the SD card performs horribly low when it's about random IO. See the '10:26:14' entry: 40% CPU that are in reality only waiting for the crappy SD card finishing its work.
     
    That's the problem with 'CPU monitoring' on Linux in general and especially on SBC where 'crappy storage' is more rule than exception. When looking at load or CPU utilization it's all the time misleading as soon as slow performing storage is involved. Since 'Linux waiting for IO' counts as 'CPU busy / increased load'.
     
    That's why I unfortunately can only recommend our ugly armbianmonitor to really get a clue what's going on...
  16. Like
    tkaiser got a reaction from WarHawk_AVG in gotop   
    Fancy graphics that are totally useless (even on x86). On all the ARM boards and in the meantime everywhere on x86 as well the hardware + kernel implement cpufreq scaling. On some boards we allow min cpufreq to be as low as 240 MHz while under load when no throttling occurs cpufreq can climb up to 1200 MHz.
     
    Graphs that do not visualize this important fact are... 100% meaningless.
     
    An SBC with 20% CPU utilization at 1200 MHz is way more busy than the same SBC with 50% CPU utilization at 240 MHz while the fancy graph will show exactly the opposite.
     
    @lex' htop is better but if you really want to get a clue what's going on in Armbian you need to open a few windows and run htop, 'iostat 5' and 'armbianmonitor -m' in parallel (though with most recent armbianmonitor version you don't need iostat any more since armbianmonitor is able to display where 'average load' originates from -- on SBC the amount of %iowait percentage is crucial)
     
    BTW: the concept of 'average load' especially on Linux and especially on SBC running off horribly slow storage is mostly misunderstood.
  17. Like
    tkaiser got a reaction from WarHawk_AVG in gotop   
    No idea what you're talking about. The cpufreq governor 'just works' (or not as expected -- see this thread). The gotop tool has no clue at which frequency the CPU cores are running so it simply graphs numbers without meaning.
     
    Just tried it out on an idle Lime2. First try with our default cpufreq settings: the tool is that demanding that it already influences the system's behaviour. The Lime2 usually idles stable at 528 MHz but wenn running gotop the governor often decides to enter higher cpufreq OPP since 'too much demand'. So this is just another example of 'monitoring gone wrong' since monitoring negatively affects the system's behaviour. You watch stuff that wouldn't happen if you were not watching.
     
    To test how bad the graphing is it as easy as using a fixed cpufreq. I switched to performance governor and set max cpufreq to 912 MHz, then started gotop, then waited few seconds and adjusted cpufreq to 144 MHz just to switch back to 912 MHz after some more seconds:

    The system was idle all the time, it's just gotop being both pretty heavy wrt CPU usage and not caring about something that happens everywhere around since almost a decade: cpufreq scaling.
     
    BTW: on ARM big.LITTLE systems gotop's output will be even more misleading.
     
    I know that people will love this utility since people love colorful graphics and always prefer (meaningless) data over information. Users might have fun staring at these misleading graphs but at least for developers this tool is of no use at all (so wrong forum -- most probably the 'eye candy and fancy stuff' subforum would be better suited , SCNR)
  18. Like
    tkaiser got a reaction from WarHawk_AVG in Orange Pi Zero - CPU and Load issues with 5.38   
    Yes, it's only available what's defined in DT. This is related to this topic.
     
    But please be careful: setting minimum cpufreq to really low values is counterproductive with some cpufreq governors since it will take a high amount of time to increase cpufreq when needed. @zador.blood.stained and me tested extensively two years ago with a lot of H3 boards and back then we found that setting boards to ~500 MHz minimum was the best compromise. When looking at temperatures or consumption there's literally zero difference between idling at 240 MHz or 480 MHz. The only important thing is DVFS (entering a state where the CPU is fed with lowest voltage possible -- so on those H3 boards with primitive voltage regulation most probably idle behaviour at 240 MHz and 816 MHz doesn't differ that much or at all).
     
    Keeping minimum clockspeed at a sensible high value is especially important when thinking about storage performance since some cpufreq governors don't count I/O activity as an indication to increase CPU clockspeeds. For example SD card performance on Tinkerboard with TinkerOS sucked but not with Armbian. Only real difference: the kernel allows to downclock to 200 MHz while with Armbian our cpufrequtils package keeps minimum clockspeed at 600 MHz.
     
    In Armbian we have special precautions for the ondemand governor: https://github.com/armbian/build/blob/52c71aba807f28e8325f324fba39f25e6991f7f2/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L59-L70
     
    It seems I need to add something to tune sampling_rate as @BRSS suggested above (seems something changed with 4.14). Currently testing with
    if [ -f /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency ]; then echo $(($(cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency) / 10 )) >${i}/sampling_rate fi Feedback welcomed! Anyone willing to help please edit /etc/init.d/armhwinfo and add the above after the 'echo 10 >${i}/sampling_down_factor' line, reboot and report back.
     
  19. Like
    tkaiser reacted to ayufan in NanoPC T4   
    I actively rebase my kernel on top of rockchip-linux to keep a list of patches somehow compact. My current workflow is not very good for community contribution, still: this is rebase of commit history, but I'm happy to change that.
    One thing that is probably unique about my kernel that I release a new kernel version after every: https://gitlab.com/ayufan-repos/rock64/linux-kernel/ and https://github.com/ayufan-rock64/linux-kernel and this is released as debian packages that you can put on any distro and apt-get install: http://deb.ayufan.eu/ayufan-rock64/linux-kernel. In my latest builds, I effectively moved from building kernel each time to installing kernel/u-boot package for simplicity and split of responsibility (single resp repository).
     
    Anyway. I don't want to be a bottleneck, so I would say that the best would be to start a new common repo branch and rebase all our work on this branch, give a few people review/merging capabilities and based the work on the good will of people. I know that being alone and reviewing/accepting is a job that can get boring, as you also need to ensure the quality, splitting the responsibility here is desirable. Now, I do all the stuff there myself, but also I only have to check rock64/rockpro64 which is to be fair not a lot of hurdle for me, but with more dependence on this work we simply need more people.
     
    I somehow like the rebase workflow that we always keep a small number of patches, but I'm fine with merge workflow too
     
  20. Like
    tkaiser got a reaction from guidol in NanoPi K1 Plus to be released soon   
    With 10,000 the kernel takes a look 100 hundred times each second, when set to 200,000 it's just 5 times any more. And this is all off-topic here as already said (but same applies to the other thread that talks about OPi Zero)
     
    As a first step I tried to consolidate timer frequency settings accross all kernels since what we have today is just chaos.
  21. Like
    tkaiser got a reaction from jscax in rsyslog causing Orange Pi Zero crash and freeze   
    If @jscax is using a default/legacy image it's pretty easy to lower DRAM clockspeed with 'h3consumption -D'. And yes, undervoltage might be the culprit (the Micro USB nightmare).
  22. Like
    tkaiser got a reaction from jscax in rsyslog causing Orange Pi Zero crash and freeze   
    If a board crashed or freezes nothing will be written to syslog so searching for the strings that appeared in the logfile long before the crash/freeze happened is pretty much useless.
     
    We provide diagnosis tools, check the output of 'armbianmonitor -m' yourself (maybe post a few lines after an hour of operation) and please post the output from 'armbianmonitor -u' (since without no one has a clue which branch and kernel you're running and so on).
     
    @Igor: Is this patch not applied any more? https://github.com/armbian/build/blob/master/patch/u-boot/u-boot-sunxi/adjust-default-dram-clockspeeds.patch#L244
  23. Like
    tkaiser got a reaction from gounthar in ROC-RK3399-PC (Renegade Elite)   
    The way both demo videos are produced it could be fakes (statically overlaying different display contents). @Da Xue just as a suggestion (from someone who had to learn to spot faked SBC demo videos): IMO it would be better if there's a little bit of human interaction overlapping the display contents at least for a short time.
  24. Like
    tkaiser got a reaction from WarHawk_AVG in Orange Pi Zero - CPU and Load issues with 5.38   
    OPi Zero and all the other smaller H3 boards implement DVFS with just two voltages: 1.1V and 1.3V (some interesting stuff wrt this)
     
    These 912 MHz are the value we chose with legacy kernel to remain on the lower voltage but with mainline kernel it's 816 MHz instead (with legacy we used our own optimized 'Armbian settings' while with mainline we rely on 'upstream settings'). So if you want to ensure lowest consumption and heat possible with mainline kernel this needs to be adjusted to MAX_SPEED=816000 instead. The 96 MHz difference isn't important, remaining on 1.1V is.
     
    Should be pretty easy to test for by setting both min and max speed one time to 816 and the other to 912MHz and then compare temperatures in idle.
  25. Like
    tkaiser got a reaction from CabröX in NanoPI M4   
    Thank you for updating the post with this second picture!
     
    So I would assume we have either:
    one USB3 port directly connected to RK3399 and three USB3 ports behind the internal VL817 hub sharing bandwidth or all 4 USB3 ports behind the internal VL817 hub sharing bandwidth (then OTG is routed to USB-C but only as Hi-Speed?) Same Wi-Fi chip as NanoPC-T4, optional eMMC, 2 PCIe lanes available on a header... nice! I really hope NanoPi M4 and NanoPC-T4 will be as compatible as possible so we can support them with a single image