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. [..] Regards, Simon
