Chainloaded uboot images for amlogic

[hexdump]

@lanefu - for those amlogic tv boxes chainloading u-boot means the old legacy u-boot on the box is loading a mainline u-boot.bin (which has nice features like extlinux.conf support and allocates less memory for itself) which is then loading the kernel

 

@SteeMan - this looks a bit like this box has a non standard mmc setup which might be not so easy to track down (one would need to extract the android dtb from the box - see: https://github.com/hexdump0815/u-boot-misc/tree/master/misc.h616-legacy/android-device-tree-copy and then the mmc entries should be compared to the android dtbs of other boxes where emmc works - here is for instance my h96max-x3 android dtb: https://github.com/hexdump0815/linux-mainline-and-mali-amlogic-kernel/blob/master/misc.aml/dtb/meson-sm1-h96max-x3.dts.android - this is a big puzzle and a lot of trial and error might be required without the guarantee to get it working)

 

the patch is to remove some code which will not work in our scenario (getting linux working on it) - it looks like the mainline u-boot code for the s905x3 i used as a base was only done for android which has a different partition (+table) setup than what we plan to use

 

the uEnv.txt file is read before extlinux.conf, so things can be set there which partially cannot be defined in the extlinux.conf (which is quite limited) - in armbian that file usually is called armbianEnv.txt i think, so you should maybe adjust the filename to be in sync with armbian if you want to get it closer to a standard armbian setup

 

just an idea: you might also try the newer u-boot 2021.01 or soon the upcoming 2021.04, but i think nothing really changed in there for amlogic

 

@lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe

 

good luck and best wishes - hexdump

[lanefu]

41 minutes ago, hexdump said:

loading a mainline u-boot.bin (which has nice features like extlinux.conf

 

Interesting I'll have to learn more about extlinux.conf 

[SteeMan]

31 minutes ago, lanefu said:

Interesting I'll have to learn more about extlinux.conf 

One of the interesting features of extlinux.conf is the ability to present a boot menu.  I have played around with it a bit to have different kernel versions installed and switch between them at boot time.  With a boot menu and hdmi support in u-boot, it brings some nice capabilities.

[lcapriotti]

17 hours ago, hexdump said:

 

@lcapriotti - it would be very helpful if you could find out how you got it to work on your box - this might getting this resolved easier for @SteeMan maybe

What I *think* I have done is:

 

use sm1-u-boot.bin from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 

dd the file to an SD card and boot from it

dd the file to the emmc once booted from the SD card

 

Not 100% sure though

[SteeMan]

@lcapriotti It would help me if you could provide  the following information from your TX3 box:

1) what dtb are you using in extlinux.conf

2) what kernel version are you booting with

3) what is the file size of your /boot/u-boot.emmc file

 

[lcapriotti]

1) I am using meson-sm1-sei610.dtb

2) I am using the default from Armbian_20.10_Arm-64_focal_current_5.9.0.img

3) my uboot.emmc is 765,142 bytes long

 

[hexdump]

@lcapriotti - could you maybe upload your uboot.emmc somewhere so that we can run some strings and/or hexdump on it to find out what version it is?

[lcapriotti]

There you go: https://www.dropbox.com/s/zq9sjetlb49wyc2/u-boot.zip?dl=0

[SteeMan]

@lcapriotti thanks for uploading that file.  That file is identical to hexdump's sm1-u-boot.bin file linked to above.  The mystery remains why you originally had the same issue that I am seeing with the tx3 box not being able to access emmc with this u-boot.  But as you report you are no longer having that problem.

[lcapriotti]

Keep in mind I have one of the first TX3 boxes, maybe HW changed between my version and newer ones.

[hexdump]

maybe upgraded or downgraded android on the box, i.e. different version of the legacy u-boot? - in case both of you have a serial console connected you might compare the u-boot version strings from early boot ...

[lcapriotti]

I took my time, apologies, but here is the boot log via serial.

boot.txt

[hexdump]

that log looks like my mainline u-boot is not chainloaded but has replaced the legacy u-boot (as there is no sign of a legacy u-boot in the log) ... this works quite well for me but is not tested too well and worst case you can brick the box - but looks like you got it working well too

 

maybe you wiped your emmc (accidently?) and by chance had the proper u-boot at the proper place on the sd card ... if the box does not find a boot loader on emmc then it will try to boot from sd card ... or you even by chance replaced the bootloader on emmc with my mainline u-boot ...

[lcapriotti]

I kinda recall having wiped the emmc by mistake, and had to boot from SD on which I installed you mainline u-boot.

I then recovered the emmc u-boot using the one on the SD, risky but hey it worked....

 

[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

 

Spoiler

TIMEOUT 20
MENU TITLE Multi-OS-USB

# Partition 5
 LABEL Manjaro
  LINUX /auxboot/Manjaro/Image
  INITRD /auxboot/Manjaro/initramfs-linux.img
  FDT /auxboot/Manjaro/meson-g12b-ugoos-am6-plus.dtb
  APPEND root=UUID=XXXXXXX-8c29-48c2-94a6-b14b9cc76a44 rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0

# Partition 6
 LABEL ArmbianHirsute
  LINUX /auxboot/ArmbHirsute/vmlinuz
  INITRD /auxboot/ArmbHirsute/initrd.img
  FDT /auxboot/ArmbHirsute/meson-g12b-ugoos-am6.dtb
  APPEND root=UUID=XXXXXXX-e7a8-42f7-813d-1907d72f739d rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0

 

 

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.

[maziizam]

I have vontar x3 am905x3 4gB ram but emmc is broken. How start it at sd-card without emmc?

[SteeMan]

As far as I know you can't

[hexdump]

@maziizam - you might try to dd this u-boot: boot-amlogic_sm1-aarch64-x96-air.dd.gz or boot-amlogic_sm1-aarch64-x96-air-serial.dd.gz from https://github.com/hexdump0815/u-boot-misc/releases/tag/200926-01 (after unzip) to the beginning of the disk via: dd if=boot-xyz.dd of=/dev/your-sd-card bs=512 seek=1 skip=1 (the seek/skip tries to preserve the partitiona table)

 

good luck and best wishes - hexdump

[Energokom]

On 1/5/2021 at 9:22 PM, hexdump said:

 in case you want to experiment (i.e. not sure if it really works), you might play around with chainloading the g12a-u-boot.bin (s905x2) and sm1-u-boot.bin (s905x3) 

I have a HK1 BOX S905x3 nic 100mb/s TV box - there is no Ethernet chip on the board. I edited the dtb, cleaning up the ethernet@ff3f0000 - everything related to the  external chip, and change to internal ethernet 100 M/s

 

Various U-boot.bin  that I've tried allow me to boot from USB. When booting from sd, does not go further u-boot .

Only with one u-boot-tx3-bz.bin is loading, but first the screen gives out other colors, then everything is fine and u-boot starts.

But with this u-boot-tx3-bz.bin in older versions of the armbian is also green or blue screen (wrong colors). I want to ask you how to build your u-boot so that it would use my dtb?

 

 

 

Edited January 21, 2023 by Energokom

[AlexRaven]

Hello. Tell me, was there a reason for the failure to boot image u-boot  hexdump from MMC? And why does BusyBox only boot kernel 5.9 from MMC?
And one more question. Can I write a thread in extlinux.conf and make DUALBOOT Android with MMC? After all, how does Coreelec do it? All good and success.

[Bartel Eerdekens]

Sorry for bumping this (quite) old thread:

 

But I have a question about chainloading u-boot images: Is it recommended to change the RAM addresses (TEXT_BASE / SYS_LOAD_ADDR) when chainloading u-boot images?
Or is it okay to keep them the same? Thanks!

@hexdump for tags/notification

Edited July 1 by Bartel Eerdekens
typo

[hexdump]

@Bartel Eerdekens - just pure guessing as all this was quite some time ago: i think it does not matter as the chainloaded u-boot will be just loaded to some other address and when executed there via "go" command of the legacy u-boot it will relocate itself to where it is supposed to live and the legacy u-boot does not play any role anymore at that point - but all this might also be completely wrong ...