efi bootmenu

[Simon Glass]

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.

[..]

Regards,
Simon