tripole

@hexdump Thank you for your work on these chain loaders. It has enabled me to do something I have wanted for a long time. I have your g12a-u-boot.bin (renamed to u-boot.ext) running on my Ugoos AM6 plus, in a multi-os boot setup, with all OSes installed on the SD (utilizing the vendor boot for the all boot stages except the last, which is in u-boot.ext). Currently, I can boot into Armbian Meson64 (Hirsute flavor, built in QEMU based on the rootfs file tree), Manjaro ARM (for VIM3/Ugoos, copied from distro image), and a Armbian Buster mini as rescue (also from QEMU/rootfs). By writing the entries in extlinux.conf according to the correct menu syntax (inferred from e.g. pxe_utils.c in u-boot source, see below) one can select which kernel+initrd+dtb to load, and which root file system to mount. (One has to be quick at the second prompt to make the OS selection. This prompt appears at the sysboot stage, after u-boot autoload has timed out. Perhaps the sysboot timeout can be extended a bit? Edit: The TIMEOUT keyword does not seem to take effect.) On all the OSes I have kept their original /boot dir and then added a new mount point /boot_FAT32 where the first FAT32 partition is located (with extlinux.conf, kernels+initrds+dtbs, and u-boot.ext), and updated the local /etc/fstab accordingly. Then it is simple to propagate the changes made to /boot under a running OS also to the boot partition. The SD layout/geometry is essentially: From the first available sector (2048, no gap needed) and 300M onwards; the kernel+initrd+dtbs and extlinux.conf stuff on a FAT32 partition. The follows, after perhaps a common swap partition, a number of ext4 partitions with the different OSes. Here is what the extlinux.conf can look like P.S. I know it is hard to compile these loaders correctly: From u-boot-amlogic (custodian) have have managed to compile, starting with different defconfigs, chain loaders that boot but with; no (HDMI) screen, green screen (several flavors), and indeed, purple-pinkish screen, but not one single working properly. Doh.

Follow-up on Ugoos Am6 plus (s922xj). Now I have also got WiFi working (with image 20.09, kernel 5.8.10). It turns out that the clock frequency for SDIO was too high, and it manifested itself via an error "mmc0: error -84 whilst initialising SDIO card" in dmesg. Inspired by I tried to edit the max-frequency setting in the dts/dtb file (meson-g12b-ugoos-am6). In the sd@ffe03000 { ...} clause changed the original entry max-frequency = < 0x5f5e100 >; to max-frequency = < 0x17d7840 >; (i.e. lowering the frequency from 100MHz to 25MHz), and this worked. The wifi chip brcm4359 (AP6398s package) is then detected at boot and the brcmfmac driver/module loads. (It gives a few error messages about missing firmware (despite having installed armbian-firmware-full) but these messages seem harmless, see e.g. here and here.) I haven't tested the connection extensively, but both 2.4GHz and 5GHz seem to work fine. As a final note; there still seem to be some kind of initialization issue with the box so that it often requires a cold boot for everything to work (i.e. pull power plug, wait and then keep power button pressed during start). Edit1: The SDIO interface on both the s922x and the AP6398S module support SD spec. version 2.x/3.x/4.x DS/HS modes up to UHS-I SDR104 (using clock freqs. 25,50,100 and 208MHz). Therefore, I expected that setting the max-frequency parameter above to at least one of the higher clocks would work but, alas, I can only get the lowest 25MHz clock to work. (In /sys/kernel/debug/mmc0/ios the timing spec. is then listed as "sd high-speed"). Edit2: I have now found one more SDIO clock frequency that works; 0x2b594d1 (45.454545MHz). (Such odd numbers are perhaps not surprising given Amlogic's history.)

OK, I will try a shorter post this time. I have got Armbian 20.09 (buster_current_5.8.10) up and running on the Ugoos Am6 plus (the newer version with s922xj SoC) using the supplied dtb for Am6. Everything seems to work fine (ethernet, usb, graphics, sound, video playback (see below) and Bluetooth) except wifi. The clock speed cannot be set (in arbian-config) above 1992MHz however, and I have a similar problem with the picture (thin colored vertical lines at the borders of the display) as tonny above. dmesg_UgoosAm6plus_Android_edit.txt.gz dmesg_UgoosAm6plus_Armbian_20.09_5.8.10-arm-64.txt.gz Edit: There also seems to be an issue with initialization of the ethernet chip; sometimes it starts in "happy" mode and sometimes in "grumpy" mode. In grumpy mode there is about 20% packet loss and speed is much lower. In happy mode it works flawlessly for days. Cold boot sometimes works to transfer from grumpy to happy, but not always. Perhaps the problem is related to this https://patchwork.kernel.org/patch/11800917/

How to get a working LED/VFD front display on Tanix TX3 mini-A: First, many thanks to Balbes, Igor and the other heroes of the Armbian community. Instructions (noob-like, i.e. like me): Install (see instructions at the top of this thread) the dtb file meson-gxl-s905w-tx3-mini-vfd.dtb.gz and boot your tx3 box with this file. (This assumes that you boot from SD/USB so that you don't risk bricking your box. See also notes below, incl md5sum) Download the vfd code (module and daemon) tarball vfdd-20181209.tar.xz from a link at the bottom of the page http://www.rvq.fr/linux/tanix-vfd.php and unpack it someplace on your tx3 box. Build the vfd module (natively): Install the *.deb package from Balbes/Armbian with linux kernel headers for the kernel you are running. Then, copy the contents of vfdd-20181209/vfdmod/vfdmod/ to some place in the kernel headers tree, say drivers/vfd Go to drivers/vfd and write up a Makefile somewhat like this; KERNEL_SOURCE := /usr/src/linux-headers-4.19.7-aml-s9xxx PWD := $(shell pwd) default: ${MAKE} -C ${KERNEL_SOURCE} M=${PWD} modules clean: ${MAKE} -C ${KERNEL_SOURCE} M=${PWD} clean Run 'make' and build the module vfdmod.ko Check that the module loads: insmod vfdmod.ko Build the daemon vfdd: Go to the directory vfdd-20181209/ and run make. (I got some seemingly harmless warnings, which I ignored.) The daemon executable vfdd should emerge. After inspection/editing of the Makefile in vfdd-20181209/ (e.g. BINDIR, ETCDIR) you can run 'make install' to copy the the daemon executable and configuration file to their proper locations (or do this manually). Test the daemon: Check the vfd conf file (default /etc/vfd.conf) and edit according to taste, or leave as-is. Start the daemon with recipe as in vfdd-20181209/vfdd.runit.in If everything is OK some nice little numbers and symbols should now emerge on the front LED display of your tx3 box. (Note that the daemon cycles through time/date/temp on the display and that e.g. the play button means bluetooth, I think.) Notes: The dtb file meson-gxl-s905w-tx3-mini-vfd.dtb (md5sum is fe846c5c3c7903b15c0725c2bd289fe5) is an augmentation of the Balbes/Armbian file meson-gxl-s905w-tx3-mini.dtb where the following definition has been added/compiled in (method; hack to Balbes' Armbian cross compile build environment) to support vfd (as per recipe in vfdd-20181209): meson-vfd { compatible = "amlogic,aml_vfd"; dev_name = "meson-vfd"; status = "okay"; gpios = <&gpio_ao GPIOAO_4 GPIO_ACTIVE_HIGH>, /* STB */ <&gpio GPIODV_27 GPIO_ACTIVE_HIGH>, /* CLK */ <&gpio GPIODV_26 GPIO_ACTIVE_HIGH>; /* DI/DO */ }; (A dtb file can easily be decompiled and inspected by decompiling it with dtc, the device tree compiler.) The vfd module can also be complied using the Balbes/Armbian cross compile environment, using (at least for me) some ugly hacks, but the native route seems much simpler. (The module built with the cross compile environment becomes smaller; I don't know why (perhaps due to some shared code).) I have used information and links mainly from the excellent tx3 info source http://www.rvq.fr/linux/tanix-tx3.php