[PATCH] RFC: Support an EFI-loader bootflow

[Simon Glass]

Hi Takahiro,

On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
<takahiro.akashi at linaro.org> wrote:
>
> Simon,
>
> On Sat, Aug 28, 2021 at 02:35:21PM -0600, Simon Glass wrote:
> > This is just a demonstration of how to support EFI loader using bootflow.
> > Various things need cleaning up, not least that the naming needs to be
> > finalised. I will deal with that in the v2 series.
> >
> > In order to support multiple methods of booting from the same device, we
> > should probably separate out the different implementations (syslinux,
> > EFI loader
>
> I still believe that we'd better add "removable media" support
> to UEFI boot manager first (and then probably call this functionality
> from bootflow?).
>
> I admit that, in this case, we will have an issue that we will not
> recognize any device which is plugged in dynamically after UEFI
> subsystem is initialized. But this issue will potentially exist
> even with your approach.

That can be fixed by dropping the UEFI tables and using driver model
instead. I may have mentioned that :-)

>
> > and soon bootmgr,
>
> What will you expect in UEFI boot manager case?
> Boot parameters (options) as well as the boot order are well defined
> by BootXXXX and BootOrder variables. How are they fit into your scheme?

I haven't looked at boot manager yet, but I can't imagine it
presenting an insurmountable challenge.

>
> But anyway, we can use the following commands to run a specific
> boot flow in UEFI world:
> => efidebug boot next 1(or whatever else); bootefi bootmgr

OK.

As you probably noticed I was trying to have bootflow connect directly
to the code that does the booting so that 'CONFIG_CMDLINE' can be
disabled (e.g. for security reasons) and the boot will still work.

>
> > Chromium OS, Android, VBE) into pluggable
> > drivers and number them as we do with partitions. For now the sequence
> > number is used to determine both the partition number and the
> > implementation to use.
> >
> > The same boot command is used as before ('bootflow scan -lb') so there is
> > no change to that. It can boot both Fedora 31 and 34, for example.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> > See u-boot-dm/bmea for the tree containing this patch and the series
> > that it relies on:
> >
> >   https://patchwork.ozlabs.org/project/uboot/list/?series=258654&state=*
> >

[..]

> > +static int efiload_read_file(struct blk_desc *desc, int partnum,
> > +                          struct bootflow *bflow)
> > +{
> > +     const struct udevice *media_dev;
> > +     int size = bflow->size;
> > +     char devnum_str[9];
> > +     char dirname[200];
> > +     loff_t bytes_read;
> > +     char *last_slash;
> > +     ulong addr;
> > +     char *buf;
> > +     int ret;
> > +
> > +     /* Sadly FS closes the file after fs_size() so we must redo this */
> > +     ret = fs_set_blk_dev_with_part(desc, partnum);
> > +     if (ret)
> > +             return log_msg_ret("set", ret);
> > +
> > +     buf = malloc(size + 1);
> > +     if (!buf)
> > +             return log_msg_ret("buf", -ENOMEM);
> > +     addr = map_to_sysmem(buf);
> > +
> > +     ret = fs_read(bflow->fname, addr, 0, 0, &bytes_read);
> > +     if (ret) {
> > +             free(buf);
> > +             return log_msg_ret("read", ret);
> > +     }
> > +     if (size != bytes_read)
> > +             return log_msg_ret("bread", -EINVAL);
> > +     buf[size] = '\0';
> > +     bflow->state = BOOTFLOWST_LOADED;
> > +     bflow->buf = buf;
> > +
> > +     /*
> > +      * This is a horrible hack to tell EFI about this boot device. Once we
> > +      * unify EFI with the rest of U-Boot we can clean this up. The same hack
> > +      * exists in multiple places, e.g. in the fs, tftp and load commands.
>
> Which part do you call a "horrible hack"? efi_set_bootdev()?
> In fact, there are a couple of reason why we need to call this function:
> 1. to remember a device to create a dummy device path for the loaded
>    image later,
> 2. to remember a size of loaded image which is used for sanity check and
>    image authentication later,
> 3. to avoid those parameters being remembered accidentally by "loading" dtb
>    and/or other binaries than the image itself,
>
> I hope that (1) and (2) will be avoidable if we modify the current
> implementation (and bootefi syntax), and then we won't need (3).

Yes thank you...I do understand why it is needed now, but it is
basically due to the the  fat that EFI has its own driver structures.
Once we stop those, it will go away.

>
> > +      * Once we can clean up the EFI code to make proper use of driver model,
> > +      * this can go away.
>
> My point is, however, that this kind of cleanup is irrelevant to
> whether we use driver model or not.

Are you sure? Without driver model how are you going to reference a
udevice? If not that, how are you going to reference a device? The
tables in the UEFI implementation were specifically added to avoid
relying on driver model. It is a crying shame that I did not push back
harder on this at the time.

Regards,
Simon