AndrewDB

I have been compiling the Linux kernel natively on some Amlogic TV boxes I have running Armbian. I can compile the Linux kernel in 44 minutes on an S912 box. Using distcc the time goes down to around 15 minutes. The distcc build farm is basically made up of Amlogic TV boxes connected with a 100mbps switch.
I have posted a HOWTO about distcc on aarch64 here: http://wiki.loverpi.com/specs:sbc:distcc-kernel-compile
 
It takes around two hours to build an image using Armbian on my Thinkpad-T420 with a relatively fast Internet connection, start-to-finish.
I expect Armbian-NG will take less than an hour to build an image using distcc on my low-cost build farm.
 

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. 

New image ver 5.82 S9xxx and Odroid N2

Good news. I checked the work Armbian on the model Beelink GT1 mini (S905X2). The system starts normally with dtb from x96max, works wired network, HDMI, BT, eMMC, SD and USB.

Seems that the entropy daemon haveged fails to start with recent kernels. I find that adding --data=16 to DAEMON_ARGS in /etc/defaults/haveged allows the daemon to start successfully.

add video=1920x1080 to the end of the bootargs line in /boot/uEnv.ini 

So you want to update the kernel? The way I do that is that I compile and install a kernel I download from Oleg's (balbes150) repository on GitHub. This has the advantage that I can configure the kernel to fit exactly my needs. Depending on your hardware you can also download, configure, compile and install an unpatched mainline kernel from kernel.org. Either way, you get exactly the kernel version you want with exactly the options you need.
 
BUT
 
If the kernel you already have installed and booting from eMMC is working fine, there is no reason to update.

Pay attention. To properly boot the system to SD card on Odroid N2 you need to switch the startup u-boot was installed on SD\eMMC. (that is, the position that is used in the release of equipment from the plant).

Are you trying to upgrade to a new Armbian release, a new Debian/Ubuntu release, or to a new kernel? Because these are three different things. And obviously there is a way to upgrade each of these.

I recommend adding a fan. It's easy to add (this is one of the reasons I paid attention to this model). The body already has a ready-made large hole. It is necessary to disassemble the body and remove the plug and can be easily placed on top of the fan size 90*90 with USB connection. If you use a smaller fan, you can leave the plug and make a hole of the desired size over the radiator.
 
Check for firmware. Libreelec runs all the hardware. Only the shutdown does not work (the system restarts).
 
I didn't check. Try dtb from other models.
 
The core has basic support for Khadas EDGE (the site has an image). I have a full XFCE desktop running on EDGE (no wifi and BT and sound only).
 
I have long been there, so @amirul was able to run Armbian.

TX3 mini - a (2gb 32gb)
Armbian_5.68_Aml-s9xxx_Ubuntu_bionic_default_4.19.13_desktop_20190110.img.xz
 
All good, Audio, bt, internet, usb-tethering, bluetooth hotspot. USB keyboard/ mouse works perfect.
No overheating issues, max 50.3c on 1hour 98% cpu-load
 
 

Now checked on Odroid C2 an image 5.76 with MALI and a media script, by a technique with replacement of u-boot, as for K2. 
Everything works fine. After installing the script, the standard browser began to play video 1080 full screen without brakes. MPV is just as easy to handle any full-screen video. Bonus has an in-house sound via HDMI. There is one caveat when configuring - it is necessary to specify the correct DTB option in the file for Odroid C2  "/extlinux/extlinux conf".
 
For those who don't know. The browser has a special additional link for a quick test of full-screen video.

BM8 s912 2Gb meson-gxm-q200.dtb
root@aml-bm8:~# uname -a Linux aml-bm8 5.1.0-rc1-aml-s905 #5.77 SMP PREEMPT Sun Apr 7 12:55:48 MSK 2019 aarch64 aarch64 aarch64 GNU/Linux update: T95Z Plus - s912 octacore 3gb ram 

Good news.
Build the first version of Armbian for TV box x96 max (S905X2).
While not working, sound via HDMI, WiFi. Test images on the site in the catalog S905X2.

setting->more settings->about device->update

Old kernel has build-in support for various acceleration, but:

- its old, overall low quality, support is long gone and could be/it is security problematic out of the box,
- 3D & video is (usually) closed source and can't be reused on modern kernel. Things must be written from scratch and this task(project) is measured in years and is related to thousands of R&D hours which usually nobody pays for,
- accelerations are tied to old fixed versions of Chromium (you can't update it) which represent yet another security risk,
 
We are focused towards open source, modern kernels (security and stability) and CLI usage. Video/desktop acceleration comes last in play.

are you using https://en.wikipedia.org/wiki/Travis_CI   on Github?

Do you use the Media Script from JMCC on it?
Did you try another browser? Armbian browser doesn't exist. You can try firefox or Vivaldi browser.
https://vivaldi.com/nl/blog/snapshots/vivaldi-2-3-rc-2-vivaldi-browser-snapshot-1440-37/
 
Or you using Stretch or Bionic? Did you try the other?

 

Just wanted to announce that Armbian-NG (https://github.com/AndrewBCN/Armbian-NG/) has been chosen as the OS to power the new CNX Election Meddling System (https://www.cnx-software.com/2019/04/01/introducing-cnx-election-meddling-system/).
 
Why? Because Python. 
 
Have a nice day and don't forget to vote!

Hi,
 
after reading the very entertaining thread regarding the BPI-W2 and the following opening of the bsp-kernel on github, I became curious and when prices dropped for the Lake-1-TV-Box, I decided to play around with it.
 
Without very much documentation there was a bunch of trial and error and still many things are not absolutely clear to me, but finally I could boot an armbian build today:
_ _ _ | | __ _| | _____ / | | | / _` | |/ / _ \ | | | |__| (_| | < __/ | | |_____\__,_|_|\_\___| |_| Welcome to ARMBIAN 5.68 user-built Ubuntu 18.04.1 LTS 4.9.119-rtd1295 System load: 1.49 0.74 0.31 Up time: 3 min Memory usage: 4 % of 1631MB IP: CPU temp: 46°C Usage of /: 11% of 7.2G [ General system configuration (beta): armbian-config ] New to Armbian? Check the documentation first: https://docs.armbian.com Thank you for choosing Armbian! Support: www.armbian.com  
This is still connected over the serial port and completely untested. I had to use the strange chained double-u-boot and load kernel and dtb manually (from raw sd card sectors), so it is not even close to alpha. But it seems, that this can be improved. 
 
I plan to make a repeatable build config, but do not expect some really usable stuff anytime soon.  The situation with the lack of mainline support was already discussed in the other thread and the future does not look very bright here.
This is more or less a personal playground at the moment. But if anyone is interested, you can leave comments or questions here.
 
Sticky part (updated 03-03-2019):
 
RTD1295-Devices:
      Tested: Lake 1 Home Cloud TV Box
      Untested: Beelink SEA 1, Zidoo X9s, Zidoo X8, Zidoo X10,  Probox2 AVA, WD My Cloud Home, ...
 
All development and tests thus far have been done on the Lake-1-TV-Box. It can not be ruled out, that the other boxes have other u-boot-versions/-configurations.
 
Prerequisites:
Mandatory:
Serial connection soldered to the PCB (to reach the u-boot-shell) and a suitable terminal software. Further information here: https://en.opensuse.org/HCL:Lake1 (I can not confirm that „SD rescan“ does not work. Only „fatls“ and „fatload“ never worked for me, that’s why raw sector reads are used.)
 

 
Recommended:
Access to a Windows-PC, a USB-male-to-male-cable and the knowledge to re-flash the device by yourself.
If you are not comfortable in doing this, DON’T DO IT!!! YOU CAN BRICK YOUR DEVICE FOREVER !!
 
Current installation process (booting from SD-Card):
Build a full-OS-image with armbian selecting „lake1“ from this fork: https://github.com/Staars/build. This will create an image with kernel image and dtb written to sectors before the root partition. The u-boot-build of armbian is not used. Write the image (using etcher) to an SD-card. For the moment we will not touch the eMMC of the target device and therefore will work as non-destructive as possible. This might change in the future and it should be no problem to implement a eMMC-only solution, but at the moment there is no solution in sight, that would let you dual-boot Android and Linux. Create a terminal connection to the serial pins of your target device and intercept the boot process immediately after power up to reach the first u-boot-shell. Now we have to edit the BOOTCMD the following way: env edit bootcmd sd read $kernel_loadaddr 800 954a; sd read $fdt_loadaddr a440 5d; env set bootargs earlycon=uart8250,mmio32,0x98007800 console=ttyS0,115200 noinitrd root=/dev/mmcblk0p1 rootfs=ext4  init=/sbin/init; b2ndbc; bootr env save  
           This is a relatively harmless operation and can be reversed with the insertion of 'bootr' in step 2.
           The Android-installation on the eMMC stays untouched.
 
   4. Now at every boot the device will initialize the SD (which can fail!!), load the image and dtb, change the bootargs and call the second u-boot, which then will (hopefully) boot the kernel. 
 
U-boot:
At the moment u-boot will be build, but not used. Because of bootloader encryption this will likely stay that way. We can build the fsbl-parts, but without the proper encryption the boot stops, when the first part (hw_setting) is loaded. 
A separated u-boot-fork at https://github.com/Staars/u-boot-rtd is used for the armbian build, but that does not really matter. We must use the vendor-u-boot and we can not do real scripting (no RUN-command) but only chaining of commands.
 
Kernel:
The starting point from Sinovoip was labeled 4.9.119, but this is very likely not the whole story. Some parts are even newer and some are probably older, given the fact that git-cherry-picking showed possible updates when used with the stable linux-4.9-branch below tag:4.9.119.
The additional phoenix drivers were partly integrated in the kernel-fork on https://github.com/Staars/linux-kernel-rtd/tree/latest_patched as an extra folder to keep them in one place.
If there should be really an adoption of this platform in the future, it might be a good idea to go the other way around and merge the soc-specific parts into a generic linux-4.9.-fork. This is a bit of work, but it should be possible.
The fork is currently patched to 4.9.174
New kernel fork started at https://github.com/Staars/linux-stable/tree/linux-4.19.y (not 4.20 because of LTS) and armbian build config updated.
 
DTS/DTB:
This is a minimal changed version for the banana-pi w2. 
 
Bluecore.audio:
I do not really know if this (audio firmware?) is useful outside of Android. It is written to the SD-Image (directly behind the DTB), but not loaded.
 
What works:
-SATA-port (incl. booting with /root on SSD with bootarg 'root=/dev/sataa1')
-WLAN (onboard 8821AU), but there are very short freezes every few seconds
-simple software install (i.e. OMV)
-reboot/restart works, but can take some time
-bluetooth
 
What does NOT work:
-bluetooth
-halt/restart
 
Things to do:
-waiting for someone, who confirms, that this is repeatable on other setups
-working on the DTS/DTB
-test Ethernet, USB
-HDMI-in/-out or graphics in general (very low priority for me)
-eMMC-only-install (must check first, where it is safe to write data)
-test 4.19 (functional regression expected)
 
Board_Pics:
 

Alpine Linux for S9xxx
 
https://forum.khadas.com/t/alpine-linux-for-amlogic-s9xxx/3040

Perhaps in the original Armbian uses its own logic of designation of the cores and the system being built I do not pretend to be true, but I try to stick to the logic of the Linux systems and "adult" distributions. In them, "default" means stable, proven, reliable in use, recommended for the average user. "DEV" is a future system that is being developed , can be improved, but can potentially contain bugs and is recommended for advanced users. "Next" is the analogy of the symbol of the Linux kernel, i.e. the image of the "next" Armbian uses the core of the "NEXT" Linux. So less confusion when comparing the user designations of the image and the kernel, which it has.  
 
PS I do not impose anything on anyone, it is only my personal opinion.

https://yadi.sk/d/Z3mh-PJdfuePiw
 
 

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.  
 

I'll keep posting the progress here.
Yes there are many ways to save a lot of time from one image generation to the next, by reusing files that are already downloaded or compiled.
I am also thinking about using a directory structure and configuration files identical to those of Armbian, so that people who are familiar with building Armbian images would be able to just switch over to Armbian-NG quite easily.
I also am having quite a bit of fun programming in Python again, after almost a decade of not writing a single line of Python.