tkaiser

Nope. Care to read and understand what Igor explained? Even if you replace 'stable' with the correct word 'default' it won't work.

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.

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

Really curious about what you did with PCIe here, how many times SuperSpeed is available at USB receptacles and so on. Can't wait for the wiki page to appear

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.

I'm so stupid... since I consulted schematics before and forgot that you can't trust in anything this famous company provides as 'information'. Their schematics for v1.1 board were wrong, they wrote 1.2V while in reality it's 1.3V and my early developer sample used even 1.4V (funny DIY instructions to fix this on Rev 1.0 boards). Ok, time to edit linux-sunxi wiki again and our fex file once it's confirmed the board really comes up with 1.3V.

Not mentioned by them of course... but it seems the new board revision also contains an eMMC 5.1 for which patches might be necessary: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/commits/master No idea who's looking into this. It's 2018 and at least I'm not interested in wasting just a single second any more on fixing expensive H3 boards (those cheap ones at 10 bucks are still great as IoT nodes or those with A series SoCs and PMU/battery support)

FriendlyELEC usually updates their wiki prior to official product launch.

Since I doubt we ever get any useful answer I prepared at least legacy images: https://github.com/armbian/build/commit/57f90b0b69bb31cd190f064428c0d9b1e33fadf0 The next batch of images created with legacy kernel will use 912 MHz as upper cpufreq limit since users might get a new v1.2 board that boots with voltage regulator set to 1.1V only. Users of rev 1.1 boards can use h3consumption to get their former maximum cpufreq (though this was set too high, see post above. With 1.2V Allwinner's official recommendation is 1008 MHz maximum while 1104 MHz might work with the majority of boards): h3consumption -m 1200 Users of rev 1.2 boards have to do the following as root first: cd /boot/ cat bin/bananapim2plus_v1_2.bin >script.bin && reboot If the board reboots you're fine and can enjoy voltage regulation, if not the image you use is too old and needs to be updated first. Afterwards you can tweak settings with h3consumption as you want. For the mainline kernel images there's no solution yet

SinoVoip BS as usual. H3 has no PMU support (PMU --> Power management unit, something only Allwinner A and R series are equipped with and from H series only H6) It seems they simply implemented simple GPIO triggered voltage switching between 1.1V and 1.3V via PL01 (same as on their Zero) so now we have the same problem as with NanoPi NEO2 and others: Older variants have been sold without any voltage regulations (but at least same voltage as the lower now: 1.1V), now voltage regulation has been added. So what to do? A discussion how to solve this problem is ongoing here: https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?tab=comments#comment-57746 -- @5kft made a proposal no one has reacted to so far. It's important to keep in mind that older BPi M2+ variants use 1.2V and our images use this voltage level to allow an upper clockspeed of 1200 MHz that will for sure result in troubles when those new BPi M2+ should come up with voltage set to just 1.1V. It's important to keep in mind that older BPi M2+ variants use 1.2V while our images accidentally assumed it would be 1.3V based on the review/developer samples SinoVoip sent out to us over 2 years ago. So the 1200 MHz maximum we currently allow for BPi M2+ may be considered stable on those v1.0 boards a few of us have but are already borderline with the V1.1 boards and will cause trouble for sure when the new BPi M2+ variant boots with voltage regulation set to just 1.1V. I got confused since SinoVoip released wrong schematics for their rev 1.1 boards (see below). Rev 1.0 boards used fixed 1.4V while rev 1.1 boards used 1.3V (and schematics showed 1.2V for no reason). So if BPi folks did not ensure that default voltage when the board boots is 1.3V buyers of the new BPi M2+ might experience crashes while booting with already existing images. Let's wait whether we get those reports and whether one of those BPi folks clarifies whether the voltage regulation comes up with 1.1V or 1.3V when unconfigured. If it's the former most probably the simplest solution is to drop Armbian support for the board right now.

Yes, two and a half years ago it was not listed. BTW: in the upper right corner there is a search function.

Never seen this before but obviously thermal readouts are (once again) broken for whatever reasons after a kernel update. I already added code to better cope with this but seems it doesn't work in this situation. Log upload failed due to this timeout issue (how long does it take until the command gets back with that error message?) so could you please do the following instead (capital U this time) and upload the results to https://pastebin.com? armbianmonitor -U

Already available: The official NAS enclosure which opens up plenty of opportunities for specific server and NAS use cases: Please check the product page for details (e.g. what's included and what you need to purchase separately) My understanding is that the drive cage can accomodate 2 x 3.5" disks and 2 x 2.5" disks though you can only use 2 of them at the same time with Pine's own SATA card (relying on an ASM1061 -- check performance numbers here, the tests were made on an ODROID-N1 which uses same SoC and SATA chip). The ASM1061 only provides 2 SATA ports (so eSATA and SATA can't be used at the same time) and is attached with just a single PCIe lane which is fine when connecting spinning rust but will already bottleneck two SSDs since PCIe will limit overall bandwidth then. Performance fanatics might skip Pine's cheap ASM1061 card and search for a PCIe card based on either ASM1062 or Marvell's 88SE9230 (both using 2 PCIe 2.x lanes, the latter providing 4 SATA ports). If it's just about attaching 4 SATA devices cards based on Marvell 88SE9215 will also do it (for performance numbers see here) External powering with one single 12V PSU (it's the common barrel plug with 5.5/2.1mm, centre positive) is sufficient. For 2 3.5" disks you should choose 5A. If you want to add Wi-Fi to this setup you most probably need to drill 2 holes to attach good external antennas (recommended since Pine's Wi-Fi module is a pretty decent one: AP6359SA is dual-band and dual-antenna and even RSDB capable which allows to use both bands at the same time so providing more bandwidth but especially lower latency if the AP also supports it)

Can you provide the output of the following please: ls -la /etc/armbianmonitor/datasources/soctemp cat /etc/armbianmonitor/datasources/soctemp armbianmonitor -u

h3disp

Strange, no output? Hmm... these numbers are mostly marketing stuff since for whatever reasons some of those modes are just added theoretical numbers (e.g. the 600 Mbps of 802.11n which are just the addition of the 2 numbers 150 and 450 which only would make some sense if the adapter is capable of Real Simultaneous Dual Band (RSDB)... and most of them aren't but still are advertised as '600 Mbps') Also throughput at the network layer is always way lower (I found once a great explanation online but no luck yet). Anyway: your numbers suggest you're using HT40 with the RTL8723BS now (ultra wide channels which are of almost no pratical use in urban areas) so unless the NanoPi and your router aren't the only ones around througput should drop drastically. In my opinion 2x2 MIMO and/or switching to 5 GHz is still necessary to get any decent wireless performance. So I would prefer any RTL8192CU USB dongle featuring 2 antennas or those SDIO attached MIMO capable wireless chips that appear slowly (like AP6356S on NanoPC T4 or AP6359SA to be combined with RockPro64 -- this one is even RSDB capable which provides more bandwidth but especially lower latency)

All FriendlyELEC boards have a 4-pin header for serial console and to be powered with. But as already mentioned their A64 board is the only one around with this SoC not able to deal with batteries since lacking connector/circuitry (ok, the other exception is BPi-M64 with the super sophisticated battery connector you can attach nothing too). IMO battery support is the only reason to look at A64 at all. Nope, I don't agree. RTL8723 is the same as any of those other '2.4 GHz 1T1R' Wi-Fi thingies. They all perform more or less the same and environmental conditions (count of 'adversary' wireless networks around) matters more than anything else. I referenced the relevant thread already. If it's about battery support in the past I always chose Olimex since they sell matching batteries on their own (for which the relevant parameters were available). Just came accross this here so maybe situation with Pine64 has improved in the meantime (only remember some weird discussions over in their forum long time ago).

Continuing discussion over there: The numbers you published here... were they made with HT40? Care to provide iwconfig output?

Guess which is the only Allwinner A64 board around where engineers 'forgot' to include charging capabilities? The one that is on sale of course All 64-bit SoCs that support ARMv8 Crypto Extensions (this is something different than SoC vendor proprietary 'crypto engines'). So every Cortex-A53 or A72 (except Raspberry Pi, ODROID-C2 and NanoPi K2): https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829

That's irrelevant since it happens above the filesystem layer. It's all about partition alignment. I changed this last year to 4MB boundaries. This resulted in a partition alignment at 4 MB boundaries (before we were using 1 MB) so after this change less wear on SD card but '3 MB wasted'. Since unlike other projects we do not promote the use of old, small and crappy SD cards and the minimum card size you get today is 16GB* I think 'wasting' 3MB on a 16GB card is nothing to care about. * (personal recommendation: SanDisk Ultra A1 16GB -- but always check prices of the larger variants since at least 32GB are not that much more expensive than the 16GB variant)

RTL8189ES is 2.4 GHz and 1T1R so I would assume @lex used one of the HT40 modes for his iperf3 tests (those modes might produce nice benchmark numbers but are pretty useless in reality due to Wi-Fi being a shared medium and the band usually overcrowded like hell in urban areas) Would be interesting to see 'iwconfig' output...

h3disp -d reboot

[x] done I agree on the need for a regular resync to 'disk' and wonder whether it's possible to make it somewhat easy configurable (e.g. defaulting to 1440 minutes which can be overwritten by setting SYNC_INTERVAL=60 in /etc/default/armbian-ramlog)?

Web search for authentication token manipulation error site:armbian.com shows threads were users failed to burn correctly and the rootfs on the SD card was in such a corrupted state that it has been set to read-only at booting. None of these users was aware that burning went wrong (hardware trouble). They all reported an 'Armbian problem'. The less obvious cases of 'burning went wrong' NEVER talk about failed flashes but about 'Armbian bugs' or even 'Armbian sucks'. Since people are not aware of burning SD cards being such a sh*t show. Often users feel offended when told to use SD cards that are not utter crap (too slow) or told to use another burning tool (that verifies what's going on), then they try Etcher, Etcher reports failure and users think the tool would fail but not their crappy SD card (or reader or whatever). See here, here or here. The symptoms of such soft failures differ depending on whether the SD card is crappy itself or only something went wrong when burning. In the first case users might spot mmc errors in their logs but if only the burning process was faulty then they just have an OS install containing various bit flips which lead to all sorts of strange problems that all just look like software malfunctions (I myself ran into this issue over 2 years ago since back at that time Etcher-CLI didn't exist and I wanted to burn on my Linux build host. Did this with dd, no error messages when burning but weird software behaviour. I waste more than one day on this since I was developing at the same time and was hunting for bugs that did not exist -- since crappy card reader was the culprit creating data corruption while burning -- moving the card reader to the back of the PC to USB ports that were directly connected to the mainboard solved the issue. That day I learned to never ever skip verify) In Armbian we started 2 years ago promoting Etcher and trying to educate our users to only use this software. That helped somewhat and in the meantime Etcher is fortunately the standard recommendation almost everywhere. You should keep in mind that Pine64 folks forked an early Etcher 2.0 beta to provide all OS images only through this tool (called Pine64 Installer) since IIRC 60% or even 70% of all support requests and 'DOA reports' were simply related to users failing to burn an image to SD card.

Ok, one last time: it's about the AVERAGE USER and THEIR AND OUR TIME. Not about what some 'experts' use and some anecdotes like Etcher always generating kernel panics while Win32DiskImager working flawlessly (haha). Does this Win32 tool provide an auto update mechanism so it's ensured each and every user who downloadded this tool in the past is already using the latest version? If not then recommending this tool is a great way to sabotage Armbian development Does this tool always verify the burning result by default ('by default' is important since average users don't change default settings)? If not then recommending this tool is a great way to sabotage Armbian development Is this tool Windows only or available on other platforms? If only Windows why should we even mention it? I don't get it why it's so hard to get that a MANDATORY VERIFY after burning is important (unfortunately Etcher users can change the defaults and skip verify -- but fortunately users almost always stay with defaults). Again in big letters since: VERIFY IS IMPORTANT! Personally you can use whatever tool you want. But please stop the attempts to recommend anything else than Etcher. It's kicking us developers into the face since we can not spend our time on improving Armbian but have to deal with reports of 'Armbian fails this or that way' that are in reality just the result of 'burning went wrong'. This thread contains a bunch of examples why burning can fail. The 'average user' reality out there is that they are not aware that burning often fails. They use SD cards that are lying around, they buy counterfeit cards on eBay and Aliexpress, they use crappy card readers and have not the slightest idea why VERIFY is important. So please stop recommending tools that allow them to skip verify. Nice to see that this Win32 tool now allows for an optional verify (optional --> useless since people will skip it and then open up 'bug reports' here as they did in the past prior to the 'Use only Etcher' recommendation). Once they implement this as mandatory and every Windows user uses at least this latest version then this tool could be recommended. But not today. Again: it's not about what people do who consider themselves experienced users or even experts. It's about average users and it's about allowing us to focus on development and not wasting our time trying to hunt bugs down that do not exist since just the result of the 'burning SD cards' sh*t show prior to Etcher.