Staars

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:
 

We all know there are several shortcomings which causes mess in the config files and prevent simple implementing of more complex scripting. In order to make build system future proof and to cleanup the exception mess, which is virtually everywhere, I decided to start working on a part of the build system. Now the concept works and it is not that far to be mad if idea is bad
 
packages/extras was moved into this, then board support package and (for now) Cubietruck and Tinkerboard hacks from config/sources/ All others have to be implement into packages and their scripts. It's one time job and it will be much easier in the future, with new boards or functions.
 
New board support packages are now broken into unlimited number of packages. Currently there are three main groups and already present logical packages. Most of present are tested and are fully operational. Mostly its copy/past with bug fixed here and there. Perhaps some bugs were made in this process, but in essence system works - for those two boards. Upgrade path is not determined yet - I only focused on packaging and installing. All those packages can be installed from freshly build ones or from the repository. Each package can have their own number and package is rebuild only if number upstream doesn't exists.
 
This RFC includes preliminary merge of @balbes150 TV boxes fork so it's ATM a bit messy. Cubietruck and Tinkerboard images were tested (Bluetooth briefly, audio need to check again), the rest is not prepared and it requires some manual work. I hope someone else, not just the usual suspects, will help doing this.
 
I will slowly move forward and keep it mergeable/synced with upstream.
 
This approach is more or less only a working proposal for changes. IMHO it's better than what we have now but not perfect.

(WIP) Readme with some more details https://github.com/armbian/build/tree/tvboxes/config/packages
 
You can try this by adding LIB_TAG="tvboxes"
 
Edit:
 
Skeleton is done, images can be build from this branch ... Most but not all of our current families and board specialities has been moved under this packaging system. I tested Cubietruck, RockPro, Tinkerboard. At least they works fine - checked for Bluetooth (TB/CB3) and video acceleration on Cubietruck.

TBD: adjust changes in armbian-config regarding desktop (nodm is gone, lightdm only with possible autologin) and kernel switching.

@JMCC Welcome to try adding perhaps Tinkerboard MM script as a new multimedia/something package. What shall be its name? If some 3rd party packages needs to be placed to the repository, put them here: https://github.com/armbian/upload
 
@gprovost mvebu family is not there yet, but if you got time it should be clear what to do? If not, I wrote lousy docs or scripting is more complicated as before  
 
@selfbg Added Olimex SOM204. Check when possible.

@zador.blood.stained Are packages relations alright? I hope they are future proof. Upgrade is planned from armbian-config and is actually optional. Older packages, except boot and kernel are no more.
 
@tkaiser cpufreq is not overwriting anymore, serial consoles are board property SERIALCON="ttyS0,ttyGS0", board config is reloaded right before packages building. Shell we move hardware-optimisations.sh to per board script? Changes should not affect OMV.
 
@Staars Z28Pro merged but untested
 
@lanefu @5kft @TonyMac32 .... check.

@balbes150 have a lot of work to move his scripting into the build engine. Helping him, testing, fixing, ... @all Check and join if you can.
 
beta.armbian.com can be switched to this new world order ASAP.

Expected merge due: 2/2019 ?

Happy 19!

Edit by lanefu 7/2019:

A project #1 has been created on github.   There are several tasks, which will be tracked as issues on the board.

I am not sure if this is what you want to know, but:

- Debian.org or Ubuntu.com officially does not support any of those boards/boxes,
- Armbian userspace has many small but vital performance or security adjustments,
- Armbian fancy some kernel development and a lot of its maintaining. Debian relies on upstream sources for ARM hardware which can be years behind and/or lack of many functions,
- Armbian userspace is lean, clean but 100% Debian (or Ubuntu) compatible
- many stock Debian bugs are fixed on the way, "better than original :)"
- a build system is a central part of this whole ecosystem. You can DIY. Debian much harder.
- dedicated support forums per boards/boxes
- plug and play vs. complicated install scenarios on Stock Debian
- unified development scenarios and user experience vs. mess of different setup instructions scattered all around
 
I must have forgotten many other important points

yes i've heard about the rock64 gbe problem, don't know if it was finally solved (pcb tracks timings), but i don't know about a global rk3328 GMAC interface problem.
So far i can't fault my z28pro Gbe, it has been running a torrent through vpn with continuous upload of 30-50Mbps and i haven't noticed any problem, nor any dubious log output..
 
i've done a short 6 min iperf test :
 
i also transfered approx 750GB of real data to an attached USB drive and about 80MB/s and it didn't fail.
If it's not a physical hardware issue, and yes the ethernet pcb design on that device is quite insane ( massive gap under the transformer, although strictly following the datasheet recommendation), i must say that all my traffic is going through quality shielded cat6 cables with proper earth.
 
 
well the z28pro 2G/16G (Gbe, Wifi AC+BT) being often available at or below 40e, i don't think you'll find a Usb3/Gbe device at a lower price.
I'll leave the dev boards aside although i don't think they are much cheaper and you should at least add the cost of a case and power adapter.
 

Regarding the Gb-Lan-problems I recognized a declining speed, which occurred quite frequently after some time. And because there were some similar reports for the Rock64 on other sites, I assumed it was a general problem of the RK3328.
But this might be wrong, because another aspect is, that the LAN-Port on this box is as strong as the grip of the hand of Mr. Burns  . This thing is the most sloppiest Port I've ever seen. You don't feel a click, when you plug the cable in. In the end it is possible, that I only face a mechanical problem here.
 
Beside that, I think it is a nice little box and if the onboard devices are useable for your needs, it is relatively cheap.

BT should work now on the z28pro.
Everything is in the repo now and you can make a test build.

Hi,
 
some progress.
After installing the latest ayufan-build (0.6.22 xenial) I could update via Wifi-Dongle to kernel 4.15 (from ayufan) and now I have working ethernet. Beside that my box "feels" more stable, at least in the last 10 minutes. But I did not do anything to really stress the system.
I have a Z28Pro (2/16, V11).