AML boot sequence.

    I have an m8s plus dvb 1G box that I am trying to boot using LibreELEC. Is this supported? I have downloaded the LibreELEC-AMLGX.arm-11.0.6-box.img.gz and installed this onto a USB. I end up with two GPT partitions one is the fat with label LIBREELEC and the other is an ext4 filesystem with label STORAGE. I then change the uEnv.ini file on the fat partition to point to meson-gxl-s905d-mecool-m8s-plus.dtb. When I boot this USB device I don't get past the Android TV splash screen from the boot loader on the device (not sure where this is stored).

    There is no android installed on the eMMC as this was blown away with by an old CoreELEC install. Unfortunately, CoreELEC doesn't include support from the eMMC any longer but CoreELEC with happily boot up.

    I guess my first question is if this device is supported (without the DVB drivers) and secondly what is the boot priority?

    You need to invoke recovery boot again so it searches for bootscripts that tell it to load LE boot files else it will be looking for CE boot files which are different (names) and not found; hence you end up attempting to load Android.

    I believe that it should at least boot up past that splash screen and at least not sit at the android tv screen.

    I cannot really solder a few wires on the box to get serial output and as CoreELEC no longer supports the eMMC (actually does LibreELEC support the eMMC or has that been disabled in the DTB also?) for this device I will try to remove the first line and see if I can force a USB boot.

    Are these scripts compile the same way as other uBoot scrips? I have forgotten the command to produce the .scr file.

    While it may not be possible to know exactly why the stock image is not booting it is possible to deduce that for some reason, it is likely that the state of the eMMC is affecting the LibreELEC boot sequence.

    For instance, by modifying the s905_autoscript and runnig mkimage (going from memory here) -T script etc... I manage to get a reboot loop going, as the Android TV splash screen disappears for a second and then re-appears. We could therefore deduce that the Amlogic uboot is reading the USB and the script on the USB? Would you not agree?

    And by replacing the kernel, image and dtb files onto a booting CoreELEC configuration and having the device boot up, would you not agree that the only difference here is almost certainly the LibreELEC script?

    Anyhow, this issue isn't affecting me any longer as I have worked around it. I appreciate you help and for pointing me to the sources.

    This describes the BL1 (Silicon) to BL2 (Software) boot flow: https://docs.u-boot.org/en/latest/boar…/boot-flow.html

    Once you get to BL2, what happens depends on what the software implements. Amlogic hacked in various recovery mechanisms to support common things that Android STB manufacturers want (and we abuse those to make the box run Linux). However those OEM box manufacturers sometimes tweak the code to suit their own purposes, or simply because they can, or because their developers were simply incompetent with strange ideas. As a result, while the general flow probably follows some common themes, there are enough exceptions seen "in the wild" that you shouldn't assume anything until you see UART logs and/or a dump of the u-boot env configuration.

    If vendor u-boot is on eMMC in 99.999% of boxes it will be used. The contents of the u-boot environment (env) will then dictate what happens next. If the env has been modified through boot.scr or s905_autoscript methods it will look for Linux boot files (as dictated by what the boot scripts set) and this remains configured unless a reset is performed (restoring the original env for Android-only boot) or the recovery mode is triggered again; causing it to look for boot.scr or s905_autoscript which can (re)modify the env again.

    Your box has an env modified by CE boot scripts to look-for and use CE boot files. Unless you trigger recovery again and tell it to use LE boot files; it continues to look for CE files and fails to find them as CE and LE boot media are (intentionally) different and since the kernels are now also rather different, the boot params may or may not be aligned.

    Users frequently assume u-boot scripts are read on every boot and this is not true. Users also assume they can rename files and make it all work, and this is not completely true. Users also very-very-wrongly assume that I have any interest in CE or interest in triaging frankenbox configurations. Sorry to dissapoint..

    Thanks, but I think that the I probably need to put this on a USB drive, call it "cfgload" and add a reboot to it. ie something like:

    Shell session
    # cat > cfgload.txt << __EOF__
defenv
saveenv
run storeargs
sleep 2
reboot
__EOF__
# bin/mkimage -C none -A arm64 -T script -d cfgload.txt cfgload