Hi Ilias,
On Tue, 24 Aug 2021 at 03:30, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
Hi Tom,
> >
[...]
> > The series is available at u-boot-dm/bmea-working > > My question / concern is this. Would the next step here be to > implement the generic UEFI boot path? Today, I can write Fedora 34 for > AArch64 to a USB stick, boot U-Boot off of uSD card and the installer > automatically boots. I'm sure I could do the same with the BSDs. > Reading the documentation left me with the impression that every OSV > would be expected to write something, so that their installer / OS boot. > But there's already standards for that, which they do, and we should be > implementing (and do, via the current distro_boot) or making easier to > enable. Thanks!
Here you are talking about scanning for a bootflow. It is not actually OS-specific. If it were, there would be no point to this :-)
If you look in the distro scripts you will see 'scan_dev_for_efi' (and also scan_dev_for_scrips). At least the first needs to be implemented a bit like the distro boot is at present. So far I have only implemented scan_dev_for_extlinux (plus pxe) as it is enough to show the concept.
Adding EFI it's likely to be about the same amount of code as distro.c at present, perhaps a little less since we don't have the network case. It is used by Fedora 34, I believe, so is easy enough for me to do. But I wanted to get something out as the concept is visible in this series.
OK, good. I'd certainly like to see how this looks with EFI added.
What would be the order preference after scanning?
(from other thread) With distro boot this is done with an environment variable, as I understand it. That is not implemented in this series, but is easy to do and is in the TODO. For now it can only be done with aliases to set the order of the bootmethods and that requires adding to the DT, so I don't think it scales well. I'm open to ideas though.
Keep in mind that our efibootmgr is pretty complete wrt to booting. It can even support booting multiple OS'es without GRUB2 (even loading different initrds is supported). Ideally (and assuming we want to support EFI booting for more devices), I would map existing extlinux configs into efibootmgr entries.
Yes I understand. I believe distro boot supports multiple OSes too, but perhaps only on different media? I'm not sure. Anywayt ere are always going to be people who don't want or need to use EFI (or grub)
Well, here's where I'm a bit curious. I have seen at least twice "wait, EFI stub in the linux kernel adds how much?" type commentary. I don't know how prevalent that type of concern will really be given just how often I don't see the Linux kernel config shrunk down from what the reference platform started with. And as Ilias is pointing out, you can do _a_lot_ with efibootmgr and without grub/whatever. And both Arm (the company) and RISC-V (the overarching organization) are both pushing to standardize around the idea that if you're on something bigger than an MCU, EFI-the-ABI should get you up and running.
Exactly. Keep in mind that RISC-V is looking into EBBR as well, so this is far from an 'Arm thing'. Moreover, the efi stub side of the kernel for risc-v, will only load an initrd using the EFI_LOAD_FILE2 protocol we added support for. So right now the only way to properly boot a RISC-V with EFI is through the manager.
I had heard that RISC-V was just going to use UEFI (and not U-Boot), but perhaps that is not correct. So far I have not really done anything with RISC-V so am not familiar with it.
Regards, Simon