efi bootmenu

[Heinrich Schuchardt]

On 12/29/21 17:04, Mark Kettenis wrote:
>> From: François Ozog <francois.ozog at linaro.org>
>> Date: Wed, 29 Dec 2021 14:39:36 +0100
>>
>> 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.
>>
>
> Well, whatever you do, please build something that works well with a
> serial console.  EDK2 makes assumptions the terminal emulation on the
> other side, insists on changing the colors to white on black and
> relies on function keys that need escape sequences.  And escape
> sequences over serial are always iffy since they depend on timing for
> their interpretation.  You can do better for U-Boot.

We already use escape sequences for the U-Boot console and you can't
avoid them for navigation keys. What operating system are you using that
that does not provide a serial terminal emulation which understands ECMA-48?

> Also, keep in mind that BootOrder and Boot#### only really work if
> there is runtime EFI variable support.  So the boot menu should
> include options to select a device to boot from and use the default
> (removable media) bootloader from the ESP on that device.  And a way
> to make this selection stick!  Pretty much all x86 EFI implementations
> provide functionality like that.  I suppose this could be done by
> populating the EFI variable store with appropriate Boot#### variables
> and manipulating BootOrder.  But that would make it hard to generalize
> the boot menu to non-EFI boot flows.

We are talking here about an EFI boot menu. Why do you mention non-EFI?

Best regards

Heinrich