efi bootmenu

[Mark Kettenis]

> Date: Wed, 5 Jan 2022 09:52:41 +0100
> From: Heinrich Schuchardt <xypron.glpk at gmx.de>
> 
> 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?

The OS doesn't matter so much; it's the terminal emulation software
that matters.  On the BSD's (including macOS) people typically use the
cu(1) utility to connect to a serial console.  This utility doesn't do
any terminal emulation itself, but relies on the environment it runs
in.  I typically use xterm(1), but will often use tmux(1) to keep my
serial console sessions alive.  This mostly emulates a classic VT220
environment, which I do believe to be a superset of ECMA-48.

Anyway, I'm bringing this up since my experience with using the
TianoCore EDK2 "TUI" interface is pretty poor.  It assumes that your
terminal has a fixed size of 80x25, while the standard size of an
xterm is 80x24, which means that inside tmux you'll only have 80x23.
But even with the xterm window resized such that I have an 80x25
console the interface sometimes misbehaves and I end up with elements
in the wrong spot.  And the way the interface relies purely on ESC, Fn
and arrow keys is annoying since the escape sequences generated by
these keys sometimes get misinterpreted.  Now this may all be a poor
implementation on the side of EDK2.  But it makes me believe that a
U-Boot should implement a much simpler interface that is more command
line oriented.  Something like printing a menu and letting the user
select an option by typing a single character or number.

> > 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?

Because Simon did, and I agree with him that U-Boot would be better of
with a way to select a boot device that is independent of the boot
mechanism.  Suppose that as a user I want to install a Linux distro on
my machine.  I copy the installer for that distro to a USB key and I
want to boot it.  But my system is set up to boot from eMMC.  U-Boot
should make it easy to do a one-off boot from USB without burdening
the user with making a choice between EFI and non-EFI boot methods and
just pick the boot method that makes the machine boot from the USB
key.

Cheers,

Mark