Re: [PATCH] RFC: Support an EFI-loader bootflow
On Wed, Sep 29, 2021 at 10:08:48PM -0600, Simon Glass wrote: > Hi Takahiro, > > On Mon, 6 Sept 2021 at 21:58, AKASHI Takahiro > wrote: > > > > On Mon, Sep 06, 2021 at 04:41:55AM -0600, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Fri, 3 Sept 2021 at 10:30, Heinrich Schuchardt > > > wrote: > > > > > > > > > > > > > > > > On 9/3/21 10:53 AM, Simon Glass wrote: > > > > > Hi Takahiro, > > > > > > > > > > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro > > > > > wrote: > > > > >> > > > > >> Simon, > > > > >> > > > > >> On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote: > > > > >>> Hi Takahiro, > > > > >>> > > > > >>> On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro > > > > >>> 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 :-) > > > > >> > > > > >> I'm afraid that you don't get my point above. > > > > >> > > > > > > > > > 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 Boot 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. > > > > >> > > > > >> I don't say it's challenging. > > > > >> Since you have not yet explained your idea about how to specify > > > > >> the *boot order* in your scheme, I wonder how "Boot"/"BootOrder" > > > > >> be treated and honored. > > > > >> There might be a parallel world again. > > > > > > > > > > Well as I mentioned, I haven't looked at it yet. The original question > > > > > was how to do EFI LOADER and I did a patch to show that. > > > > > > > > > > Are we likely to see mixed-boot environments, that use distro boot for > > > > > some OSes and EFI for others? I hope not as it would be confusing. EFI > > > > > is the parallel world, as I see it. > > > > > > > > > > It should be easy enough for the 'bootmgr' bootflow to read the EFI > > > > > variables and select the correct ordering. As I understand it, EFI > > > > > does not support lazy boot, so it is acceptable to probe all the > > > > > devices before selecting one? > > > > > > > > > >> > > > > > > > > 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. > > > > >> > > > > >> # Maybe, it sounds kinda chicken and egg. > > > > >> > > > > >> Even now, you can code this way :) > > > > >> > > > > >> efi_set_variable(u"BootNext", ..., u"Boot0001"); > > > > >> do_efibootmgr(); > > > > >> > > > > >> That's it. My concern is what I mentioned above. > > > > > > > > > > OK. But then you would need to export those functions. I think it > > > > > would be better to split up the logic a bit and move things out of the > > > > > cmd/ directory (at some point). > > > > > > > > > >> > > > > >> Just a note: > > > > >> In the current distro_bootcmd, UEFI boot manager is also called > > > > >> *every time* one of boot media in "boot_targets" is > > > > >> scanned/enumerated. > > > > >> But it will make little sense because the current boot manager only > > > > >> allows/requires users to specify both the boot device and the image > > > > >> file > > > > >> path explicitly in a boot option, i.e. "Boot" variable,
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Takahiro, On Mon, 6 Sept 2021 at 21:58, AKASHI Takahiro wrote: > > On Mon, Sep 06, 2021 at 04:41:55AM -0600, Simon Glass wrote: > > Hi Heinrich, > > > > On Fri, 3 Sept 2021 at 10:30, Heinrich Schuchardt > > wrote: > > > > > > > > > > > > On 9/3/21 10:53 AM, Simon Glass wrote: > > > > Hi Takahiro, > > > > > > > > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro > > > > wrote: > > > >> > > > >> Simon, > > > >> > > > >> On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote: > > > >>> Hi Takahiro, > > > >>> > > > >>> On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro > > > >>> 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 :-) > > > >> > > > >> I'm afraid that you don't get my point above. > > > >> > > > > > > > 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 Boot 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. > > > >> > > > >> I don't say it's challenging. > > > >> Since you have not yet explained your idea about how to specify > > > >> the *boot order* in your scheme, I wonder how "Boot"/"BootOrder" > > > >> be treated and honored. > > > >> There might be a parallel world again. > > > > > > > > Well as I mentioned, I haven't looked at it yet. The original question > > > > was how to do EFI LOADER and I did a patch to show that. > > > > > > > > Are we likely to see mixed-boot environments, that use distro boot for > > > > some OSes and EFI for others? I hope not as it would be confusing. EFI > > > > is the parallel world, as I see it. > > > > > > > > It should be easy enough for the 'bootmgr' bootflow to read the EFI > > > > variables and select the correct ordering. As I understand it, EFI > > > > does not support lazy boot, so it is acceptable to probe all the > > > > devices before selecting one? > > > > > > > >> > > > > > > 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. > > > >> > > > >> # Maybe, it sounds kinda chicken and egg. > > > >> > > > >> Even now, you can code this way :) > > > >> > > > >> efi_set_variable(u"BootNext", ..., u"Boot0001"); > > > >> do_efibootmgr(); > > > >> > > > >> That's it. My concern is what I mentioned above. > > > > > > > > OK. But then you would need to export those functions. I think it > > > > would be better to split up the logic a bit and move things out of the > > > > cmd/ directory (at some point). > > > > > > > >> > > > >> Just a note: > > > >> In the current distro_bootcmd, UEFI boot manager is also called > > > >> *every time* one of boot media in "boot_targets" is scanned/enumerated. > > > >> But it will make little sense because the current boot manager only > > > >> allows/requires users to specify both the boot device and the image > > > >> file > > > >> path explicitly in a boot option, i.e. "Boot" variable, and tries > > > >> all the boot options in "BootOrder" until it successfully launches > > > >> one of those images. > > > > > > > > Yes, is the idea of lazy boot entirely impossible? Or is it still > > > > possible to do that to some extent, e.g. by scanning until you find > > > > the first thing in the boot order? > > > > > > > >> > > > > > > >
Re: [PATCH] RFC: Support an EFI-loader bootflow
On Mon, Sep 06, 2021 at 04:41:55AM -0600, Simon Glass wrote:
> Hi Heinrich,
>
> On Fri, 3 Sept 2021 at 10:30, Heinrich Schuchardt wrote:
> >
> >
> >
> > On 9/3/21 10:53 AM, Simon Glass wrote:
> > > Hi Takahiro,
> > >
> > > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro
> > > wrote:
> > >>
> > >> Simon,
> > >>
> > >> On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote:
> > >>> Hi Takahiro,
> > >>>
> > >>> On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
> > >>> 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 :-)
> > >>
> > >> I'm afraid that you don't get my point above.
> > >>
> >
> > > 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 Boot 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.
> > >>
> > >> I don't say it's challenging.
> > >> Since you have not yet explained your idea about how to specify
> > >> the *boot order* in your scheme, I wonder how "Boot"/"BootOrder"
> > >> be treated and honored.
> > >> There might be a parallel world again.
> > >
> > > Well as I mentioned, I haven't looked at it yet. The original question
> > > was how to do EFI LOADER and I did a patch to show that.
> > >
> > > Are we likely to see mixed-boot environments, that use distro boot for
> > > some OSes and EFI for others? I hope not as it would be confusing. EFI
> > > is the parallel world, as I see it.
> > >
> > > It should be easy enough for the 'bootmgr' bootflow to read the EFI
> > > variables and select the correct ordering. As I understand it, EFI
> > > does not support lazy boot, so it is acceptable to probe all the
> > > devices before selecting one?
> > >
> > >>
> >
> > 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.
> > >>
> > >> # Maybe, it sounds kinda chicken and egg.
> > >>
> > >> Even now, you can code this way :)
> > >>
> > >> efi_set_variable(u"BootNext", ..., u"Boot0001");
> > >> do_efibootmgr();
> > >>
> > >> That's it. My concern is what I mentioned above.
> > >
> > > OK. But then you would need to export those functions. I think it
> > > would be better to split up the logic a bit and move things out of the
> > > cmd/ directory (at some point).
> > >
> > >>
> > >> Just a note:
> > >> In the current distro_bootcmd, UEFI boot manager is also called
> > >> *every time* one of boot media in "boot_targets" is scanned/enumerated.
> > >> But it will make little sense because the current boot manager only
> > >> allows/requires users to specify both the boot device and the image file
> > >> path explicitly in a boot option, i.e. "Boot" variable, and tries
> > >> all the boot options in "BootOrder" until it successfully launches
> > >> one of those images.
> > >
> > > Yes, is the idea of lazy boot entirely impossible? Or is it still
> > > possible to do that to some extent, e.g. by scanning until you find
> > > the first thing in the boot order?
> > >
> > >>
> >
> > > 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.
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Takahiro, On Sun, 5 Sept 2021 at 19:47, AKASHI Takahiro wrote: > > Hi Simon, > > On Fri, Sep 03, 2021 at 02:53:52AM -0600, Simon Glass wrote: > > Hi Takahiro, > > > > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro > > wrote: > > > > > > Simon, > > > > > > On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote: > > > > Hi Takahiro, > > > > > > > > On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro > > > > 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 :-) > > > > > > I'm afraid that you don't get my point above. > > > > > > > > > > > > > > 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 Boot 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. > > > > > > I don't say it's challenging. > > > Since you have not yet explained your idea about how to specify > > > the *boot order* in your scheme, I wonder how "Boot"/"BootOrder" > > > be treated and honored. > > > There might be a parallel world again. > > > > Well as I mentioned, I haven't looked at it yet. The original question > > was how to do EFI LOADER and I did a patch to show that. > > > > Are we likely to see mixed-boot environments, that use distro boot for > > some OSes and EFI for others? I hope not as it would be confusing. EFI > > is the parallel world, as I see it. > > Yeah, I absolutely agree here. > That is why I constantly insist "removable media" support should be > implemented in UEFI boot manager in the first place. Please remember > that "removable media" support is part of UEFI specification, > UEFI boot manager and hence "EFI LOADER". > > # By "removable media" support, I mean that the image to be loaded > # is determined by searching for the default file path, or /EFI/BOOT/xxx.efi, > # in the system partition. The media can be, say, a fixed (non-removable) > # HD on the system. > # This is definitely part of UEFI environment. > OK. > > It should be easy enough for the 'bootmgr' bootflow to read the EFI > > variables and select the correct ordering. As I understand it, EFI > > does not support lazy boot, so it is acceptable to probe all the > > devices before selecting one? > > > > > > > > > > > > > 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. > > > > > > # Maybe, it sounds kinda chicken and egg. > > > > > > Even now, you can code this way :) > > > > > >efi_set_variable(u"BootNext", ..., u"Boot0001"); > > >do_efibootmgr(); > > > > > > That's it. My concern is what I mentioned above. > > > > OK. But then you would need to export those functions. I think it > > would be better to split up the logic a bit and move things out of the > > cmd/ directory (at some point). > > If we don't take "mixed-boot environments", adding efibootmger to > bootflow mechanism, or implementing efibootmger using bootflow, > makes little sense. I'm not convinced of that, actually. Let's leave the discussion for when bootflow is a little closer. I think it should be possible to boot without needing CONFIG_CMDLINE, for example. But even without that, a unified approach to what is available to boot and what to select could be quite helpful I think. It can support custom flows too, such as Chrome OS. > > > > > > > Just a note: > > > In the
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Heinrich,
On Fri, 3 Sept 2021 at 10:30, Heinrich Schuchardt wrote:
>
>
>
> On 9/3/21 10:53 AM, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro
> > wrote:
> >>
> >> Simon,
> >>
> >> On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote:
> >>> Hi Takahiro,
> >>>
> >>> On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
> >>> 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 :-)
> >>
> >> I'm afraid that you don't get my point above.
> >>
>
> > 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 Boot 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.
> >>
> >> I don't say it's challenging.
> >> Since you have not yet explained your idea about how to specify
> >> the *boot order* in your scheme, I wonder how "Boot"/"BootOrder"
> >> be treated and honored.
> >> There might be a parallel world again.
> >
> > Well as I mentioned, I haven't looked at it yet. The original question
> > was how to do EFI LOADER and I did a patch to show that.
> >
> > Are we likely to see mixed-boot environments, that use distro boot for
> > some OSes and EFI for others? I hope not as it would be confusing. EFI
> > is the parallel world, as I see it.
> >
> > It should be easy enough for the 'bootmgr' bootflow to read the EFI
> > variables and select the correct ordering. As I understand it, EFI
> > does not support lazy boot, so it is acceptable to probe all the
> > devices before selecting one?
> >
> >>
>
> 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.
> >>
> >> # Maybe, it sounds kinda chicken and egg.
> >>
> >> Even now, you can code this way :)
> >>
> >> efi_set_variable(u"BootNext", ..., u"Boot0001");
> >> do_efibootmgr();
> >>
> >> That's it. My concern is what I mentioned above.
> >
> > OK. But then you would need to export those functions. I think it
> > would be better to split up the logic a bit and move things out of the
> > cmd/ directory (at some point).
> >
> >>
> >> Just a note:
> >> In the current distro_bootcmd, UEFI boot manager is also called
> >> *every time* one of boot media in "boot_targets" is scanned/enumerated.
> >> But it will make little sense because the current boot manager only
> >> allows/requires users to specify both the boot device and the image file
> >> path explicitly in a boot option, i.e. "Boot" variable, and tries
> >> all the boot options in "BootOrder" until it successfully launches
> >> one of those images.
> >
> > Yes, is the idea of lazy boot entirely impossible? Or is it still
> > possible to do that to some extent, e.g. by scanning until you find
> > the first thing in the boot order?
> >
> >>
>
> > 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
> > ---
> > 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=*
> >
> >>>
> >>>
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Simon, On Fri, Sep 03, 2021 at 02:53:52AM -0600, Simon Glass wrote: > Hi Takahiro, > > On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro > wrote: > > > > Simon, > > > > On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote: > > > Hi Takahiro, > > > > > > On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro > > > 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 :-) > > > > I'm afraid that you don't get my point above. > > > > > > > > > > > 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 Boot 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. > > > > I don't say it's challenging. > > Since you have not yet explained your idea about how to specify > > the *boot order* in your scheme, I wonder how "Boot"/"BootOrder" > > be treated and honored. > > There might be a parallel world again. > > Well as I mentioned, I haven't looked at it yet. The original question > was how to do EFI LOADER and I did a patch to show that. > > Are we likely to see mixed-boot environments, that use distro boot for > some OSes and EFI for others? I hope not as it would be confusing. EFI > is the parallel world, as I see it. Yeah, I absolutely agree here. That is why I constantly insist "removable media" support should be implemented in UEFI boot manager in the first place. Please remember that "removable media" support is part of UEFI specification, UEFI boot manager and hence "EFI LOADER". # By "removable media" support, I mean that the image to be loaded # is determined by searching for the default file path, or /EFI/BOOT/xxx.efi, # in the system partition. The media can be, say, a fixed (non-removable) # HD on the system. # This is definitely part of UEFI environment. > It should be easy enough for the 'bootmgr' bootflow to read the EFI > variables and select the correct ordering. As I understand it, EFI > does not support lazy boot, so it is acceptable to probe all the > devices before selecting one? > > > > > > > > > > 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. > > > > # Maybe, it sounds kinda chicken and egg. > > > > Even now, you can code this way :) > > > >efi_set_variable(u"BootNext", ..., u"Boot0001"); > >do_efibootmgr(); > > > > That's it. My concern is what I mentioned above. > > OK. But then you would need to export those functions. I think it > would be better to split up the logic a bit and move things out of the > cmd/ directory (at some point). If we don't take "mixed-boot environments", adding efibootmger to bootflow mechanism, or implementing efibootmger using bootflow, makes little sense. > > > > Just a note: > > In the current distro_bootcmd, UEFI boot manager is also called > > *every time* one of boot media in "boot_targets" is scanned/enumerated. > > But it will make little sense because the current boot manager only > > allows/requires users to specify both the boot device and the image file > > path explicitly in a boot option, i.e. "Boot" variable, and tries > > all the boot options in "BootOrder" until it successfully launches > > one of those images. > > Yes, is the idea of lazy boot entirely impossible? Or is it still > possible to do that to some extent, e.g. by scanning until you find > the first thing in the boot order? If I correctly understand what 'lazy boot' means here, you can do
Re: [PATCH] RFC: Support an EFI-loader bootflow
On 9/3/21 10:53 AM, Simon Glass wrote:
Hi Takahiro,
On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro
wrote:
Simon,
On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote:
Hi Takahiro,
On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
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 :-)
I'm afraid that you don't get my point above.
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 Boot 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.
I don't say it's challenging.
Since you have not yet explained your idea about how to specify
the *boot order* in your scheme, I wonder how "Boot"/"BootOrder"
be treated and honored.
There might be a parallel world again.
Well as I mentioned, I haven't looked at it yet. The original question
was how to do EFI LOADER and I did a patch to show that.
Are we likely to see mixed-boot environments, that use distro boot for
some OSes and EFI for others? I hope not as it would be confusing. EFI
is the parallel world, as I see it.
It should be easy enough for the 'bootmgr' bootflow to read the EFI
variables and select the correct ordering. As I understand it, EFI
does not support lazy boot, so it is acceptable to probe all the
devices before selecting one?
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.
# Maybe, it sounds kinda chicken and egg.
Even now, you can code this way :)
efi_set_variable(u"BootNext", ..., u"Boot0001");
do_efibootmgr();
That's it. My concern is what I mentioned above.
OK. But then you would need to export those functions. I think it
would be better to split up the logic a bit and move things out of the
cmd/ directory (at some point).
Just a note:
In the current distro_bootcmd, UEFI boot manager is also called
*every time* one of boot media in "boot_targets" is scanned/enumerated.
But it will make little sense because the current boot manager only
allows/requires users to specify both the boot device and the image file
path explicitly in a boot option, i.e. "Boot" variable, and tries
all the boot options in "BootOrder" until it successfully launches
one of those images.
Yes, is the idea of lazy boot entirely impossible? Or is it still
possible to do that to some extent, e.g. by scanning until you find
the first thing in the boot order?
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
---
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=*
[..]
+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, _read);
+ if (ret) {
+ free(buf);
+
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Takahiro,
On Thu, 2 Sept 2021 at 20:27, AKASHI Takahiro
wrote:
>
> Simon,
>
> On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote:
> > Hi Takahiro,
> >
> > On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
> > 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 :-)
>
> I'm afraid that you don't get my point above.
>
> > >
> > > > 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 Boot 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.
>
> I don't say it's challenging.
> Since you have not yet explained your idea about how to specify
> the *boot order* in your scheme, I wonder how "Boot"/"BootOrder"
> be treated and honored.
> There might be a parallel world again.
Well as I mentioned, I haven't looked at it yet. The original question
was how to do EFI LOADER and I did a patch to show that.
Are we likely to see mixed-boot environments, that use distro boot for
some OSes and EFI for others? I hope not as it would be confusing. EFI
is the parallel world, as I see it.
It should be easy enough for the 'bootmgr' bootflow to read the EFI
variables and select the correct ordering. As I understand it, EFI
does not support lazy boot, so it is acceptable to probe all the
devices before selecting one?
>
> > >
> > > 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.
>
> # Maybe, it sounds kinda chicken and egg.
>
> Even now, you can code this way :)
>
>efi_set_variable(u"BootNext", ..., u"Boot0001");
>do_efibootmgr();
>
> That's it. My concern is what I mentioned above.
OK. But then you would need to export those functions. I think it
would be better to split up the logic a bit and move things out of the
cmd/ directory (at some point).
>
> Just a note:
> In the current distro_bootcmd, UEFI boot manager is also called
> *every time* one of boot media in "boot_targets" is scanned/enumerated.
> But it will make little sense because the current boot manager only
> allows/requires users to specify both the boot device and the image file
> path explicitly in a boot option, i.e. "Boot" variable, and tries
> all the boot options in "BootOrder" until it successfully launches
> one of those images.
Yes, is the idea of lazy boot entirely impossible? Or is it still
possible to do that to some extent, e.g. by scanning until you find
the first thing in the boot order?
>
> > >
> > > > 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
> > > > ---
> > > > 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=*
> > > >
> >
> > [..]
> >
> > > > +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;
Re: [PATCH] RFC: Support an EFI-loader bootflow
Simon,
On Thu, Sep 02, 2021 at 10:40:57AM -0600, Simon Glass wrote:
> Hi Takahiro,
>
> On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
> 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 :-)
I'm afraid that you don't get my point above.
> >
> > > 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 Boot 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.
I don't say it's challenging.
Since you have not yet explained your idea about how to specify
the *boot order* in your scheme, I wonder how "Boot"/"BootOrder"
be treated and honored.
There might be a parallel world again.
> >
> > 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.
# Maybe, it sounds kinda chicken and egg.
Even now, you can code this way :)
efi_set_variable(u"BootNext", ..., u"Boot0001");
do_efibootmgr();
That's it. My concern is what I mentioned above.
Just a note:
In the current distro_bootcmd, UEFI boot manager is also called
*every time* one of boot media in "boot_targets" is scanned/enumerated.
But it will make little sense because the current boot manager only
allows/requires users to specify both the boot device and the image file
path explicitly in a boot option, i.e. "Boot" variable, and tries
all the boot options in "BootOrder" until it successfully launches
one of those images.
> >
> > > 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
> > > ---
> > > 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=*
> > >
>
> [..]
>
> > > +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, _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"?
Re: [PATCH] RFC: Support an EFI-loader bootflow
Hi Takahiro,
On Tue, 31 Aug 2021 at 00:14, AKASHI Takahiro
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 Boot 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
> > ---
> > 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=*
> >
[..]
> > +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, _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.
Re: [PATCH] RFC: Support an EFI-loader bootflow
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.
> 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 Boot and BootOrder variables. How are they fit into your scheme?
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
> 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
> ---
> 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=*
>
> As an aside, the hack to call efi_set_bootdev() provides another example
> of why the EFI implementation should have been written using driver model,
> instead of independently of it. I hope that someone can take up this
> challenge and reduce the amount of duplication between the EFI
> implementation and the rest of U-Boot.
>
> Some relevant threads on that are below. The first two show (I believe)
> why this is was all so unnecessary if it had been done correctly from the
> start:
>
> https://lists.denx.de/pipermail/u-boot/2016-May/254804.html
>
> https://lists.denx.de/pipermail/u-boot/2016-August/263501.html
>
> http://patchwork.ozlabs.org/project/uboot/patch/1471374529-61610-2-git-send-email-ag...@suse.de/#1433754
>
> https://lists.denx.de/pipermail/u-boot/2019-March/362190.html
>
> https://yhbt.net/lore/all/20210628134827.GA9516@bill-the-cat/
>
> https://lists.denx.de/pipermail/u-boot/2018-February/321463.html
>
> Sample log on rpi_3_32b:
>
> U-Boot 2021.10-rc2-00043-gccd453aa918-dirty (Aug 28 2021 - 13:58:46 -0600)
>
> DRAM: 992 MiB
> RPI 3 Model B (0xa22082)
> MMC: mmc@7e202000: 0, sdhci@7e30: 1
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:
>serial
> Out: vidconsole
> Err: vidconsole
> Net: No ethernet found.
> starting USB...
> Bus usb@7e98: USB DWC2
> scanning bus usb@7e98 for devices... usb_kbd usb_kbd: Timeout poll on
> interrupt endpoint
> Failed to get keyboard state from device 0c40:8000
> 4 USB Device(s) found
>scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot: 0
> Scanning for bootflows in all bootmethods
> Seq Type State UclassPart Name Filename
> --- --- --
>
> Scanning bootmethod 'mmc@7e202000.bootmethod':
> 0 efi-loader loaded mmc 1 mmc@7e202000.bootmethod.p
> efi/boot/bootarm.efi
> ** Booting bootflow 'mmc@7e202000.bootmethod.part_1'
> Scanning disk m...@7e202000.blk...
> ** Unrecognized filesystem type **
> Card did not respond to voltage select! : -110
> Scanning disk sd...@7e30.blk...
> Disk sd...@7e30.blk not ready
> Found 4 disks
> No EFI system partition
> Booting /efi\boot
> Waiting for Ethernet connection... done.
>
> Fedora (5.11.12-300.fc34.armv7hl) 34 (Workstation Edition)
> UEFI Firmware Settings
>
> Use the ▲ and ▼ keys to change the selection.
> Press 'e' to edit the selected item, or 'c' for a command prompt. Press
> Escape to return to the previous menu.
>The selected entry will be started automatically in 0s.
>
> boot/Kconfig | 21 +++
> boot/Makefile| 1 +
> boot/bootmethod.c| 73 ++
> boot/efiloader.c | 141 +++
> include/bm_efi.h | 42 +
> include/bootmethod.h | 1 +
> 6 files changed, 266 insertions(+), 13 deletions(-)
> create mode 100644 boot/efiloader.c
> create mode 100644 include/bm_efi.h
>
> diff --git a/boot/Kconfig b/boot/Kconfig
> index a1beb182f60..6339ace9413 100644
> --- a/boot/Kconfig
> +++ b/boot/Kconfig
> @@ -310,6 +310,27 @@ config BOOTMETHOD_DISTRO
>
[PATCH] RFC: Support an EFI-loader bootflow
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 and soon bootmgr, 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
---
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=*
As an aside, the hack to call efi_set_bootdev() provides another example
of why the EFI implementation should have been written using driver model,
instead of independently of it. I hope that someone can take up this
challenge and reduce the amount of duplication between the EFI
implementation and the rest of U-Boot.
Some relevant threads on that are below. The first two show (I believe)
why this is was all so unnecessary if it had been done correctly from the
start:
https://lists.denx.de/pipermail/u-boot/2016-May/254804.html
https://lists.denx.de/pipermail/u-boot/2016-August/263501.html
http://patchwork.ozlabs.org/project/uboot/patch/1471374529-61610-2-git-send-email-ag...@suse.de/#1433754
https://lists.denx.de/pipermail/u-boot/2019-March/362190.html
https://yhbt.net/lore/all/20210628134827.GA9516@bill-the-cat/
https://lists.denx.de/pipermail/u-boot/2018-February/321463.html
Sample log on rpi_3_32b:
U-Boot 2021.10-rc2-00043-gccd453aa918-dirty (Aug 28 2021 - 13:58:46 -0600)
DRAM: 992 MiB
RPI 3 Model B (0xa22082)
MMC: mmc@7e202000: 0, sdhci@7e30: 1
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:
serial
Out: vidconsole
Err: vidconsole
Net: No ethernet found.
starting USB...
Bus usb@7e98: USB DWC2
scanning bus usb@7e98 for devices... usb_kbd usb_kbd: Timeout poll on
interrupt endpoint
Failed to get keyboard state from device 0c40:8000
4 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
Scanning for bootflows in all bootmethods
Seq Type State UclassPart Name Filename
--- --- --
Scanning bootmethod 'mmc@7e202000.bootmethod':
0 efi-loader loaded mmc 1 mmc@7e202000.bootmethod.p
efi/boot/bootarm.efi
** Booting bootflow 'mmc@7e202000.bootmethod.part_1'
Scanning disk m...@7e202000.blk...
** Unrecognized filesystem type **
Card did not respond to voltage select! : -110
Scanning disk sd...@7e30.blk...
Disk sd...@7e30.blk not ready
Found 4 disks
No EFI system partition
Booting /efi\boot
Waiting for Ethernet connection... done.
Fedora (5.11.12-300.fc34.armv7hl) 34 (Workstation Edition)
UEFI Firmware Settings
Use the ▲ and ▼ keys to change the selection.
Press 'e' to edit the selected item, or 'c' for a command prompt. Press
Escape to return to the previous menu.
The selected entry will be started automatically in 0s.
boot/Kconfig | 21 +++
boot/Makefile| 1 +
boot/bootmethod.c| 73 ++
boot/efiloader.c | 141 +++
include/bm_efi.h | 42 +
include/bootmethod.h | 1 +
6 files changed, 266 insertions(+), 13 deletions(-)
create mode 100644 boot/efiloader.c
create mode 100644 include/bm_efi.h
diff --git a/boot/Kconfig b/boot/Kconfig
index a1beb182f60..6339ace9413 100644
--- a/boot/Kconfig
+++ b/boot/Kconfig
@@ -310,6 +310,27 @@ config BOOTMETHOD_DISTRO
This provides a way to try out bootmethod on an existing boot flow.
+config BOOTMETHOD_EFILOADER
+ bool "Bootmethod support for EFI boot"
+ depends on BOOTMETHOD && EFI_LOADER
+ default y
+ help
+ Enables support for EFI boot using bootmethods. This makes the
+ bootmethods look for a 'boot.efi' on each filesystem
+ they scan. The resulting file is booted after enabling U-Boot's
+ EFI loader support.
+
+ The depends on the architecture of the board:
+
+aa64 - aarch64 (ARM 64-bit)
+arm - ARM 32-bit
+ia32 - x86 32-bit
+x64 - x86 64-bit
+riscv32 - RISC-V 32-bit
+riscv64 - RISC-V 64-bit
+
+ This provides a way to try out bootmethod on an existing boot flow.
+
config LEGACY_IMAGE_FORMAT
bool "Enable support for the legacy image format"
default y if !FIT_SIGNATURE
diff --git a/boot/Makefile
