Implement the distro bootloader specification

[kwizart]

I wonder if it's possible to implement the distro bootloader specification ? (see also doc/README.distro in U-Boot source tree).

Using the bootloader specification, it should be possible to keep the boot menu to switch between Android and GNU/Linux but the latter will use extlinux to load the kernel, dtb and initramfs along with bootargs, all from external mmc.

Is this could be possible using the current U-Boot tree ? Or is there any constraints because of the chainload that does not permit to load any kernel from external mmc ?

On a side note, I was able to boot to a Fedora 30 (rawhide) userspace. But I need to revert the removed chosen bootargs node as I don't see where I could have specified the bootargs elsewhere.

Thx for this impressive work.

[xc-racer99]

Great, glad you could boot Fedora. That makes Arch, Debian, Ubuntu, and now Fedora. I'm assuming you're using an i9000?

Looking through README.distro, it should definitely be possible. There is no constraints due to the chainload, other than the fact that u-boot needs to be set to run from a specific address and also placed in a specific location on the onenand.

I do have a couple of concerns with it though: 1) how would be how to deal with the main and recovery onenand boots. Based on the "Interactively booting from a specific device at the u-boot prompt"; you can only pick which device, not which partition (correct me if I'm wrong). 2) How well would it interact with just the volume and power keys? That's the big issue as we don't have a full-fledged keyboard available. It appears that to dynamically select via u-boot prompt you would need a keyboard. The beauty of the current implementation is that you can do everything with the hardware keys.

Bootargs are currently statically defined in include/configs/s5p_aries.h - look for setup_kernel_args. You should be able to overwrite this variable from u-boot console (or from userspace if you've setup fw_setenv - note this is untested EDIT: this would also require OneNAND support in the kernel, but these patches aren't upstream yet).

[xc-racer99]

Ok, after reading https://systemd.io/BOOT_LOADER_SPECIFICATION as well, I'm starting to get more of the idea. There would be one partition per block device that would contain all of the boot info files; the bootloader (u-boot in our case) would parse these files and add the entries. We would then need a method of showing these in u-boot's bootmenu for easy access (and probably also as a way of saving the last used boot device; which I've found very handy over the couple of days I've used it).

However, we do start having problems (from my understanding of the specification): 1) We would need this FAT32 partition on the internal MMC for i9000 and I don't see this happening. Repartitioning the MMC would make it too tricky to go back to Android if needed. 2) How do we deal with non-GPT or MBR partitions such as onenand? There is no definition of this in the specification. The kernel is not a file in a filesystem; but is rather written directly to the flash.

The second could probably be overcome without too much difficulty (just hardcoding the onenand boot options into u-boot to always show and skipping the specification). The first might be able to be done by flashing a PIT file via Odin/Heimdall or by manual commands (I don't know, I don't have an MMC on my device).

Another question is how much have distros bought into this specification?

[kwizart]

Yes I'm using i9000.

I think all of arm distros you mentioned are already using this specification.

The point is to run bootcmd_mmc1 and that will run any Linux distro either using a single partition on external mmc with rootfs and kernel in /boot directory. Or using a more complex partition layout with: (like in recent fedora). mmcblock1p1 ESP (as fat32 mmcblock1p2 /boot mmcblock1p3 pv (rootfs, swap, etc).

So in others words, there is no partition layout to be enforced, but instead there is a mean to discover the partition layout and select the boot option the most appropriate for the device.

I don't know about onenand support , so maybe there is a need to extend the specification. Also I'm not sure about the android case, but one can assume that if there is no boot method that works on the internal mmc (no grub2, extlinux, EFI) that the previous android boot option will work...

But I saw you've talked about a bootmenu. Unfortunately I fail to see it, I'm booting directly to the kernel on onenand everytime. (even using "home" key or other combination). If there is the bootmenu that can be controller using hardware keys. I would expect, then it's just a matter to have an entry using bootcmd_mmc1 named "Distro boot on mmc1"

I might have a look into more detail in the coming days.

[xc-racer99]

I don't know about onenand support , so maybe there is a need to extend the specification. Also I'm not sure about the android case, but one can assume that if there is no boot method that works on the internal mmc (no grub2, extlinux, EFI) that the previous android boot option will work...

Looking at uboots implementation, it does support reading from UBI. So it would simply be a case of adding in another UBI volume and creating a uboot.scr file so we could properly boot into recovery.

Considering that we already need some modifications to Android ROMs to boot Android from u-boot; I'm not too concerned about this.

But I saw you've talked about a bootmenu. Unfortunately I fail to see it, I'm booting directly to the kernel on onenand everytime. (even using "home" key or other combination). If there is the bootmenu that can be controller using hardware keys. I would expect, then it's just a matter to have an entry using bootcmd_mmc1 named "Distro boot on mmc1"

Yes, there is a boot menu that should be appearing if you hold down the home button (and not either of the volume buttons) while it's booting. If it's not there, then please open an issue. You could also try holding only the volume up key in case your variant is being misdetected (in which case also open a bug :) )

[kwizart]

I've made a first attempt to implement the distro boot specification (without dealing with UBI for now).

Right now I'm able to discover and read the extlinux.conf file from a single partition on external mmc. But the ramdisk addr is not good. I probably need to fix the addresses in memory.