efi bootmenu

[François Ozog]

HI Simon

On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg at chromium.org> wrote:

> Hi François,
>
> On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> >
> >
> > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> Hi Masahisa,
> >>
> >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima
> >> <masahisa.kojima at linaro.org> wrote:
> >> >
> >> > Hi Takahiro,
> >> >
> >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi
> >> > <takahiro.akashi at linaro.org> wrote:
> >> > >
> >> > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote:
> >> > > > Hi Heinrich, Ilias, Akashi-san,
> >> > > >
> >> > > > Ilias and I are now discussing to create efi bootmenu, almost
> similar
> >> > > > to UiApp in EDK2.
> >> > >
> >> > > Why not discuss this topic openly in ML?
> >> >
> >> > Yes, I included U-Boot ML.(Sorry, I should include from the the
> beginning.)
> >> >
> >> > >
> >> > > How is this feature related to Simon's bootmethod proposal?
> >> >
> >> > If I correctly understand Simon's bootmethod proposal,
> >> > the difference is that efi bootmenu only targets to implement
> >> > the menu based UI to select/edit/add/delete "Boot####" and
> "BootOrder".
> >>
> >> Yes, EFI would be one of the bootmethods. Others would be U-Boot
> >> scripts, Chrome OS, Android, etc. plus people might add custom ones.
> >>
> >> Also I am thinking that (perhaps) the bootdev part of the standard
> >> boot thing could be used to provide boot devices for EFI.
> >>
> >> If we do have a bootmenu, I wonder if it could be generic, instead of
> >> tied to EFI?
> >
> > EFI BootXXXX specify an array of device paths and boot options. A device
> path is quite a unique construct despite its name.
> > A device path is itself an array of elements, some elements can be a
> file path , configuration information, or diverse metadata. An example of
> configuration information element is UART baud,stop bits, parity along with
> terminal (vt100, ansi…). Another device path element can cover IP address,
> transport information (tcp, UDP and port number).
> > The traditional EFI boot menu is quite crude and does not expose the
> full capabilities of BootXXXX (lacks edit of boot options for instance!).
> >
> > In the long run we will need to leverage all the BootXXXX capabilities
> and those are EFI specific while being OS agnostic.
> > The other U-Boot boot methods (Android , ChromeOS…) are OS specific.
> > The goals are thus very different and making a generic approach seems
> quite compromised. If there is a fully generic framework available in the
> future, it may be possible to integrate the EFI boot menu. But at least
> there is a need to solve, code first, the EFI complexities to fuel the
> generic architecture discussion.
>
> Despite this, the goal of standard boot is to encompass all of this
> within U-Boot. I believe that it will be successful, even if the path
> at present is a bit unclear.
>
So I would suggest we work bottom up. Starting by making EFI menu work,
then extend it more generic or integrated it in a framework. Starting top
down would require a long architecture process based on not enough known
problems to solve for each environment.

>
> [..]
>
> Regards,
> Simon
>


-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog