tkaiser

And two quick storage performance updates: 1) This is the 8GB eMMC FriendlyELEC sells (write performance limited to 43 MB/s as it's mostly the case with low capacity eMMC, read performance exceeding 130 MB/s, nice random IO values -- compare with our overview): random random kB reclen write rewrite read reread read write 102400 4 8565 8793 24853 24808 19463 8523 102400 16 25604 25986 66627 66701 56571 24459 102400 512 42217 42326 125788 126508 125959 40394 102400 1024 42762 43178 129692 129726 130452 42636 102400 16384 43914 42877 132828 133254 133417 43012 2) In the meantime I built also OMV images for NanoPC T4 and NanoPi M4 and did a quick LanTest benchmark with M4 and an externally connected Seagate Barracuda in an USB3 enclosure (not UAS capable -- but this doesn't matter with HDDs) Close to 100 MB/s sequential speed without any more optimizations is simply awesome: (debug output)

Can you provide output from these two commands one time with VPN active, the other without? nohup iostat 5 & ; time speedtest-cli ; pkill iostat ping -c 5 185.44.76.118 (replace '185.44.76.118' with the address shown by speedtest-cli before). A file called nohup.out will be created. Please post the contents as well.

Please check I found this error almost all the time related to cable/contact issues and/or underpowering.

Well, I'm not entirely sure how high the percentage of Armbian users is running Linux on the machine they deal with the downloaded Armbian image. I would believe that's less than 0.1% since the majority uses something called Windows or macOS. In fact those Linux users today already can simply loopmount the image and edit /boot/armbian_first_run.txt since /usr/lib/armbian/armbian-firstrun-config already exists and works. I thought about tweaking this mechanism to support more options like @botfap is currently doing but making this feature accessible to those +99% of Armbian users not able to mount an ext4 partition. That would require adding a 32MB FAT32 partition priot to the rootfs partition. On this partition labeled "Armbian" then the following will be: armbian-firstrun-config.txt (here options can be set that are then processed by /usr/lib/armbian/armbian-firstrun-confi, ideally the defaults are also contained but commented so users get an idea how an otherwise unmodified Armbian install will work) README.html (containing a brief overview how to access documentation, how to search the forum -- not just a stupid link to the forum but an explanation how to search the forum! -- and how to donate to the project) a 'documentation' directory (containing an offline version of https://docs.armbian.com) The approach would be compatible with @botfap's work since when his tool is written in clean bash it can also run on macOS (I honestly don't care about Windows at all) and it just needs an additional mode where it generates armbian-firstrun-config.txt instead and his actual config tasks need to be merged into /usr/lib/armbian/armbian-firstrun-config

Not happened here with Rockchip so far (with EspressoBin I had issues but there I boot now from USB3 and ignore the SD card slot). Another interesting observation: My 2GB NanoPi M4 has higher memory bandwidth and lower memory latency compared to the 4GB version: 2GB kernel 4.4.155 4GB kernel 4.4.155 2GB kernel 4.19.0-rc1 4GB kernel 4.19.0-rc1 BTW: I now also replaced the thermal pad on my 4GB NanoPi M4 with a copper shim + thermal compound and the results are impressive again: At the end of a sbc-bench run max. temperature is now at just 73.3°C (no throttling) compared to reaching 85°C throttling included with thermal pad. Those thermal pads suck. @hjc did you already look into lowering DVFS voltages? In the past we did this using a special Linpack version that is able to spot undervolted DVFS OPP before the board actually crashes.

[x] Done. 70.6°C max reported now with cpuminer benchmark running but otherwise totally idle board lying flat on a surface. And then I repeated the test this time bringing the board in an upright position since as we can see from the thermal image above RockPro64 PCB is designed to also dissipate heat from SoC into the PCB's copper ground plane. So allowing some airflow around the whole PCB should help. And it does: 69.4°C now reported. The 1.2°C less do not tell anything relevant so better look at how temperatures changed while testing: idle to 70°C high to 50°C lying flat 420 sec 280 sec upright --- sec 210 sec (with my limited time I was not able to test 'idle to 70°C' and this test is also flawed since the starting temperature is not fixed. That's why I always recommend to test with 2 consecutive sbc-bench runs and only look at the second run that starts with an overall warm board since cooling down from previous test run at always the same start temperature: sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 -- for details see here) Comparing with 'stock heatsink situation' (the grey thermal pad between SoC and heatsink) this is a nice improvement. With identical demanding task and external conditions (ambient temperature still at 24°C) temperatures went down from 85°C (with slight throttling occurring) to 71°C when executing the 5 minute benchmark run starting at 50°C. And by allowing some airflow around the whole PCB this gets even better and temperatures drop even a bit more. This is important for people wanting to avoid fans since by replacing the thermal pad with thermal compound and allowing for some airflow (no tiny enclosures!) they know they get maximum performance out of their board without throttling happening (the cpuminer benchmark is pretty demanding since making use of NEON optimizations 'normal' software doesn't use). As a comparison the lightweight sysbench 'cpu test' joke running for 20 minutes: sysbench --test=cpu --cpu-max-prime=200000000 run --num-threads=6 Temperature stays at 55°C at an ambient temp of 24°C. Please note that once you cramp your board and heatsink in a tiny enclosure this will look entirely different.

As if I would be interested in GPL violations. That's the last thing I care about. It just illustrations this total fail to get things right ('balance between NDA and open source' -- what a funny BS). The real problem with Realtek SoCs is this: https://www.cnx-software.com/2017/09/27/banana-pi-bpi-w2-is-a-features-packed-realtek-rtd1296-development-board/#comment-546422 (they have a VERY STRONG reason to keep everyone under NDA and to NOT publish their kernel sources and there will never be mainline support for these SoCs) A vendor who is not able to provide correct documentation (they are not able to even list the f*cking dimensions of their products correctly since they don't give a shit about accuracy ) and constantly babbles about 'open source' instead of clearly communicating how things really are ('we can't share sources, we signed an NDA, you won't get access to what you need') and always chooses a new SoC for any new design... well, let's simply stop talking about this Dunning-Kruger show here.

The above was with RockPro64 and a 1mm copper shim between RK3399 and heatsink. Since 2 NanoPi M4 arrived in the meantime I removed the heatsink and copper shim from RockPro64 to use the copper shim now with the NanoPi (with promising results). Now trying to get a really thin film of thermal compound on both RK3399 and the heatsink and then putting them both with nothng in between together: Full output from 'sbc-bench.sh -T 70 ; sbc-bench.sh -t 50' now https://pastebin.com/raw/hmRUMkGu and comparison to above: 20:50:26: 1800/1416MHz 6.39 100% 0% 99% 0% 0% 0% 70.0°C 20:50:38: 1800/1416MHz 6.44 100% 0% 99% 0% 0% 0% 68.9°C 20:50:50: 1800/1416MHz 6.52 100% 0% 99% 0% 0% 0% 68.3°C 20:51:03: 1800/1416MHz 6.62 100% 0% 99% 0% 0% 0% 70.0°C 20:51:15: 1800/1416MHz 6.60 100% 0% 99% 0% 0% 0% 71.7°C As expected even better thermal values now: 71.7°C displayed but the average load next to it indicates that some other background activity happened in parallel (the 'cpuminer --benchmark' task on an otherwise idle RK3399 should not exceed 6.2 so the 6.6 of my test run indicate a problem -- I need to re-test again ) But the good news is: if you get some thermal compound then you don't need a copper shim at all and can also avoid the thermal pad. But it's a good idea to use the thermal pad to cut some pieces and put them next to RK3399 to prevent shorts as can be seen above.

Absolutely support this. But IMO discussion should be moved out of this thread in an own thread over at https://forum.armbian.com/forum/12-armbian-build-framework/ @Igor can you please move last two posts to something like an 'Initial easy setup proposal' thread? I think a lot of users might benefit from a way to easily adjust the settings @botfap talked about prior to first boot.

LOL! Right, I almost forgot. You also don't give a shit about what's happening outside your company so any criticism is irrelevant and can be just the result of single persons being 'evil'. Ah, I love the 'Dunning-Kruger effect' so much Hey @chwe: what to do with this technical discussion here? Edit: Updated archived version of these funny insights. Just in case BPi folks start to edit their posts: http://archive.fo/kL8tP

This was already known. You violate the GPL not just by accident but knowingly and willingly. It can't be worse. You might feel save but you should keep in mind what happened to other GPL violators like D-Link.

@Nora Lee and @Lion Wang thank you so much for confirming that nothing has changed within the last years. To summarize: you don't understand the meaning of 'sources' in general you don't understand the relevance of the GPL (forcing you or let's better say RealTek to immediately release the sources you build stuff from) you don't understand that when you have to sign an NDA with a vendor you're becoming part of his GPL violations. Also it outlines your inability to understand the meaning of 'open source' in general you don't understand the power and relevance of open source communities Adding to this you still alow the most careless person on this planet to do your 'technical documentation' (funky copy&paste jobs full of errors without thinking a single second) and it should be obvious why software support around your recent devices sucks that much. I bet you're already working on a Qualcomm or HiSilicon board just to ensure software support will be as terrible as we're all know it from your other boards (choosing each and every time a new SoC is such a brilliant move to ensure efforts are high and user expectations can never be met)

OMG, you Banana folks will never get it. You and RealTek are not just plain GPL violators but if your above statement is true (which I doubt) you act also as stupid as in the past preventing talented community members helping you. Ask @frank-w, ask @Tido (maybe he'll explain to you again the 'release early, release often' benefits) My guess is you simply don't get sources from RealTek...

The problem is that 'true' USB-C chargers limit current to 500mA or 900mA if the other end of the USB-C cable is not able to negotiate the demand for higher currents. And those 5V SBC with USB-C right now (Vim2 and now also NanoPi M4) don't do this. They act in 'dumb' mode and require the PSU to provide 'current without asking' which standard compliants USB-C chargers will refuse. So you need a dumb or tolerant charger too. I've measured booting current with my dumb PSU and this was reported as above 5.6W which would translate to +1100mA which is well above what a standards compliant USB-C charger is allowed to provide to a dumb device. Yes, I hope this one does well. No chance to test yet since missing the needed adapter (also available in FriendlyELEC's online shop and also a recommendation for those affected then):

Dear @Nora Lee, since you're the BPi product manager I guess by not answering my question above but spamming other forums with irrelevant links you confirm that you're not able to provide bootloader and kernel sources for your W2 'closed source router', true?

And now a quick look at NanoPi M4's massive heatsink. Since I have 2 boards with one board I used the supplied blue thermal pad between RK3399 and heatsink and on the other board instead of thermal pad a 20x20mm copper shim of 1 mm height with a thin film of thermal compound on both sides. Test methodology is sbc-bench.sh -T 70 ; sbc-bench.sh -t 50 (reasons why). Full results: Thermal pad and copper shim Yes, it's a bit hard to interpret this stuff but detailed interpretation is necessary having the design of the heatsink in mind: the thing is massive (huge own thermal mass) the heatsink has fins where air can be directed through (one large and silent fan can easily cool down a whole bunch of M4 with controlled airflow) the heat conductivity of the material between heatsink and SoC plays also an important role I'm in the process of doing a lot more tests (to generate insights, not fancy graphs and numbers) but for now only the following data revealed (that needs confirmation, I'm not entirely sure if testing with two boards is not a flaw) Let's look at temperatures at the end of both sbc-test thermal tests (the first pre-heats to 70°C, the second one waits until SoC temperature is as low as 50°C): start 70°C start 50°C thermal pad 85.0°C 85.0°C copper shim 79.4°C 74.4°C Copper shim with thermal compound 'wins' but with such a massive heatsink better heat conductivity also has its downsides. So let's look at how fast switching between temperatures works: idle to 70°C high to 50°C thermal pad 75 sec 330 sec copper shim 600 sec 750 sec Results in the first row look reasonable to me (the better the SoC's heat can be dissipated into the massive heatsink the longer it takes until SoC/board temperature rises). The 2nd row (cooling down) IMO needs more investigation since I would've thought that the cooling time would be somewhat similar. But for this I most probably need precise thermal measurements to get a clue about the heatsink temperature itself. At least now when testing with the copper shim efficiently dissipating the SoCs heat into the aluminium block the heatsink gets too hot to handle when SoC temperature is reported as being higher than ~65°C for some time. All of the above was talking about true passive mode. But of course the heatsink is sufficient to be used with active cooling too. Just blow a little bit of air laterally through the heatsink fins and the board can do whatever power hungry task you want and stays cool forever. Quick experiment now at a customer: I put the NanoPi M4 directly behind the air outlet of an annoying noisy Xeon server's PSU so that the 'waste heat' coming out of the server goes through the heatsink fins. Running cpuminer on the M4 in the background scoring 8.8kH/s constantly and temperature below 43°C (at an ambient temp of 18°C in the server room, but the 'waste heat' coming out of the PSU is definitely a bit 'warmer'): https://pastebin.com/raw/s1zvyfU6 TL;DR: the massive heatsink is great even in total passive mode when only short load bursts happen (then heat gets efficiently dissipated into the aluminium block, even better with a copper shim instead of thermal pad). For high loads over longer periods the heatsink is still fine without additional ventilation as long as you're comfortable with electronics devices being operated at higher temperatures. To improve heat dissipation simply blowing some air through the heatsink fins is sufficient. I think my further testings will focus on the difference between FriendlyELEC's approach (huge thermal mass and heatsink fins more or less only efficient when combined with some airflow) and RockPro64's implementing a different strategy and now even more efficient since there RK3399 and heatsink can also be connected directly with just some thermal compound in between:

I'm now also testing IO performance on NanoPi M4 to get an idea how much influence the integrated VIA VL817 USB3 hub has. The following test command is used since I test with an el cheapo Samsung EVO 840 (known to exceed 500 MB/s on a SATA port but low capacity and implementing TurboWrite) taskset -c 4 iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2 sleep 300 taskset -c 4 iozone -e -I -a -s 2000M -r 16384k -i 0 -i 1 -i 2 Why do I test first with 100 MB, then wait 5 minutes and test again with 2 GB? Tests with 100 MB to keep results comparable with my previous collection An additional test with 2 GB since we found that with fast USB3 implementations and fast SSDs the maximum throughput isn't reported when testing with low test sizes. 1GB or better 2GB seem like a reasonable additional test to look for real maximum bandwidth possible Why waiting for 5 minutes (sleep 300) in between? Since my 128GB EVO840 implements TurboWrite and therefore is only capable to write data at maximum speed until the TurboWrite buffer is full. So if I would've tested all block sizes with 1GB test data size the EVO itself would've turned into a bottleneck after approx. 2.5GB data written Why 'taskset -c 4' (executing the test on a big core)? Since we're looking for maximum performance here Raw results as follows random random kB reclen write rewrite read reread read write 102400 4 25559 28658 21964 22012 21957 28183 102400 16 84846 94435 80322 80926 81083 92975 102400 512 325556 326434 289616 292997 294076 322974 102400 1024 347800 362005 324009 327371 329460 352963 102400 16384 381091 386458 370522 373441 373337 378399 2048000 16384 401465 402916 375361 375457 375509 398665 In other words: Even with an USB3 hub in between storage performance is excellent as long as only one disk is connected (with more than one disk and accesses in parallel performance will of course drop since then bus contention issues might occur and bandwidth has to be shared). But with HDDs this is no issue at all since they're too slow anyway. Storage performance summary: I've had some fear that the internal USB3 hub will trash storage performance but that's not true (at least when only one disk is connected). As a reference numbers generated with same SSD, same settings and same test methodology on discontinued ODROID-N1 (as an example for RK3399 USB3 without hub and also with same SSD connected to a cheap PCIe SATA controller): Random IO in IOPS Sequential IO in MB/sec 4K read/write 1M read/write ODROID-N1 5994/6308 330 / 340 NanoPi M4 5489/7045 330 / 355 ASM1061 powersave 6010/7900 320 / 325 ASM1061 performance 9820/16230 330 / 330 The ASM1061 numbers are especially dedicated to all those SBC users believing into 'native SATA'. Sequential storage performance with a good UAS capable USB3-to-SATA bridge is higher compared to cheap PCIe SATA controllers. 'Native' SATA does not exist with RK3399 anyway and for really high SATA storage performance more expensive SATA controllers making use of more than 1 PCIe lane are necessary. But with just an ASM1061 the only two real benefits of PCIe attached SATA over USB3 attached SATA are higher random IO performance less IRQs to process which results in less CPU utilization (see ODROID-N1 link above) But to attach one or two USB3 HDDs and share them at maximum speed (~100 MB/s through network) the NanoPi M4 is perfectly fine. Edit: Debug output here. We can see the usual 'ERROR Transfer event for disabled endpoint or incorrect stream ring' XHCI error when connecting an USB3 disk enclosure the first time (known problem but doesn't cause any harm) and amount of DRAM is reported differently since I swapped the SD card between my two NanoPi M4

Yesterday 2 sets of NanoPi M4 arrived (one 2GB and 4GB) which will make it convenient to test for stuff like heat dissipation in less time (I use one time the supplied thermal pad with the large heatsink, on the 2nd board I replaced the thermal pad with a 20x20mm copper shim of 1mm height I took away from my RockPro64). But now talking just about USB-C: NanoPi M4 while using an USB-C connector to be powered is obviously not USB PD compliant but simply uses the USB-C connector to be combined with a 'dumb' PSU that provides the necessary amount of current without any negotiation. FriendlyELEC shipped a new 5V/4A PSU with USB-A receptacle combined with a very short USB-C cable. Since the PSU is not EU style and I miss the necessary adapter I currently use my standard 'dumb' 5V/2A USB PSU which works fine for the tests I currently do. Not being compliant to USB PD specs (or USB-C powering specifications) means two things: Pro: no expensive USB-C charger needed (check the funny discussion in Khadas forum and there the link to tested USB-C chargers and their prices). A dumb 5V PSU that can deliver the needed amount of current at a stable voltage will be sufficient Cons: possible voltage drop N° 1: at 5V with higher currents the majority of cheap PSUs won't deliver. They can do either 5V or 4A but not both at the same time (this issue can be studied around ODROID boards that are also designed with 5V/4A in mind) possible voltage drop N° 2: the cable quality and length between board and PSU becomes an issue since here an additional voltage drop happens. The longer the cable and the thinner the wires the less the voltage available to the board (symptoms as above: especially USB disks or peripherals in general will be affected) possible undercurrent: I don't know yet but in case the NanoPi M4 really does no USB PD power signalling at all stuff like with Khadas Vim2 might happen Not possible to use 'real' or standards compliant USB-C PSUs since not providing enough current since the powered device is not able to negotiate higher current demand Edit: tested with my MacBook Pro USB-C charger not exceeding 500mA with 'dumb' consumers on the other end of the USB-C cable: endless boot/crash cycle. So be prepared to run into troubles combining NanoPi M4 with a real USB-C charger compliant to specs. This didn't work with the Vim2 and it also does not work with NanoPi M4. @hjc: seems you can consider yourself lucky that your USB-C charger is outputting more than 500/900 mA when feeding 'dumb' consumers.

With something that's broken by design? Adding tons of complexity for no real reason and allowing to backdoor your system at a level the OS can never detect? Ever done a simple web search for 'uefi security vulnerabilities issue' or something like that?

That's because you do NOT use Armbian and therefore instructions for Armbian won't work. As expected. You might have your reasons to do everything complicated and manually though...

Well, as expected. Talking about this https://github.com/armbian/build/blob/master/packages/bsp/common/usr/lib/armbian/armbian-firstrun-config? If so this is as useless for average users as what I do all the time: let customize.sh throw an appropriate NM profile into /etc/NetworkManager/system-connections/ at image creation time. Average users would need a FAT partition so they can access it from Windows or macOS. But instead we should emphasize that on our officially supported boards w/o Ethernet a remote console sits on the MicroUSB port waiting for the user to login.

What't this? In case you want to install linux-headers on Armbian the procedure is as follows: https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver

SinoVoip's Copy&Paste monkey in action: http://forum.banana-pi.org/t/a-review-of-the-banana-pi-m2-zero-running-openhab/ --> 'I personally would not want to run on a machien that freezes every time I update the config.' and 'I must say the BPi is no longer booting for me after sitting idle for a month or so' Warning or 'success story'?

This is a random forum post. We still don't have something that could be called a FAQ (only 'Getting started', 'Troubleshooting' and 'please ask the same questions over and over again in the forum') but IMO such a FAQ is needed and should then link to such 'summary topics'.

Couldn't agree more and still ask myself what I did the first time I heard of RK3399 boards: 'what's the use case for an ARM board that costs as much as a real Mini PC?' If the special capabilities of such devices (dual camera input, image processing, attaching a bunch of displays -- no idea what works with Linux and what only with Android) aren't used what's the point of spending huge amounts of money on these things? But maybe it's only me. At least I don't want to spend ~40 bucks just on a PSU (USB-C PD compliant) for such a device or +20 bucks to get appropriate heat dissipation (applies to Khadas Edge/Edge-V -- ~60 bucks for 'basic' accessories but users seem happy) Wow, 100 bucks (with a 20% Indiegogo discount) for 128GB storage and the PSU.