Official LE11 Test Images for Amlogic (Kodi-20)

    If this is a place for issues with installation, my boot attempts cause dozens of errors when booting from USB: services fail to start etc. KODI appeared once but not for long. It won't boot from SD at all, but maybe the card was to blame. A log would help, but as far as I know, you need a network to connect via SSH, and apparently boot attempts damaged the existing OS in the internal. I can take pictures.

    Box: OzoneHD (S905X ARM Coretex-A53; ARM Mali-450)

    Previous OS: AlexELEC-S9XX.arm-3.1.8 (Android behaved badly and somehow I chose AE; it ran fine, but KODI had a few issues)

    Attempted latest LE: http://chewitt.libreelec.tv/testing/LibreE…arm-10.95.0-box

    DTB:

    AE gxl_p212_2g_nand

    LE dtb_name=/dtb/meson-gxl-s905x-p212.dtb

    1) If the device tree is wrong, LE won't boot at all?

    2) Why can AE fail to boot from internal now? Booting from SD/USB is not supposed to affect it. There was a request to do a repair, but I ignored it in hopes of a successful boot, and it never came on again.

    3) Out of curiosity, AE builds are called piracy, does it mean they contain stolen code and are not an independent, proprietary product, so to speak?

    1. Most S905X boxes follow the reference boards quite closely and all use internal PHY ethernet so it's hard (but not impossible) to get a non-booting box, but that assumes you can trick the box into booting LE (some require non-standard boot tricks) and things can go wrong with cheap emmc/ram parts. You might not get WiFi/BT if non-Broadcom parts are being used.

    2. Once you initiate recovery boot to load LE the u-boot environment is tweaked to use LE boot files (else it won't boot). If you remove the SD card (or USB) and force recovery boot again it should rediscover the AE install. You can't swap between distros solely by removing the SD card.

    3. AE contains embedded tools whose primary/sole purpose is the consumption of pirated content. That's the main objection. AE's creator also leeches 99% of their distro from others without preserving attribution and licensing (so it appears to be their meisterwerk, when in fact it's the work of others). In FOSS circles that's disrespectful, but kind of normal/expected in the pirate box space.

    Quote from chewitt

    2. Once you initiate recovery boot to load LE the u-boot environment is tweaked to use LE boot files (else it won't boot). If you remove the SD card (or USB) and force recovery boot again it should rediscover the AE install. You can't swap between distros solely by removing the SD card.

    I don't know how AE or people format the eMMC. But on the Vero4K they still use the original Amlogic u-boot from Android, plus the Android partition layout, and if you go toothpick mode on it without an SD card in it (or a valid aml_autoscript) then it wipes the "instaboot" partition (it's in the u-boot script). The problem on the Vero4K is they take several (most) of the Android partitions and throw it into an LVM and use that as the root filesystem. I don't remember the exact scenario, but I have wiped instaboot many many times playing with LE/CE/Armbian and had to reinstall OSMC. :)

    Hopefully it's just a unique scenario with the Vero4K, easily fixed, but I know the u-boot sources are not complete (missing bl32) and doubting if there is other pieces missing (just because I see package updates in OSMC but no source code updates in their source tree).

    Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.

    Edited 2 times, last by frakkin64 (February 7, 2023 at 9:58 PM).

    Quote from frakkin64

    Anyways, the point of this meandering is to share that toothpick method can kill eMMC installs depending on whether they use the instaboot partition in a similar way.

    LE boot scripts don't touch partitions at all, but if the boot processes aml_autoscript then we're changing the boot flow stored in the u-boot environment to use our scripts, which will "break" legacy distro booting due to them using kernel.img not KERNEL and more. Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage. Forcing clean installs is just a sensible move.

    Quote from chewitt

    Some of these differences are intentional; partly to align with LE standard namings, but also because we (me) don't want users "updating" from all kinds of unknown legacy images to AMLGX and then showing up with tricky-to-solve support issues. Boot is already "fun" before you factor in large Kodi major version bumps and the Python2 to Python3 change which causes add-on carnage.

    After digging through the whole u-boot process, aml_autoscript, etc. I can fundamentally see why you wouldn't support eMMC's at all on Android TV-boxes and not even touch them. It's a nightmare, you would have to format & partition the eMMC to be supported by mainline, you probably would have to replace u-boot, and it just starts piling up with bricking scenarios.

    I have only worked up the nerve to chainload mainline u-boot on the Vero4K, pretty reluctant to format the eMMC and load that mainline u-boot. And naturally all working from SD cards. It's just not worth it, so far I haven't seen an SD card failure, and I have weekly backups anyways of /storage.

    Quote from frakkin64

    I have only worked up the nerve to chainload mainline u-boot on the Vero4K, pretty reluctant to format the eMMC and load that mainline u-boot. And naturally all working from SD cards. It's just not worth it, so far I haven't seen an SD card failure, and I have weekly backups anyways of /storage.

    Is that the 4K (S905X) or 4K+ (S905D)? .. I'm still waiting on a positive test report to send it upstream.

    Sam did promise to submit the FIP sources for his boards at some point (prob. minus the BL32 bits, but those are optional) .. but then he's also promised to test the 4K (for six months) and send me samples (for two years) so I'm not holding breath. Running your own business is time-consuming :)

    Quote from chewitt

    Is that the 4K (S905X) or 4K+ (S905D)? .. I'm still waiting on a positive test report to send it upstream.

    I have the 4K+, which we tested already and I am enjoying the labors with LE & Armbian. Just being lazy with the extra character, it's too far from my fingers. :)

    Quote from chewitt

    Sam did promise to submit the FIP sources for his boards at some point (prob. minus the BL32 bits, but those are optional) .. but then he's also promised to test the 4K (for six months) and send me samples (for two years) so I'm not holding breath. Running your own business is time-consuming

    Yeah, that would be nice to see. The FIP sources, maybe, are in Github -- but considering the last commit is 2017 and I have received bootloader updates since then I don't trust it's current. It's minus the bl32 bits, of course. All of the commits after Amlogic are purely cosmetic.

    Further to booting on a box with S905X, I've tried all DTBs for it, with much the same result, and noticed one error that may make sense: could not mount UUID=59a29572-99d0-44c6-b35a-98d279afa82a (the one in uEnv.ini).

    Code
    dtb_name=/dtb/meson-gxl-s905d-sml5442tw.dtb
bootargs=boot=LABEL=LIBREELEC disk=LABEL=STORAGE quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0

    ^ Modify the bootargs line in uEnv.ini to look like ^ this with everything on one line (beware, the forum wraps lines). Working?

    Sadly, no. Sorry for troubling you. The storage seems faulty. The installation starts as usual with partition resizing, etc. A reboot brings mount errors, need to exit, more errors (Kernel panic). Kodi may appear, but setting it up ends in (a need to do) a reboot. The final series of errors is failed services and dependencies. There may also appear a request to do a repair, but to no avail.

    I have tried several systems, new and old, with similar results. Alas, the attempts have ruined a working AE installation, seemingly irrevocably. Flashing the Android image doesn't produce a working system anymore, previously not perfect but possible. I'll ask elsewhere if there can be images to flash in Android Recovery, it works.

    Thanks for your help!

    Quote from Masutin

    Sadly, no. Sorry for troubling you. The storage seems faulty. The installation starts as usual with partition resizing, etc. A reboot brings mount errors, need to exit, more errors (Kernel panic). Kodi may appear, but setting it up ends in (a need to do) a reboot. The final series of errors is failed services and dependencies. There may also appear a request to do a repair, but to no avail.

    I have tried several systems, new and old, with similar results. Alas, the attempts have ruined a working AE installation, seemingly irrevocably. Flashing the Android image doesn't produce a working system anymore, previously not perfect but possible. I'll ask elsewhere if there can be images to flash in Android Recovery, it works.

    Thanks for your help!

    Once you boot LE we've configured (overwritten) properties in the u-boot environment for LE filenames. To return to a legacy image you will need to force recovery boot again. This makes vendor u-boot search for legacy image bootscripts that will overwrite those properties with the info needed to boot legacy images again. It's fairly simple to flip between legacy and LE images; but it's not as simple as just inserting and removing the SD card, you need to invoke the recovery process. Restoring the original Android image will also reset things to a state where any legacy image (or LE) can hook u-boot and set things correctly.

    From the description: vendor u-boot does hooks LE correctly, the initial boot/resizing of the SD card completes, and you can reach Kodi. At this point you should have a working install. To isolate further issues I would avoid immediate installation of add-ons and just reboot several times to prove the initial setup is valid. If there are failed services they are likely minor things, but I would need to see a log file from the box: enable debug mode in Kodi, then reboot and run "pastekodi" one minute later and share the URL.

    Errors involving storage are odd. The upstream kernel doesn't understand the Amlogic custom partition scheme used to create filesystems on the internal emmc storage so AMLGX kernels will see a /dev/mmcblkX device with no visible partition scheme or mountable filesystems; ergo there will be no attempt to mount filesystems (and thus no errors from them). That means errors are more likely to come from the SD card, in which case the issue may be the maximum speed of the mmc device being too high (some boxes with lower-spec components need to force it to lower speeds to avoid instability). There are two ways to test that. One is using a device-tree file that forces 50MHz (not 100MHz or 200MHz) and the other is using an old slow SD card (not a fancy fast one) or perhaps a USB key (which is not an mmc device). Any chance of that?

    1) A DTB that forces 50MHz. How do I find it?

    2) The boot medium. One successful install was from a 2GB SD with no markings at to its class. It's in use, but if you think it can help, I'll try it. This time I had an 8GB SD HC class 4. LE failed to boot from it, so I used a 4GB TS4GJFV30 USB stick. Other systems did boot from SD but with the same results as from USB.

    3) I reach Kodi only at initial configuration, when you need to hit Next to proceed, and it doesn't seem to complete. Can I exit that and enable debugging? As the boot now ends only in failed services, how can I reach a state of the first boot and Kodi again? In Android Recovery? Flash the Android image?

    Thanks again!

    Old and slow SD cards are great for debugging issues with problemattic boot because they don't support the faster access modes which can trip an Amlogic silicon bug causing mmc device instability. The kernel has a workaround for the bug but it's not perfect (perfect doesn't exist) and issues do arise sometimes. Old slow cards also negate the need for custom device-trees in most cases.

    If you edit uEnv.ini and change "quiet" to "quiet ssh" (adding ssh to boot params) the SSH service is forced on and you can probably access the box to run "pastekodi" and share the URL so we can see the system log and kodi log to look for service start failures and other issues.

    NB: please use the "box" image here: https://chewitt.libreelec.tv/testing/ as it has some extra things inside to help testing (maybe).

    chewitt Did not know that the box image is not capable of booting from eMMC storage. Is that also why i could not update it within libeelec to 10.95.0?

    The box is still booting without any issues i could not send the whole error message so maybe that is why it is still booting.

    Also the internal install is still working (coreelec 9.2.8. Kodi18.9)

    I will try the image you created and i will let you know how it works.

    Re-reading the original screenshot: You ran emmctool without actually having the AMLGX file to write on the /storage partition so it's errored and written no data to the device. Hence boot has still worked. If the box boots; that's where advice stops because I have no interest in wading into the shitfest of atetmpting support for internal installs on hardware I don't have. I've deleted the GT1 image from my test share.