On Thu, 6 Jan 2022 at 12:02, AKASHI Takahiro <[email protected]> wrote: > > On Wed, Dec 29, 2021 at 05:04:17PM +0100, Mark Kettenis wrote: > > > From: François Ozog <[email protected]> > > > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > > > > > HI Simon > > > > > > On Wed, 29 Dec 2021 at 14:36, Simon Glass <[email protected]> wrote: > > > > > > > Hi François, > > > > > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog <[email protected]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <[email protected]> a écrit > > > > > : > > > > >> > > > > >> Hi Masahisa, > > > > >> > > > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > > > >> <[email protected]> wrote: > > > > >> > > > > > >> > Hi Takahiro, > > > > >> > > > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > > > >> > <[email protected]> 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. > > > > 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. > > I think that this issue can/should be addressed in a separate patch > although I have had no progress on my patch[1]. > > -Takahiro Akashi > > [1] https://lists.denx.de/pipermail/u-boot/2021-November/466583.html > > > 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.
Thank you very much for the comments. As discussed here, EFI bootmenu is a start point. The major purpose is disabling U-Boot CLI, then EFI bootmenu allows to select to boot with boot####, and update boot####/bootorder/secure boot keys. I plan to develop EFI bootmenu as a native U-Boot program, then consider to migrate to the EFI app if there are concrete use cases or needs in the future. > Please keep in mind, however, that add/deleting boot options, > [en|dis]abling secure boot or modifying secure variables should > belong to some sort of privileged operations. > I think that we need to have some mechanism to distinguish them > from other menus. It might be system specific, though. Probably I need to implement the password authentication to enter the privileged operations. The password is embedded in the U-Boot config. Regards, Masahisa Kojima
