tkaiser

EDIT: All of the below written stuff is outdated and not recommended to run on any Armbian installation anyway. Simply use Armbian with default settings and you're done. In case you want to adjust settings, search the forum for 'h3consumption' utility.
 
EDIT: Please be aware that it seems voltage switching on the various Orange Pi One boards seems to have some tolerances. A user reported his Orange Pi One crashes randomly when staying on the lower voltage with the new fex settings so unless it's confirmed which voltages are really used or how to measure the real voltage the proposed fix here might lead to undervoltage/stability issues on some boards.
 
EDIT 2: In the meantime it seems only my board suffers from overvoltage so v0.3 of fix-thermal-problems.sh will apply default settings for Orange Pi One/Lite again.
 
When we first started with Orange Pi H3 SBCs a few months ago we had to realise that the SoC was blamed for overheating. Fortunately this was mostly due to overvolting/overclocking. I developed a rather primitive script to fix this stuff by converting script.bin to a temporary file, adjusting the relevant parameters to sane values and converting this back to script.bin last year.
 
Now Orange Pi One is there and the manufacturer simply disappeared. They sell a new board but there's zero information, OS images, any comments on settings, no schematic, simply nothing. This intercultural thing is still really amazing!
 
EDIT: Schematics have been released: http://linux-sunxi.org/Orange_Pi_One#See_also
 
First investigations showed that the different way to regulate the SoC's voltage seems somewhat broken and Orange Pi One is overvolted by design (affects temperature, stability and probably longevity negatively)
 
Since most Orange Pi One users cluelessly use OS images for Orange Pi PC and have not the slightest idea what's going on I fixed the fix-thermal-problems.sh script to differentiate between the older Orange Pis and the new Orange Pi One. The script checks the amount of available DRAM and if it's 512MB then it applies sane settings for Orange Pi One (no voltage switching since this is dangerous -- see above).
 
Anyone here with access to Orange Pi forums (me not -- I lost my logon credentials the 2nd time and this crappy forum doesn't send out password reset links!) should inform the users there that they should take care and that fix-thermal-problems.sh now is also able to cure Orange Pi One. Please spread the word and link to this thread.
 
1st note: Since most users have not the slightest idea what's going on on their SBC I tried to simplify installation of a small lightweight monitoring solution. If anyone wants to be able to simply monitor what's going on on his Orange Pi: In case a Debian based distro is used it's easier than anytime before: http://forum.armbian.com/index.php/topic/617-wip-support-for-the-upcoming-orange-pi-one/?p=5317
 
2nd note (mostly to the other Armbian devs): I also want to collect some feedback on this 'adjust script.bin on the fly' approach since the h3disp utility we develop should be able to run not only on Armbian but on most of the images currently used with any Orange Pi model. We try to improve and not to force someone to use a specific distro/image

Start to code? Here you find adoptions that enable these 4:3 resolutions: https://github.com/dni1337/OrangePI-Kernel/commits/master
 
But these new definitions should not overwrite existing resolutions but instead add more modes to be used. The same would help with A64 since the BSP 1.2 kernel used there (based on kernel 3.10.x) uses same code and it's also the same HDMI controller inside.
 
BTW: Currently in an very early stage and 'work in progress': https://github.com/longsleep/sunxi-disp-tool
 
But we should switch to this tool later on sun8i since this will save the reboot to change resolution. Longsleep wants to try out higher resolutions than 1080p today, maybe we need more memory reservations for framebuffer then. But at least there's some progress regarding different display resolutions and switching between them.

The reason is simple. If you insert a card when the board boots the H3 will always search for a bootloader there. If you insert the card later it won't be recognized (which might be able to be fixed by playing around with /proc/driver/sunxi-mmc.x/insert).
 
So to boot with inserted SD card the bootloader has to remain there and point to the rootfs on the eMMC (the numbering of devices will then also change!). This can be done by using our nand-sata-install.sh script and then not wiping out the SD card but keep the 1st MB intact and only adjust the partition table so that the SD card can be used for data.

Addendum: Here you find instructions how to get the kernel to recognize an SD card that has been later inserted and that is correctly defined in script.bin as 'manual': http://lists.phcomp.co.uk/pipermail/arm-netbook/2013-October/009162.html

Warning: This whole thread is only about historical information now since it's 2018 and we can buy inexpensive and great performing A1 rated SD cards in the meantime. Buying anything else is a mistake so directly jump to the end of the thread for performance numbers and recommendations.
 
 
 
Edit: See an early 2017 update at the end of the thread regarding new SD specs also covering random IO performance.
 
Edit 2: Some thoughts/observations on lifespan/reliability of SBC storage: http://tech.scargill.net/a-question-of-lifespan/ (see also/especially the comments there)
 
Edit 3: CNX Software picked up recent performance reports (eg. by Andreas Spiess) and other important issues around SD cards: http://www.cnx-software.com/2017/06/13/micro-sd-cards-for-development-boards-classes-tools-benchmarks-reliability-and-tips-tricks/
 
Edit 4: See an early 2018 update testing real world A1 performance class products at the end of the thread.
 
Edit 5: See here and there for some rather boring but very important information about Armbian's tries to prevent SD cards wearing out too fast.
 
 

 
Preparations:
 
I tested 8 different SD/TF cards under identical conditions. I created an Armbian 5.07 image to be used on Banana Pi (A20 SoC with 4.4.6 kernel, ext4 rootfs (Armbian defaults == no journal), 960MHz scaling_max_cpufreq, scaling_governor == performance. All test runs were done using 'iozone -e -I -a -s 100M -r 4k -r 16k -r 512k -r 1024k -r 16384k -i 0 -i 1 -i 2' and monitored using 'sudo iostat 5' for anomalies (none detected).
  Kernel version matters (since with Allwinner's 3.4 kernel sequential throughput is limited to ~16MB/s, with mainline kernel we get close to Banana Pi SDIO implementation's max: ~23MB/s) and filesystem settings matter too (enabled journal for example slows down 4K writes a lot).   Sequential speeds:     Random I/O:     The 4 Samsung cards were bought within the last 3 weeks and manufactured between 09/2015 and 12/2015 according to the card's metadata. Interesting observation: I used three of these cards the first time and they all show identical behaviour especially regarding writes with small record sizes: pretty slow in the beginning and getting faster over time (the Samsung Pro for example started with only 1400KB/s 4K writes and 3 runs later the same test showed 3270KB/s -- maybe an indication that some sort of calibration happened. Anyway: I know why I always repeat tests and do not rely on a single test run)   Sequential speed mostly irrelevant / random I/O differs and matters a lot!   The SanDisk Extreme Pro has been bought nearly 3 years ago. This card shows superior sequential read/write performance compared to the three Samsung EVOs. But only when used in combination with a host that can make use of these speeds. My MacBook writes 4 times faster an OS image to the Extreme Pro compared to the EVOs. But this doesn't matter at all since the SDIO implementation of the board in question is limited to ~23MB/s (50MHz @ 4 bit). The same sequential write/read speed limitation applies to most SBCs since to be able to exceed this slow mode the voltage the SD/TF card is fed with would've to be adjusted (default 3.3V, the faster modes require a dynamic switch to 1.8V instead which some/most SoCs can perform but if the SBC vendor doesn't implement this you're limited to ~23MB/s).   Therefore cards labeled as being capable of "up to 90MB/s" do not perform different than those that can only do "up to 20MB/s" as long as we're talking about sequential transfers since the SD card interface is already the bottleneck. But since we're using SD/TF cards not in cameras but as storage media for the rootfs of an SBC something different is more important: Random I/O. And here performance of cards that are labeled identical ('class 10' for example) differs a lot.   All 4 Samsungs outperform the other cards easily in this area. The SanDisk Extreme Pro can not compete regarding random I/O compared to superiour (but mostly irrelevant) sequential transfer speeds. And funnily the 3 other cards show horribly slow random write performance, especially with 16k record size. According to card metadata the 2 Intenso are oemid 0x5048 / manfid: 0x000027 (cheap crap known to die way too early) and I would believe the SanDisk 'class 10' card is a fake or at least uses the same controller as the 2 Intenso since 16K random writes are also way slower than 4K writes.   Detailed results (summary table also available as .ods, .xlsx or .txt):   Samsung Pro 64GB (brand new) http://sprunge.us/DEYd   Samsung EVO+ 64GB (brand new) http://sprunge.us/NLQd   Samsung EVO+ 32GB (brand new) http://sprunge.us/heGL   Samsung EVO 64GB (already used some time) http://sprunge.us/DUOS   SanDisk Extreme Pro 8GB (already used some time) http://sprunge.us/ZPFZ   SanDisk 'Class 10' 8GB (already used some time) http://sprunge.us/OHjT   Intenso 'Class 10' 16GB (already used some time) http://sprunge.us/LUMZ   Intenso 'Class 4' 4GB (already used some time) http://sprunge.us/GbAY   Some updates from Igor (still showing superiour EVO results but the clear winner is ODROID's eMMC module with SD card adapter):   Transcend Premium 300x 16GB (almost new) http://sprunge.us/UcSD  
 
 
Sandisk Extreme Pro 8Gb (almost new) http://sprunge.us/aDJJ
 
 
 
Hardkernel eMMC 8G via SD reader (brand new) http://sprunge.us/SHXF
 
 
 
Sandisk Ultra 8Gb (old and very used) http://sprunge.us/OWZf
 
 
 
Sandisk 8GB (almost new) http://sprunge.us/iViT
 
 
 
Sandisk 8G (new) http://sprunge.us/XHjj
 
 
 
Transcend 8Gb (used) http://sprunge.us/NTRT
 
 
 
Samsung EVO 32Gb (brand new) http://sprunge.us/bTQh
 
 
    Further readings: http://www.bunniestudios.com/blog/?page_id=1022 http://thewirecutter.com/reviews/best-microsd-card/ http://www.jeffgeerling.com/blogs/jeff-geerling/raspberry-pi-microsd-card http://www.bradfordembedded.com/2014/05/flashbenching/ Conclusions:
If the board's SD card interface is the bottleneck since it's not supporting the faster SDIO modes using expensive cards that exceed the interface's maximum sequential bandwidth is useless. An expensive Samsung Pro Plus won't be faster than a way more cheap EVO when it's about sequential transfer speeds since you will stay at ~22MB/s anyway Sequential read and especially write speeds are all the SD association's speed ratings are about (to ensure reliable recording of videos/images in cameras/recorders) When an SD card is used in an SBC sequential speeds aren't that important. It's all about random I/O, especially with small block sizes (reading and writing small random chunks of data from/to the card) No commonly used 'random I/O' speed ratings exist so you have to check the card in question prior to usage or rely on appropriate benchmarks (see the two links directly above). Again: the 'speed class' won't tell you anything. You can get two different 'class 10' cards that differ by 500% or even more regarding real world storage performance (again: random I/O matters). In the example above the Intenso 'class 10' card is 385 slower compared to the EVOs when it's about 16K random writes (good luck if you have a database running that uses this page size) Interestingly more expensive cards are outperformed by cheaper ones (the EVOs show a better overall performance compared to the Samsung Pro since sequential speeds are limited by the interface) One extreme example: Using an identical cloned installation that was somewhat outdated on the small 4GB Intenso card and on the 64GB EVO resulted in the following times for an 'apt-get upgrade' (+200 packages): EVO less than 6 minutes vs. 390 minutes (yes, ~6.5 hours) with the Intenso. The time to finish depends largely on fast random writes. It's easy to test the card in question when running Armbian since we ship with iozone. Therefore simply execute the iozone call from the first paragraph after logging in as a normal user. Starting with Armbian 5.06 a even better method exists that also tests the whole card for errors: armbianmonitor -c will report precisely both performance and health state of your card

And Gentoo, OpenSuSE, CentOS, Fedora and maybe a few hundred other Linux distro variants that might run on armhf/arm64 hardware. What's this whole thread about?
 
BTW: Armbian is different. It's not just another boring Linux distro (since then you could also use the plain Debian or Ubuntu stuff) but it's an automated build system capable to use Debian/Ubuntu and the images created in the end are the result of developing this build system over the years combined with a lot of knowledge regarding 'how to do it right'.
 
You won't have fun with this small ARM boards if not every detail here and there matches perfectly. And that's what Igor started with and what the Armbian team still tried to provide.
 
Basically three parts are involved: bootloader stuff (currently that's proprietary SoC specific bootloader stuff + u-boot, later we might have to deal with UEFI on aarch64), the kernel and the rootfs containing a Linux distro. The last part is the most irrelevant/boring one, the two former are way more important. As an example: sometimes kernel stuff won't work if hardware isn't initialized correctly already by u-boot and so on. That's what Armbian is about: Doing things right. And the distro used is close to irrelevant (the Armbian build system currently also allows to replace the whole OS distro in the last step with some other armhf/arm64 Linux rootfs -- somewhat weird but it works and would in many cases provide superiour results compared to 'original ARM Linux images')

And Gentoo, OpenSuSE, CentOS, Fedora and maybe a few hundred other Linux distro variants that might run on armhf/arm64 hardware. What's this whole thread about?
 
BTW: Armbian is different. It's not just another boring Linux distro (since then you could also use the plain Debian or Ubuntu stuff) but it's an automated build system capable to use Debian/Ubuntu and the images created in the end are the result of developing this build system over the years combined with a lot of knowledge regarding 'how to do it right'.
 
You won't have fun with this small ARM boards if not every detail here and there matches perfectly. And that's what Igor started with and what the Armbian team still tried to provide.
 
Basically three parts are involved: bootloader stuff (currently that's proprietary SoC specific bootloader stuff + u-boot, later we might have to deal with UEFI on aarch64), the kernel and the rootfs containing a Linux distro. The last part is the most irrelevant/boring one, the two former are way more important. As an example: sometimes kernel stuff won't work if hardware isn't initialized correctly already by u-boot and so on. That's what Armbian is about: Doing things right. And the distro used is close to irrelevant (the Armbian build system currently also allows to replace the whole OS distro in the last step with some other armhf/arm64 Linux rootfs -- somewhat weird but it works and would in many cases provide superiour results compared to 'original ARM Linux images')

And Gentoo, OpenSuSE, CentOS, Fedora and maybe a few hundred other Linux distro variants that might run on armhf/arm64 hardware. What's this whole thread about?
 
BTW: Armbian is different. It's not just another boring Linux distro (since then you could also use the plain Debian or Ubuntu stuff) but it's an automated build system capable to use Debian/Ubuntu and the images created in the end are the result of developing this build system over the years combined with a lot of knowledge regarding 'how to do it right'.
 
You won't have fun with this small ARM boards if not every detail here and there matches perfectly. And that's what Igor started with and what the Armbian team still tried to provide.
 
Basically three parts are involved: bootloader stuff (currently that's proprietary SoC specific bootloader stuff + u-boot, later we might have to deal with UEFI on aarch64), the kernel and the rootfs containing a Linux distro. The last part is the most irrelevant/boring one, the two former are way more important. As an example: sometimes kernel stuff won't work if hardware isn't initialized correctly already by u-boot and so on. That's what Armbian is about: Doing things right. And the distro used is close to irrelevant (the Armbian build system currently also allows to replace the whole OS distro in the last step with some other armhf/arm64 Linux rootfs -- somewhat weird but it works and would in many cases provide superiour results compared to 'original ARM Linux images')

A month ago it worked but I've no clue whether it still does. You can try it out yourself but need a serial console anyway (no HDMI support currently): Armbian_5.10_Orangepih3_Debian_jessie_4.6.0-rc1.7z
 
At least I won't look into it until 4.7 (and the THS patches ready, without working thermal throttling it's somewhat dangerous to encourage people to run mainline kernel on H3 -- please keep that in mind)

BTW: The FriendlyARM folks were the only paying attention to this security flaw and now do it exactly that way: https://github.com/friendlyarm/h3_lichee/commit/5d4d02b1c8f336ba002eed4d97dee3a51ea76cdd

8G Class4

The english readme is ready: https://github.com/usboot/USBootPi

Hi, both posts updated with a photo. I bought both cards during 2015 and I now realized that they were manufactured during 2012 and 2013.
When it comes to desktop use (i.e. "not headless"), Toshiba exceria is much more responsive and also much faster with software updates.
If you think that these posts are "useless" even for future reference, let me know and I can delete them.

BTW: The FriendlyARM folks were the only paying attention to this security flaw and now do it exactly that way: https://github.com/friendlyarm/h3_lichee/commit/5d4d02b1c8f336ba002eed4d97dee3a51ea76cdd

Commit logs exist
 
 
 
 
This is still work in progress, please do not publish pre-release images since user feedback at this stage isn't helpful (maybe Zador corrects me but I would believe we should first test everything internally and wait for Xenial to be released)

This security flaw has been proudly produced by Allwinner itself: https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/arch/arm/mach-sunxi/sunxi-debug.c
 
As Zador explained there might be good reasons to enable/use something like this while developing, the real problem ist that none of these devs does really care about Linux and 'productive use' (and security at all). That's one of the reasons no one wants to use these BSP kernels since you never know how many surprises like this are hidden in there.
 
Fortunately mainlining efforts for H3 are still progressing nicely so we can throw this Allwinner 3.4 crap in the bin rather sooner than later

The bug could be fixed easily if you've an Ubuntu 14.04 virtual machine up and running (you could use Zador's work to patch the M3 BSP linux kernel source). Let's see when/whether they react on the issue I opened. Normally this is stuff that has to be fixed within 24 hours.
 
And regarding 'terrible design'. Yeah, but that's just one of the many design flaws. Using Micro USB for DC-IN on the first production batch was the biggest mistake, the choice of the ultra slow GL830 USB-to-SATA bridge is insane, connecting both internal USB hub and the GL830 to one single USB host port (so that 'SATA disk' and all USB ports have to share bandwidth instead of connecting the GL830 to the 2nd USB host port like Cubietech did on their Cubietruck +) is also close to unbelievable. Also not preparing a heatsink like Hardkernel does it on ODROID C1+/C2 is just moronic with a SoC like A83T.
 
The only real use case for this board could be lightweight web services where the octacora SoC could shine. 2017 when mainline kernel support might be ready. At least the Foxconn people (who started the Banana journey) start to understand. They met up with one of the linux-sunxi devs last week and send out board developer samples to real developers now

EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!
 
 
 
It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:
echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.
 
This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
 
We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue) FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1 SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10 SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1 Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2 LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3 Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).   In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)

EDIT: This is NOT about a (hidden) backdoor but just a local privileges escalation that affects one single 3.4 kernel variant for 2 Allwinner SoCs. In case you came here through lurid headlines please read this comment here first and help stop spreading further BS like "all Allwinner devices contain a hidden backdoor" -- the code has been found since Allwinner could be convinced to open their Github repos in the past so everyone is able to audit their Android kernel source!
 
 
 
It has been brought to our attention two days ago on 2016-04-30 in linux-sunxi IRC that Allwinner's 3.4 legacy kernel for H3/A83T/H8 contains a nasty local privileges escalation. Any process running with any UID can become root easily by simply doing this:
echo "rootmydevice" > /proc/sunxi_debug/sunxi_debug Combined with networked services that might allow access to /proc this means that this is also a network enabled root exploit. As usual we fixed such an issue within a few hours, on May 1st new Armbian 5.10 images were rolled out and in the meantime the fix is also in Armbian's apt repo so please upgrade now (apt-get update/upgrade or start with a fresh OS image) if you're affected! If you're already running Armbian 5.10 then this vulnerability is already fixed.
 
This security flaw is currently present in every OS image for H3, A83T or H8 devices that rely on Kernel 3.4: this applies to all OS images available for Orange Pis (except Armbian 5.10 available since May 1st), any for FriendlyARM's NanoPi M1, SinoVoip's M2+ and M3, Cuebietech's Cubietruck + and Linksprite's pcDuino8 Uno
 
We informed all vendors where possible also two days ago (FriendlyARM and SinoVoip took notice, the others still ignore the issue) FriendlyARM: https://github.com/friendlyarm/h3_lichee/issues/1 SinoVoip M3: https://github.com/BPI-SINOVOIP/BPI-M3-bsp/issues/10 SinoVoip M2+: https://github.com/BPI-SINOVOIP/BPI-M2P-bsp/issues/1 Cubietruck +: https://github.com/cubieboard/Cubietruck_Plus-kernel-source/issues/2 LinkSprite pcDuino8 Uno: https://github.com/pcduino/pcduino8-uno-kernel/issues/3 Users of any of the available OS images for H3 based Orange Pis are somewhat lost since none of the OS images or kernels used for these are maintained any longer. Loboris disappeared (so the opened issue is more like a reference) and Xunlong themselves do not maintain their software at all (not even possible to open an issue there).   In case some readers here do also have accounts at Orange Pi forums, please spread the word and inform the users that their OS images are exploitable unless they already use Armbian 5.10. Same applies to Banana Pi forums, please spread the word there also that all M3 and their M2+ OS images are affected (I deleted my account there since talking to @sinovoip is like talking to a wall and just makes me sick, but it might be worth the efforts to try to warn their users)

Amazing. You looked at an image where a chip is shown that is 14x14mm in size and don't get the idea that these solder points nearby have to be rather tiny?
 
And now you're searching in a software forum (Armbian you know) for tutorials how to improve your soldering skills since you tried to save $5 and ended up with the wrong device for your use cases? Really?

IR Receiver:
 
 

 
All credits go to "@GUTEK@ the greatest artist on planet" who created this wonderful masterpiece of art. For a detailed description have a look below.

Tutorial for ili9325 and spfd5408

 
soon tutorial for fastes ili9341

Again: What are you talking about? Armbian does not support Banana Pi M3. If you use the insanely broken Armbian rip-off 'Team BPi' provides then please ask them what they fucked up (but since they fucked up so many things in all of their crappy OS images they obviously have no clue which skills they lack   )

Another update on the great 'development efforts' 'Team BPi' shows. A few hours ago they finally managed to add 1-wire support to their kernel tree for the Banana Pi M3.
 
Missing 1-Wire support was brought to their attention several times through their forums in the last months, a user provided the necessary driver as pull request for the M2 back on 3rd Dec., it took them only 24 days to merge this pull request (hard work you know?), and then just additional 19 days to get the idea to activate 1-wire for Banana Pi M3 also.
 
What does this mean for unfortunate M3 customers already using their OS images? Simply nothing since 'Team BPi' still provides no kernel/u-boot update routines. Most probably they will release a couple of new fishy OS images the next days/weeks that suck not that much any more. But it's still close to unbelievable they don't provide an online update routine so users can benefit immediately from fixes to their BSP they commited on Github.
 
We've told them so many times how easy it is to achieve this but they still don't care about anything else than selling their hardware and tricking users into believing some sort of development/support progress would be made.
 
Same with the issue kometchtech brought to our and their attention (adding "init=/bin/systemd" to the bootargs which is necessary for every OS image that makes use of systemd -- and these are a lot). This is something they should've to adjust in sunxi-pack/chips/sun8iw6p1/configs/*/env.cfg but they refuse to and provide countless crappy OS images that all do not fully work instead.

Yes, no PMU/PMIC --> no battery support. I'm still curious whether we'll see a quad core A20 successor this year (similar performance as H3 but with AXP209 PMU support and SATA -- best choice for a small server IMO).
 
In the meantime Xunlong announced a few more boards, the OPi Plus 2E being also quite interesting for server tasks. H3 combined with SY8106A as usual, 2 GB DRAM, 16 GB eMMC, 3 available USB2.0 host ports like on OPi PC (fortunately no USB hub used and no USB port wasted for an USB-to-SATA bridge, that means you can benefit from 3 USB host ports that do not have to share bandwidth!) and some onboard WiFi accessible through SDIO.
 
Xunlong charges $35 for the board and we know already everything regarding software support: All we have to do is to combine a few bits from fex/.dts stuff for Orange Pi PC and Plus and we're done: Full Armbian support out of the box.