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

Wild Penguin · November 24, 2021 at 2:30 PM

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-c1/soft…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:

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?
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!
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

**chewitt** · November 24, 2021 at 6:52 PM

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.

Wild Penguin · November 24, 2021 at 8:31 PM

Quote from chewitt

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!

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).
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.
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...

**chewitt** · November 25, 2021 at 10:46 AM

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.

**dtech** · November 26, 2021 at 5:46 AM

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?

Wild Penguin · November 29, 2021 at 9:33 AM

Quote from dtech

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

Quote from dtech

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:

FAT partition (required by uboot, but not really anything else after uboot in the boot chain (*)
Ubuntu root partition
Storage partition for LE
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.

**dtech** · November 29, 2021 at 2:47 PM

Quote from Wild Penguin

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

Quote from Wild Penguin

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?!

**chewitt** · November 29, 2021 at 5:36 PM

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.

**dtech** · November 29, 2021 at 6:26 PM

Quote from chewitt

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.

**chewitt** · November 30, 2021 at 4:34 AM

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.

Wild Penguin · November 30, 2021 at 8:55 PM

I just tried and uboot shipping with C1 images (*) has no problems with ext4load (well, at least for booting LiserTV; I haven't made any extensive tests!).

I can also change variables pointing to KERNEL and SYSTEM image file locations. Only the latter is required for boot to find the SquashFS (AFAIK! and only if it is not in the root of partition mounted to /flash), but both are used by any autoupdate scripts (I presume!). I didn't check or test that functionality since I don't need it. I also didn't check if the variables are used similarly across other (all?) LibreELEC releases.

In my setup, I've decided to put all LibreELEC files (of any release) in ext4 partition (which also has the Ubuntu root) in /boot/[RELEASE] folder, where [RELEASE] is specific to the version I intend to boot. That way they are nicely organized in their own folders, on an partition with ample space =)

Ubuntu already has it's boot files also in it's root filesystems/boot (in addition to the FAT partition). It should be able to boot in a similar way from "just the ext4 partition". Not sure if there's any need to - just getting the *ELEC files off the partition will already make it quite nice and tidy.

The changes I've made to boot.ini (LiserTV):

Code

setenv odroidp4 "BOOT_IMAGE=boot/LaserTV/KERNEL SYSTEM_IMAGE=boot/LaserTV/SYSTEM"
setenv odroid   "${odroidp1} ${odroidp2} ${odroidp3} ${odroidp4}"


# U-Boot - populate bootcmd
setenv kernel  "ext4load mmc 0:2 21000000 boot/LaserTV/KERNEL"
setenv dtb     "ext4load mmc 0:2 21800000 boot/LaserTV/meson8b_odroidc.dtb"
setenv bootseq "bootm 21000000 - 21800000"
setenv bootcmd "${kernel}; ${dtb}; ${bootseq}"

setenv fdt_high "0xffffffff"

# Set Boot and Disk Partitions
setenv bootrootfs "boot=/dev/mmcblk0p2 disk=/dev/mmcblk0p4"

Display More

In case someone reading this tries something similar: don't, unless you can fix it. Any autoupdate will fail after the chances, at least in case boot.ini is not in /flash directory anymore (and probably even if it is / this is untested). Obviously you need to adapt the paths and partition numbers according to your setup.

Cheers!

*) Well, most images - but since it's from 2011 and hasn't been updated since, it most probably it is the same u-boot on all non-ancient images floating around for the C1.

p.s. I didn't bother on changing the FAT partition (containing the boot.ini) to ext4. But IMHO there's little benefit from converting it; the only benefit I can think of is reducing partition number by combining the root (of a OS) and u-boot boot partition, but there's a potential huge downside; in case the OS craps out for any reason (or, there is a power outage or anything) -> you risk having a corrupt boot partition for u-boot- So it is sensible to have a separate boot partition for sanity's sake in any case. In case the OS has an InitRD / anything on the boot partition only, it can be used to recover in some cases. But if anyone else tests this u-boot form ext4, please do tell if it works =)