[PATCH 00/28] Initial implementation of bootmethod/bootflow

[Ilias Apalodimas]

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.

Regards
/Ilias
> 
> -- 
> Tom