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:
