On Mon, Aug 23, 2021 at 11:25:40AM -0600, Simon Glass wrote: > Hi Ilias, > > On Mon, 23 Aug 2021 at 06:35, Ilias Apalodimas > wrote: > > > > On Thu, Aug 19, 2021 at 01:27:50PM -0400, Tom Rini wrote: > > > On Thu, Aug 19, 2021 at 08:25:33AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 19 Aug 2021 at 07:59, Tom Rini wrote: > > > > > > > > > > On Wed, Aug 18, 2021 at 09:45:33PM -0600, Simon Glass wrote: > > > > > > > > > > > Bootmethod and bootflow provide a built-in way for U-Boot to automatically boot > > > > > > an Operating System without custom scripting and other customisation: > > > > > > > > > > > > - bootmethod - a method to scan a device to find bootflows (owned by U-Boot) > > > > > > - bootflow - a description of how to boot (owned by the distro) > > > > > > > > > > > > This series provides an initial implementation of these, enable to scan > > > > > > for bootflows from MMC and Ethernet. The only bootflow supported is > > > > > > distro boot, i.e. an extlinux.conf file included on a filesystem or > > > > > > tftp server. It works similiarly to the existing script-based approach, > > > > > > but is native to U-Boot. > > > > > > > > > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > > > > > > > > > bootflow scan -lb > > > > > > > > > > > > which means to scan, listing (-l) each bootflow and trying to boot each > > > > > > one (-b). The final patch shows this. > > > > > > > > > > > > It is intended that this approach be expanded to support mechanisms other > > > > > > than distro boot, including EFI-related ones. With a standard way to > > > > > > identify boot devices, these features become easier. It also should > > > > > > support U-Boot scripts, for backwards compatibility only. > > > > > > > > > > > > The first patch of this series moves boot-related code out of common/ and > > > > > > into a new boot/ directory. This helps to collect these related files > > > > > > in one place, as common/ is quite large. > > > > > > > > > > > > Like sysboot, this feature makes use of the existing PXE implementation. > > > > > > Much of this series consists of cleaning up that code and refactoring it > > > > > > into something closer to a module that can be called, teasing apart its > > > > > > reliance on the command-line interpreter to access filesystems and the > > > > > > like. Also it now uses function arguments and its own context struct > > > > > > internally rather than environment variables, which is very hard to > > > > > > follow. No core functional change is included in the included PXE patches. > > > > > > > > > > > > For documentation, see the 'doc' patch. > > > > > > > > > > > > There is quite a long list of future work included in the documentation. > > > > > > One question is the choice of naming. Since this is a bootloader, should > > > > > > we just call this a 'method' and a 'flow' ? The 'boot' prefix is already > > > > > > shared by other commands like bootm, booti, etc. > > > > > > > > > > > > The design is described here: > > > > > > > > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > > > > > > > > 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. -- Tom