On 12/29/21 17:04, Mark Kettenis wrote:
From: François Ozog <francois.o...@linaro.org>
Date: Wed, 29 Dec 2021 14:39:36 +0100

HI Simon

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

Hi François,

On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.o...@linaro.org>
wrote:



Le mar. 28 déc. 2021 à 09:32, Simon Glass <s...@chromium.org> a écrit :

Hi Masahisa,

On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima
<masahisa.koj...@linaro.org> wrote:

Hi Takahiro,

On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi
<takahiro.aka...@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

Reply via email to