Hi Ilias, On Tue, 24 Aug 2021 at 03:30, Ilias Apalodimas <ilias.apalodi...@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