Werner

@kamma @martinayotte @Igor Thanks - was a nice teamwork

I've tested latest above values by StabilityTester running 100 times, this gives few errors for 1488 and 1640 MHz.
After increase voltage by 10 for both, StabilityTester run 100 times without error.
So, finaly:
MHz 1080 1320 1488 1640 1800 mV 880 880 940 990 1050  
I've made PR to master with this.

Giving power to wrong people is even harder problem. @Piersandro was contacted in person a week ago but he didn't respond. There is nothing more to add on this topic.

Thanks, the OPi 0+ H5 looks perfect. I ordered one.

What about OPi 0+ H5?
 
Offering GBE, 64bit quad core, officially supported by Armbian and dirt cheap
https://www.armbian.com/orange-pi-zero-plus/
https://www.aliexpress.com/item/Orange-Pi-Zero-Plus-H5-Chip-Quad-Core-Open-source-Cortex-A53-512MB-development-board-beyond/32828347476.html?spm=a2g0o.cart.0.0.68e43c00J6oKjx
 
If you need even more power staying at low price, could accept the sacrifice in reliability and get a PCIe which is broken by design you can go for a H6 based board like OrangePi OnePlus. The H6 SoC is clocked with 1,8 GHz. All H6 boards are still in development stage and do not come with support.
I have two OPi 1+ running about since when they were released and besides the very first issues like not having ethernet working they now are working quite well for me.
 
If unsure go for the H5 SoC.

please read this thread and understand the limitations of the espressobin... and its current stability

Just as a side note : you can also do the reverse, installing Ubuntu as you main OS and use VirtualBox to run Win10 inside a VM ...

What about OPi 0+ H5?
 
Offering GBE, 64bit quad core, officially supported by Armbian and dirt cheap
https://www.armbian.com/orange-pi-zero-plus/
https://www.aliexpress.com/item/Orange-Pi-Zero-Plus-H5-Chip-Quad-Core-Open-source-Cortex-A53-512MB-development-board-beyond/32828347476.html?spm=a2g0o.cart.0.0.68e43c00J6oKjx
 
If you need even more power staying at low price, could accept the sacrifice in reliability and get a PCIe which is broken by design you can go for a H6 based board like OrangePi OnePlus. The H6 SoC is clocked with 1,8 GHz. All H6 boards are still in development stage and do not come with support.
I have two OPi 1+ running about since when they were released and besides the very first issues like not having ethernet working they now are working quite well for me.
 
If unsure go for the H5 SoC.

You need to install DT compiler from : http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_arm64.deb
 
Backup /boot/dtb/rockchip/rk3399-rockpi4b.dtb into /boot/dtb/rockchip/rk3399-rockpi4b.dtb-ORIG
 
Decompile the DTB into DTS :
dtc -@ -I dtb -O dts -o rk3399-rockpi4b.dts-4.20.0 /boot/dtb/rockchip/rk3399-rockpi4b.dtb Edit the file rk3399-rockpi4b.dts-4.20.0 by changing all the serial node from "disabled" to "okay", then recompile DTB :
dtc -@ -I dts -O dtb -o /boot/dtb/rockchip/rk3399-rockpi4b.dtb rk3399-rockpi4b.dts-4.20.0  

This is/was a limited edition (6pcs, two already broken) gift by TJoe @Code4Sale LLC He made them for Ohio Linux fest:

This already works with 5.1 if armbian is still using my kernel patches. All that's needed is putting firmware in /lib/firmware.

Maybe later ... I don't want to get indigestion doing too much branch switching ...

None of my 12 card have one too. I've never seen that message ...
But googling this message reveal that people were facing either corruptions or defects.
Try another card, it will help to figure out !

There you go: 
 

because new user write into the dev forum instead of  review their own actions and look for a solution.
Because of that there is an own section in the forum:
Board doesn't start
 SD card and PSU issues
Or if you want to read a current posting that goes in that direction.
 
So until you have gathered some basic experience,  supporting others,  you are blocked from writing to the dev forum, but everywhere else is open.
If you are here for a couple months on a regular basis, you will understand.
 

I made several test builds and tests installs on Debian Buster and IMHO it is ready for user level/extended testing. Most interesting for us is that our modifications and things defined in armbian-config remain working. Most of them will, but some will fail ... I did install a desktop over Buster, it works, but haven't done many tests, hostapd works (but it throws out some errors that need to be examined, ...)

Ubuntu Disco is in a similar state. CLI works, desktop upgrade works, ...

How to extend this testing? Shell all nightly images only be Buster/Disco, most popular boards gets a CLI test version? Exotic ones? "Chosen" ones? Shell we unlock building but leave a mark "WIP" or something?

added &mmc2 section into ****nanopi-neo.dts
from folder /usr/src/build/cache/sources/u-boot/v2019.04 run
"git diff arch/arm/dts/sun8i-h3-nanopi-neo.dts > /usr/src/build/patch/kernel/sunxi-dev/my-neo-emmc.patch"
from /usr/src/buid run ./compile.sh
...
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
reboot without SD - fault
 
BTW. ***nanopi-neo.dts hasn't &mmc2 section again. Looks like patch wasn't applied. 
 
I've copied .diff file to the same folder as Igor's destination: ./patch/u-boot/u-boot-sunxi
from /usr/src/buid run ./compile.sh
...
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
and 
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1p1 bs=1024 seek=8" (I'm not sure but I did it)
 
reboot without SD - SUCCESS!!!
 
Thank you martinayotte&Igor for your support
 
P.S.
last (I hope) doubt....
"dd if=/tmp/u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8"
this command will copy a .bin file into the root folder on eMMC... how it will be read by system during the load?
no .bin files in SD-card's nor "/boot" folder nor "/ "folder
current configuration: ls /dev | grep mmcblk
mmcblk0
mmcblk0p1
mmcblk1
mmcblk1boot0
mmcblk1boot1
mmcblk1p1
 

Changed posting permission - one need 10 5 posts to post in RK3399 or Allwinner H6 forums.  

Orangepi PC2 is a good board and would be much safer option since support is fairly mature, while (any) H6 still has many glitches and is still under development.

It is not actually provided in any DT nodes ...
I will add it in the following days, directly in main DT, without any needs for overlay.
Then, you will need to take a new nightly image ...

This is not Armbian since there is no Armbian for this board. Only test build which were not done for you, but for experienced developers, which will not request support, but perhaps fix things. Big difference. We can't help you anything with having a good "Armbian" experience at this point. Not possible. Get a board, that is supported.
 
 
This is normal for a hardware where "half" of the missing component is not even developed. Development = thousands of working hours and not something you can download freely from the internet and install. Simple questions, like "how to use wireless" might be easily related with huge time and money costs. Not to mention time lost to clarify this "every day", since there are always people, who never read welcome text on those test images.
 

Send some. A very needed component for development and dealing with "customers"  

Bottom line. If you are not a developer, read and wait, wait until it gets to users level. We are still months away. 

Are you really considering building an madm RAID with USB drives?
Technically it is possible but I doubt you'll get anything but problems with reliability.
It's easier than you may think to compile yourself - check out https://docs.armbian.com/Developer-Guide_Build-Preparation/
If you're looking to 'play' with mdadm as a learning exercise then fine, but if you really value your data I'd suggest you should build a 'proper' raid using an x86 board and good quality SATA drives.
On budget SoC boards I'd just rsync my precious data across several physical drives.
 

Now this is last one - others broken ones were removed + nightly building has been disabled.

Latest one from the download should boot, but upgrade will break it most likely.

Support in modern kernel was made virtually from scratch. There is little in common between 3.4.y and 4.19.y

Strangely, I've put back the original DTB and it still working ...
I will try again with a "virgin" image.
 
EDIT : I took another SDCard, reburned 5.0.10, and this time, although still showing those "cpufreq" error, it booted successfully, although "filesystem resize" took more time than usual ...