[ODROID C1] Multibooting many LibreELEC versions for testing (SYSTEM file and boot variable)

  • Hi,


    I have this quite old but still quite powerful device for it's age hanging around =).


    The LibreELEC images floating around for the device have an uboot right next to MBR, then a single FAT32 partition and the ext4 (ext2?) partition for storage. It's similar (or identical) compared to an Ubuntu partition table, except that the SYSTEM contains the root (ro) and the ext2(4?) is mounted to /storage. See: https://wiki.odroid.com/odroid…ion_table#tab__odroid-c11 for reference. I've only deduced this, I've not looked at the source.


    The FAT16 partition is housing boot.ini, .dtb, KERNEL in addition to the aforementioned SYSTEM (and sometimes INITRD and a .bmp splash image, depending on who made the release).


    Now, I've managed to get (manual) multibooting working by replacing the boot.ini along with the SYSTEM file, and setting the variable pointing to STORAGE partition correctly. I can easily point to any alternative KERNEL and .dtb files, but the problem is the very large SYSTEM files. To test several versions, I can:


    • Rename the SYSTEM file every time I change boot.ini. But this way I need to make the fat16 partition very large to house the SYSTEM files!
    • Alternatively, copy the SYSTEM file to the FAT16 partition every time. This is a bit time consuming and causes writes which are ultimately unnecessary.


    The questions:

    1. Where does a Kernel in a LibreElec version look for the SYSTEM file? Is it always hardcoded to ${boot}/SYSTEM? Is there a way to pass a location for SYSTEM for the Kernel as a parameter? I'm sure the answer is somewhere in the sources (1, 2) but I don't know the source well enough to find the information, maybe someone can point me at it?
    2. How can I determine what commands does the uboot build I'm using support? Can it load with ext2load or ext4load? This way, I can keep the fat partition very lean and clean since KERNEL and .dtb could be anywhere! (3). Same comment on source diving as above!
    3. What are the constraints to where $boot needs to point at? I'm thinking about will a LibreElec version panic out in case I've pointed to a SYSTEM file somewhere else and/or loaded .dtb and KERNEL with ext[2,4]load. Is boot parameter only used for updates (and $boot mounted at /flash as ro)? If the answer is yes, then I can live with that since I don't really need any kind of autoupdate (this is testing, after all!).


    Cheers!


    The source repositories I'm referring to:


    1) https://github.com/dtechsrv/LibreELEC-AML (and images at http://libreelec.dtech.hu/S805/ ; relevant thread LE-9.2.8 builds for some Amlogic S905x, S802/S812 and S805 devices ; I haven't actually tested these images yet on the C1)

    2) https://github.com/Leverex/lisertv.os (an unofficial branch; relevant thread https://forum.odroid.com/viewtopic.php?f=116&t=39184 ).

    3) [EDIT]: AFAIK, here is the branch the uboot I'm using is based on: https://github.com/hardkernel/u-boot/tree/odroidc-v2011.03

    Edited 2 times, last by Wild Penguin ().

  • 1. The kernel expects to find SYSTEM in the same partition as the KERNEL (or kernel.img) file. I'm not aware of a way to pass SYSTEM as a param but since I can't think of any reason to put it anywhere other than the boot partition I'm not sure it would be needed.


    2. "printenv" will show the u-boot environment via UART cable on a working board. If no UART you'll need to dive into the ancient Hardkernel sources. I wouldn't attempt to mess around with the default boot flow that's present in existing C1 images. It works, and the code behind it is crappy so by fiddling with it (from experience) you will only break something, and fixes bring new exiting bugs to play with.


    3. I'm not really sure what the question is. Leave the boot flow alone.

  • 1. The kernel expects to find SYSTEM in the same partition as the KERNEL (or kernel.img) file. I'm not aware of a way to pass SYSTEM as a param but since I can't think of any reason to put it anywhere other than the boot partition I'm not sure it would be needed.


    2. "printenv" will show the u-boot environment via UART cable on a working board. If no UART you'll need to dive into the ancient Hardkernel sources. I wouldn't attempt to mess around with the default boot flow that's present in existing C1 images. It works, and the code behind it is crappy so by fiddling with it (from experience) you will only break something, and fixes bring new exiting bugs to play with.


    3. I'm not really sure what the question is. Leave the boot flow alone.

    Hi chewitt, thanks for your reply. It is helpful and helped to get me on the right track!


    1. There is no reason to put SYSTEM on another partition than the boot in a single-OS (LibreELEC) device. However I've tried to describe a use case where the reason might arise; if one has several OSes and/or several versions of a OS, say LibreELEC in this case. The FAT partition is very small per default, and a user might be in a situation where it can not be grown easily (this is a limit I actually faced, since I didn't realize the SYSTEM images are quite large).
    2. I'm trying to get away without using an UART cable, while that is always an option. I might just give it a shot by trial-and-error :-). I realize uboot is not (supposed to be) any kind of multiboot loader such as grub, but I'm trying to find out it's limits.
    3. I must admit my thoughts got a bit convoluted as I was trying to describe why I need the answer, but the actual question got lost =) The question in simple terms is: What is LibreELEC doing with the boot (Kernel) parameter?


    I'm definitely comfortable with fiddling with the boot, while I understand some users might not. Chances of bricking might be high for some devices, but the C1 (and similar) doesn't have any non-removable flash-memory. If I screw up to boot, I only need to get my eMMC / µSD readers ready or change a jumper on the device to choose the other memory to boot from. The overall goal here is to reduce the need to open the device (which I've installed in a case) and switch eMMC module / µSD cards or change the jumper. It gets tiresome over time, and I'd much rather use SSH (or keyboard) to change the OS.


    While typing a reply, I found the actual key files in the source: packages/sysutils/busybox/scripts/init. I believe that file has all the answers I need for boot and disk parameter handling at least for the releases I can find ;-). By a quick glance, seems like $boot is always mounted to /flash and $IMAGE_SYSTEM is mounted to /sysroot; looks like to current script can read an alternative file name (and path) for SYSTEM, however it needs to be on the /flash. So with this init script, the SYSTEM file must always reside in whatever gets mounted on /flash (i.e. given by boot parameter). This might have nothing to do with the KERNEL image file, btw..


    I will at some point test with e2load and e4load and reply here my findings. I believe one can get away with having the SYSTEM elsewhere (from boot.ini partition) by lying to busybox ;-). I Haven't tested yet, though, and I definitely wouldn't do this kind of testing on a device where recovery isn't trivial. I could of course build my own KERNEL and INITRD (I presume busybox along with init is in there) but I'm not sure it's worth the hassle. Maybe just as an exercise later...

  • The main challenge with u-boot on Meson8 boards is that half the stuff you think you know hasn't been implemented yet on the prehistoric version of u-boot that's being used .. it's an archeological exercise :)


    LE's KERNEL file contains an initramfs so we don't use a separate initrd file, and we avoid the entire topic of coexistence with other distros by simply not supporting it. As a rule it's not a big requirement on ARM devices among our userbase so we avoid the heartache.


    wrxtasy released images for C1 for a while and I can see active installs in our stats server, so there is prior-art in his GitHub repo. There is also ongoing effort from dtech to adapt his LE 9.2.x image.


    There is also a slow-burning effort to run mainline kernels on Meson8 boards. The amlogic-mx branch in my LE repo builds images but we did not figure out the u-boot bootscripts needed yet, so we are interested in what you figure out. Keep sharing infos.

  • I’m really trying to adapt it, but I'd rather just say experimentation. Now I have a working image, but I wouldn't say it's 100% done.

    http://libreelec.dtech.hu/snapshots/20211122/ (Source: https://github.com/dtechsrv/LibreELEC-AML/tree/odroid-c1)

    It contains almost all Kodi patches I have used for the boxes, including the fix for the IPTV problem, and I also enabled the dvb-latest driver package. However, the kernel of wrxtasy I used for this build is unfortunately very outdated.


    Although I only have this board for 2 weeks. Before that, I only had boxes. :)


    For me, the u-boot is a whole new area, so unfortunately I can't answer your previous questions on the merits either, but all the experience comes in handy. If I understand correctly, you want a native ext2/ext4 partition instead of a squashfs + overlayfs for the system patrition, right?

  • I’m really trying to adapt it, but I'd rather just say experimentation. Now I have a working image, but I wouldn't say it's 100% done.

    http://libreelec.dtech.hu/snapshots/20211122/ (Source: https://github.com/dtechsrv/LibreELEC-AML/tree/odroid-c1)

    It contains almost all Kodi patches I have used for the boxes, including the fix for the IPTV problem, and I also enabled the dvb-latest driver package. However, the kernel of wrxtasy I used for this build is unfortunately very outdated.


    This is interesting information!


    I've used the LiserTV release for media uses for a few days, and it seems really responsive and stable! I'm not sure where it pulls it Kernel sources from, but:

    Code
    # uname -a
    
    Linux LaserTV 3.10.107 #1 SMP PREEMPT Tue Oct 27 19:15:52 UTC 2020 armv7l GNU/Linux

    For me, the u-boot is a whole new area, so unfortunately I can't answer your previous questions on the merits either, but all the experience comes in handy. If I understand correctly, you want a native ext2/ext4 partition instead of a squashfs + overlayfs for the system patrition, right?

    No, not quite. I want to read the squashfs file (SYSTEM) from another partition (so that I'm not forced to make a large FAT partition). I.e. I'm perfectly fine with the squasfs (i.e. SYSTEM) and storage partitions libreelec will be using, but the partially hardcoded location (as confirmed by the busybox init script) of the SYSTEM squasfs image file makes the setup a bit inflexible.


    The current partition layout I have is this:


    1. FAT partition (required by uboot, but not really anything else after uboot in the boot chain (*)
    2. Ubuntu root partition
    3. Storage partition for LE
    4. Storage partition for LE (another version)

    (At this point, an MBR partition table is full. I could make one of the partitions an extended partition, but really I think I don't need any more; but in case different releases of LibreELEC have different structures for the storage or any incompatibilities, I might or - alternatively - make some kind of file juggling every time I change the booted release; or in case I want to install any other OS, such as another Linux distribution, Lakka, Retropie etc...).


    The FAT partition will contain all LibreELECs individual SYSTEM files, KERNEL files (if they are different) and Ubuntu Kernel files, and INITRD files in case any of the OSes use one (some don't, as already pointed out). The total size of all these files will get quite large easily! It would be more handy to and tidy to have some (or all!) on some other partition.


    The Ubuntu root partition will be large in any case. One possibility in my case would be to move the SYSTEM (and KERNEL) files this partition into the folder /boot, but I haven't tested if the uboot can use ext4load (I've looked at the source and it looks like it should have it build in).


    Of course, this is just for my personal tinkering. I wouldn't recommend this to anyone who can not fix what they've broken ;)


    Cheers!


    *) Technically there's nothing preventing from making a uboot setup without an fat partition if I've understood it's documentation and source correctly, but it has been chosen as the most sensible choice for most situations. Any OS can read FAT, and it will usually contain only a few files, written rarely - so efficiency etc. is not really an issue. U-boot has (in the source, still not sure about this binary release) support for ext4, but such partitions could not be accessed (easily) from, say, a Windows computer.

  • I'm not sure where it pulls it Kernel sources from...

    LiserTV uses the HardKernel's own kernel-branch with a few extra patches:

    Commits · Leverex/linux
    Linux kernel source tree. Contribute to Leverex/linux development by creating an account on GitHub.
    github.com

    Any OS can read FAT, and it will usually contain only a few files, written rarely - so efficiency etc. is not really an issue.

    It is a little interesting that x86 has been forcing UEFI and secure boot (nightmares) for a long time, but for u-boot we still use a file system to load all boot files that doesn't even handle basic permissions. Okay, that's easy to store boot files on FAT... But is it secure at all?! :/

  • U-boot also allows the entire boot process to be encrypted/signed and protected; but this requires support for those things in Silicon which increases costs, so you almost never see it with cheap TV box devices.

  • U-boot also allows the entire boot process to be encrypted/signed and protected; but this requires support for those things in Silicon which increases costs, so you almost never see it with cheap TV box devices.

    It would have been more of a philosophical question, I personally don't like UEFI too much. :)


    Altough on the boxes the /dev/system partition, which contains the squashfs file it is ext4, but on the sd card, flash drive (or removable eMMC) it is FAT. In principle, would u-boot be able to find and start the kernel if the first partition on the sd card is ext4?


    I know I'm now speaking against myself as a Windows desktop user. Native ext4 support under Windows, that would be nice. 8o

  • U-boot can boot from an EXT4 boot partition; assuming the embedded bootscript that searches for boot files (extlinux.conf, or boot.ini, etc.) has been adapted to it. LE scripts assume FAT, so you things like "fatload" in them.