You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it is fair to say that U-Boot is the de-facto standard for various single-board computers, routers, and embedded systems, so it would be great to support generating its own boot menu config directly, rather than going via extlinux or grub.
The reason to avoid extlinux.conf is that, in extlinux mode, U-Boot (as far as I can tell) cannot boot EFI binaries.
Its support for UEFI boot is rather limited in that it does not seem to present any menu by default and simply loads the EFI binary from the standard system location (e.g. boot/bootaa64.efi on aarm64), which will typically be Grub or systemd-boot in order to have a menu. The downside is that, with this method, there is no easy way to make it load a device tree. Actually, it (at least the version that I have) will load the device tree from the dtb subdirectory of the EFI system partition, although this behaviour seems to be undocumented. In theory, this should be good-enough, since the device tree is supposed to be stable; in practice, though, the device tree needs to match the kernel version, which presents a challenge in presence of multiple boot menu items since they can use different kernels.
One example of how this problem manifests is #296013.
I think it is fair to say that U-Boot is the de-facto standard for various single-board computers, routers, and embedded systems, so it would be great to support generating its own boot menu config directly, rather than going via extlinux or grub.
The reason to avoid
extlinux.conf
is that, in extlinux mode, U-Boot (as far as I can tell) cannot boot EFI binaries.Its support for UEFI boot is rather limited in that it does not seem to present any menu by default and simply loads the EFI binary from the standard system location (e.g.
boot/bootaa64.efi
on aarm64), which will typically be Grub or systemd-boot in order to have a menu. The downside is that, with this method, there is no easy way to make it load a device tree. Actually, it (at least the version that I have) will load the device tree from thedtb
subdirectory of the EFI system partition, although this behaviour seems to be undocumented. In theory, this should be good-enough, since the device tree is supposed to be stable; in practice, though, the device tree needs to match the kernel version, which presents a challenge in presence of multiple boot menu items since they can use different kernels.One example of how this problem manifests is #296013.
The Flat Image Tree format seems to solve this problem as it, both, is able to boot EFI binaries and presents a boot menu with the kernel/initramfs/dtb individually configurable for each item.
So the proposal, essentially, is to implement a module that would directly generate a FIT loadable by U-Boot.
The text was updated successfully, but these errors were encountered: