AndrewDB

I would like to announce that I am getting started on an armbian-derived project, Armbian-NG. This is not a fork of Armbian, nor a rewrite, it's a derived project that piggyback's on the excellent work by Igor and the entire armbian development team. I think of Armbian-NG as armbian's little clumsy brother, who is just learning to walk but has great potential. 
In as few words as possible, Armbian-NG will be a Python (set of) script(s) that runs natively on Aarch64 (64-bit ARM) hardware (running Ubuntu 18.04 or later) to build Armbian images. More details  can be found here: https://github.com/AndrewBCN/Armbian-NG
 
As with armbian, anybody is welcome to contribute with code and ideas to Armbian-NG. And since no project is worth its storage space without a logo, Armbian-NG already has one. 

I would like to announce that I am getting started on an armbian-derived project, Armbian-NG. This is not a fork of Armbian, nor a rewrite, it's a derived project that piggyback's on the excellent work by Igor and the entire armbian development team. I think of Armbian-NG as armbian's little clumsy brother, who is just learning to walk but has great potential. 
In as few words as possible, Armbian-NG will be a Python (set of) script(s) that runs natively on Aarch64 (64-bit ARM) hardware (running Ubuntu 18.04 or later) to build Armbian images. More details  can be found here: https://github.com/AndrewBCN/Armbian-NG
 
As with armbian, anybody is welcome to contribute with code and ideas to Armbian-NG. And since no project is worth its storage space without a logo, Armbian-NG already has one. 

amirul@rk3328:~/puppeteer-core$ uptime 01:32:40 up 7 days, 1:19, 2 users, load average: 0.81, 0.94, 0.95 amirul@rk3328:~/puppeteer-core$ uname -a Linux rk3328 4.4.154-rk3328-tv #9 SMP Thu Mar 14 16:46:17 MSK 2019 aarch64 aarch64 aarch64 GNU/Linux Yes these TV boxes are amazing. I have one still up after 7 days despite temps hitting 100 C at times
and @balbes150 work is phenomenal. Genius 

It should be. u-boot-2018 does not support USB Burn Tool (I warned all about this). Also, u-boot-2018 can not run external systems from USB media, you need to use only the SD card. You should only write u-boot-2018 to eMMC when you know exactly what you need it for. For other cases, you need to use the installation with the preservation of the standard u-boot-2015 (use the installation script install.sh).
 
To make USB Burn Tool work you need to erase u-boot-2018 in eMMC. For example to run the command "dd if=/dev/zero of=/dev/mmcblkX bs=1M count=4M" (Replace X with the number of your eMMC).
 

andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uptime 13:43:47 up 39 days, 14:22,  1 user,  load average: 0.00, 0.01, 0.00 andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uname -a Linux m9cmax4k 4.19.7-aml-s9xxx #5.67 SMP PREEMPT Fri Dec 28 10:16:25 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux 39 days uptime.
Ubuntu 18.04 running from eMMC. I practically never have to reboot this box (used as a file server with a USB hard disk), it is that good.
As always, I am grateful to Oleg and the entire Armbian development team for their amazingly good work.  
 

Mecool Km8-P 2G/16G working with Armbian 5.76 Debian stretch default 5.0.0 on eMMC.

=> Had to put android 6 image with old bootloader first.
=> Exclusively boot on SD not USB.
 

Great! The more modern kernel, less things will work is normal. Drivers and board hardware config (DTB) once developed for initial kernel (4.4.y in this case) has to be ported to modern kernel (not just enabling in menu config). I don't know how much has been already done so it is hard to say ... in general don't expect anything better than 4.4.y except perhaps some very specific functions.

Actually, you can natively build an Aarch64 Rockchip kernel very easily.
 
Instructions to do so can be found here:  http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-howto-native-compile-kernel
 
You'll have to modify a couple of steps slightly if you are building for Rockchip SoC's but basically it's a 10 minutes process to get started on compilation, and depending on your hardware your kernel will compile in 15 to 45 minutes. Another 5 minutes to spend on installing and voilà! You can run your own self-compiled mainline Linux kernel on your SBC, if it manages to boot properly but note that this is not guaranteed on Rockchip SoC's.

Had a look at the thread and came to the conclusion that the build is REALLY beyond me. I'll just go back to tweaking FREETYPE_PROPERTIES in /etc/environment & chrome://flags 

andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uptime 13:43:47 up 39 days, 14:22,  1 user,  load average: 0.00, 0.01, 0.00 andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uname -a Linux m9cmax4k 4.19.7-aml-s9xxx #5.67 SMP PREEMPT Fri Dec 28 10:16:25 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux 39 days uptime.
Ubuntu 18.04 running from eMMC. I practically never have to reboot this box (used as a file server with a USB hard disk), it is that good.
As always, I am grateful to Oleg and the entire Armbian development team for their amazingly good work.  
 

andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uptime 13:43:47 up 39 days, 14:22,  1 user,  load average: 0.00, 0.01, 0.00 andrew@m9cmax4k:~/Benchmarking/Linpack/hpl-2.1/bin/Aarch64$ uname -a Linux m9cmax4k 4.19.7-aml-s9xxx #5.67 SMP PREEMPT Fri Dec 28 10:16:25 MSK 2018 aarch64 aarch64 aarch64 GNU/Linux 39 days uptime.
Ubuntu 18.04 running from eMMC. I practically never have to reboot this box (used as a file server with a USB hard disk), it is that good.
As always, I am grateful to Oleg and the entire Armbian development team for their amazingly good work.  
 

For anyone coming across this: Removing the symlink didn't work for me on Espressobin, but the following did:
systemctl stop serial-getty@ttyS0.service  

cd /etc/systemd/system/getty.target.wants rm serial-getty*ttys0 You gotta disable the service by e.g. removing the symlink like shown above. Don't remember the exact name of the symlink in getty.target.wants, so if the rm doesn't work, find out and use the correct name ;). For me disabling the service like that works (you can also try with systemctl disable), but don't blame me, if it doesn't work for you...

That was an excellent tip, thank you very much! 

Then we have a getty service running for ttyS0 and for ttyAML0 (if a serial console is operational). Then this should solve the problem: https://github.com/armbian/build/commit/3092295cb0513ea12d40ad5aa1d988b09945ec05
 

I haven't played with Armbian but ttyS0 is only present on Amlogic's kernel. On mainline kernel, it should be ttyAML0. It could be that there's no such device and the tty service is restarting due to it.

for more information about the versions of your armbian-system-packages you could add the following to your
/etc/update-motd.d/10-armbian-header
ARMBIAN_bsp=$(more /etc/armbian-release|grep VERSION|cut -f 2 -d '=') ARMBIAN_kernel=$(dpkg -s linux-image-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_uboot=$(dpkg -s linux-u-boot-$BOARD-$BRANCH|grep Version|cut -f 2 -d ' ') ARMBIAN_dtb=$(dpkg -s linux-dtb-$BRANCH-$LINUXFAMILY|grep Version|cut -f 2 -d ' ') ARMBIAN_firmware=$(dpkg -s armbian-firmware|grep Version|cut -f 2 -d ' ') ARMBIAN_config=$(dpkg -s armbian-config|grep Version|cut -f 2 -d ' ') printf 'ARMBIAN bsp : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_bsp" printf 'ARMBIAN kernel : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_kernel" printf 'ARMBIAN u-boot : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_uboot" printf 'ARMBIAN dtb : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_dtb" printf 'ARMBIAN firmware : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_firmware" printf 'ARMBIAN config : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_config" printf '\n' printf 'ARMBIAN kernel : \e[0;91m%s\x1B[0m u-boot : \e[0;91m%s\x1B[0m dtb : \e[0;91m%s\x1B[0m firmware : \e[0;91m%s\x1B[0m config : \e[0;91m%s\x1B[0m\n' "$ARMBIAN_kernel" "$ARMBIAN_uboot" "$ARMBIAN_dtb" "$ARMBIAN_firmware" "$ARMBIAN_config" printf '\n' this will give you the armbian-system-package-informations in different lines or
at the end in one line like in the attached image
 
 

@ning
It worked. Thanks.
 
@AndrewDB
So in the procedure for LePotato is enough to change:
"$FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0"
in:
"python $FIPDIR/acs_tool.pyc fip/bl2.bin fip/bl2_acs.bin fip/acs.bin 0"
and so the produced "u-boot.bin.sd.bin" boots.

see: https://github.com/armbian/build/pull/1310

here's some NFS boot breadcrumbs that arent armbian specific
 
but you'll need to update your initrams image with a few settings which uboot will pool.
 
see /etc/initramfs-tools/initramfs.conf  MODULES=netboot
 
also you'll want to set your rootfs  to be something like this
 
# UNCONFIGURED FSTAB FOR BASE SYSTEM /dev/nfs / nfs defaults 1 1 /proc /proc proc defaults 0 0 /sys /sys sysfs defaults 0 0 /dev/fd0 /mnt/floppy auto user,noauto,sync,exec,umask=000 0 0 /dev/cdrom /mnt/cdrom auto user,noauto,exec,ro 0 0 none /tmp tmpfs defaults 0 0 none /var/run tmpfs defaults 0 0 none /var/lock tmpfs defaults 0 0 none /var/tmp tmpfs defaults 0 0  

Because of the dmesg-error-Message 
[    9.557455] cfg80211: loaded regulatory.db is malformed or signature is missing/invalid I rechecked the regulatory.db and did found 2 more files to install 

1.) new pem-certificate ( sforshee.key.pub.pem <-- for signature )
2.) new regulatory.bin
 
In the archive 
http://ftp.be.debian.org/pub/software/network/wireless-regdb/wireless-regdb-2019.03.01.tar.gz
or at
https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/plain/
you could find the files:
regulatory.db
regulatory.db.p7s
regulatory.bin
sforshee.key.pub.pem
sforshee.x509.pem
 
copy 
from the archive directory wireless-regdb-2019.03.01 to:
regulatory.db        to /lib/firmware  regulatory.db.p7s    to /lib/firmware  regulatory.bin       to /lib/crda sforshee.key.pub.pem to /lib/crda/pubkeys/ (reboot)
[    9.519254] cfg80211: Loading compiled-in X.509 certificates for regulatory database  
wireless-regdb-2019.03.01.zip

No need to worry about this failure, if I remember, those clm blobs are used to determine countries and allowed channels...

Yes, I was going to say that too! Specially for open-source, the Amlogic S9XXX TV boxes and SBC's are vastly superior to the RPi's.
Check this FAQ: http://wiki.loverpi.com/faq:sbc:libre-aml-s805x-faq#toc6

Now RPI strongly loses in all respects to s9xxx and rk33xx TV boxes. The only place where the use of RPI is justified, systems that use a variety of external sensors and actuators, of which a large number are produced and there are ready-made systems for their use.
 
 
 
 LE did not use patches, but a ready-made closed binary module (driver), which was taken from the finished Android firmware. This binary module was built exclusively for one version of the 3.14 kernel and cannot work with any other versions of the kernel. The manufacturer of the chip does not give anyone the source code from this driver, so no one will spend their time disassembling the binary code and studying it to write a new driver for the kernel 4\5. If you want, you can do the job yourself.

The point, in case I wasn't clear enough, is that there is zero documentation and zero support from the S9082 vendor, and the development effort to reverse engineer a linux driver for such a chip is ridiculously high. So, no, I don't think there will ever be a driver for the 4.xx/5.xx linux kernels for a totally unsupported chip such as the S9082. Again, if you need Wifi on a box that uses such a chip, use a USB WiFi dongle.
 
Check this thread: https://forum.libreelec.tv/thread/5457-s905x-unknown-wlan-chip/