* Re: efi bootmenu [not found] ` <20211221024709.GC40272@laputa> @ 2021-12-21 7:37 ` Masahisa Kojima 2021-12-28 8:31 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: Masahisa Kojima @ 2021-12-21 7:37 UTC (permalink / raw) To: Takahiro Akashi Cc: Heinrich Schuchardt, Ilias Apalodimas, U-Boot Mailing List, Simon Glass Hi Takahiro, On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi <takahiro.akashi@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". > > > Here is some background. > > === > > U-Boot's command line should be completely disabled on secure devices. > > However since U-Boot doesn't (yet) support EFI runtime SetVariable > > for all supported devices, disabling the command line is hard, if even possible. > > If we provide a boot menu, with access to very limited functionality, e.g select > > a boot option and allow users to add/edit/delete existing options, > > we can enhance security and provide a usable alternative to the users. > > > > In addition, if we can add options for managing EFI keys and enabling > > disabling secure boot, we can completely get rid of the u-boot cmd line, > > greatly enhancing platform security > > Basically, it will be a good idea. > 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. > > > === > > > > I am planning to hook the existing "bootefi bootmgr" boot process. > > In "bootefi bootmgr", the planned process will be as follows. > > 1) check "BootNext" > > What do you mean by "check"? I meant the existing bootmgr implementation. If "BootNext" is specified, system boots with "BootNext". > > > 2) show efi bootmenu (*NEW*) > > 3) if user quits efi bootmenu, then boot in accordance with "BootOrder" > > It means efi bootmenu is native u-boot program. > > > > I would like to hear your opinion how this efi bootmenu should be implemented. > > Is it better to implement as EFI application? > > In my personal opinion, we should implement the feature as a separate > EFI application. One of benefits of UEFI interfaces are the ability > to expand functionality with driver modules and applications without > modifying the core. > (One example is iPXE boot that Heinrich often picks up in his comments.) > > If it is an EFI application, it can be easily replaced with others > per system and we may be able to use secure boot to authorise the app > itself. Thank you, I understand the benefit of implementing as EFI App. > > But implementing it as an EFI app is not the goal, and I think you can > start with what you want to do first. > > > Note that I tried to run edk2 UiApp on U-Boot, I found that the > > following protocol > > are required and assertion occurs in DEBUG build. > > gEfiHiiConfigRoutingProtocolGuid > > gEfiHiiFontProtocolGuid > > gEfiHiiImageProtocolGuid > > Probably these protocols can be implemented as dummy stub. > > If I run UiApp in RELEASE build, I encounter exception on UiApp, > > I have not debugged it. > > I didn't investigate this failure in details before, but it might be > related to a (bogus) device path installed into the efi image which > is to be loaded into and invoked from the main memory. > > -Takahiro Akashi > > > Regards, > > Masahisa Kojima Thanks, Masahisa Kojima ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-21 7:37 ` efi bootmenu Masahisa Kojima @ 2021-12-28 8:31 ` Simon Glass 2021-12-28 10:14 ` François Ozog 0 siblings, 1 reply; 12+ messages in thread From: Simon Glass @ 2021-12-28 8:31 UTC (permalink / raw) To: Masahisa Kojima Cc: Takahiro Akashi, Heinrich Schuchardt, Ilias Apalodimas, U-Boot Mailing List Hi Masahisa, On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima <masahisa.kojima@linaro.org> wrote: > > Hi Takahiro, > > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > <takahiro.akashi@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? Regards, Simon > > > > > > Here is some background. > > > === > > > U-Boot's command line should be completely disabled on secure devices. > > > However since U-Boot doesn't (yet) support EFI runtime SetVariable > > > for all supported devices, disabling the command line is hard, if even possible. > > > If we provide a boot menu, with access to very limited functionality, e.g select > > > a boot option and allow users to add/edit/delete existing options, > > > we can enhance security and provide a usable alternative to the users. > > > > > > In addition, if we can add options for managing EFI keys and enabling > > > disabling secure boot, we can completely get rid of the u-boot cmd line, > > > greatly enhancing platform security > > > > Basically, it will be a good idea. > > 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. > > > > > === > > > > > > I am planning to hook the existing "bootefi bootmgr" boot process. > > > In "bootefi bootmgr", the planned process will be as follows. > > > 1) check "BootNext" > > > > What do you mean by "check"? > > I meant the existing bootmgr implementation. If "BootNext" is > specified, system boots with "BootNext". > > > > > > 2) show efi bootmenu (*NEW*) > > > 3) if user quits efi bootmenu, then boot in accordance with "BootOrder" > > > It means efi bootmenu is native u-boot program. > > > > > > I would like to hear your opinion how this efi bootmenu should be implemented. > > > Is it better to implement as EFI application? > > > > In my personal opinion, we should implement the feature as a separate > > EFI application. One of benefits of UEFI interfaces are the ability > > to expand functionality with driver modules and applications without > > modifying the core. > > (One example is iPXE boot that Heinrich often picks up in his comments.) > > > > If it is an EFI application, it can be easily replaced with others > > per system and we may be able to use secure boot to authorise the app > > itself. > > Thank you, I understand the benefit of implementing as EFI App. > > > > > But implementing it as an EFI app is not the goal, and I think you can > > start with what you want to do first. > > > > > Note that I tried to run edk2 UiApp on U-Boot, I found that the > > > following protocol > > > are required and assertion occurs in DEBUG build. > > > gEfiHiiConfigRoutingProtocolGuid > > > gEfiHiiFontProtocolGuid > > > gEfiHiiImageProtocolGuid > > > Probably these protocols can be implemented as dummy stub. > > > If I run UiApp in RELEASE build, I encounter exception on UiApp, > > > I have not debugged it. > > > > I didn't investigate this failure in details before, but it might be > > related to a (bogus) device path installed into the efi image which > > is to be loaded into and invoked from the main memory. > > > > -Takahiro Akashi > > > > > Regards, > > > Masahisa Kojima > > Thanks, > Masahisa Kojima ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-28 8:31 ` Simon Glass @ 2021-12-28 10:14 ` François Ozog 2021-12-29 13:36 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: François Ozog @ 2021-12-28 10:14 UTC (permalink / raw) To: Simon Glass Cc: Heinrich Schuchardt, Ilias Apalodimas, Masahisa Kojima, Takahiro Akashi, U-Boot Mailing List Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > Hi Masahisa, > > On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > <masahisa.kojima@linaro.org> wrote: > > > > Hi Takahiro, > > > > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > <takahiro.akashi@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. > > > Regards, > Simon > > > > > > > > > > > Here is some background. > > > > === > > > > U-Boot's command line should be completely disabled on secure > devices. > > > > However since U-Boot doesn't (yet) support EFI runtime SetVariable > > > > for all supported devices, disabling the command line is hard, if > even possible. > > > > If we provide a boot menu, with access to very limited > functionality, e.g select > > > > a boot option and allow users to add/edit/delete existing options, > > > > we can enhance security and provide a usable alternative to the > users. > > > > > > > > In addition, if we can add options for managing EFI keys and enabling > > > > disabling secure boot, we can completely get rid of the u-boot cmd > line, > > > > greatly enhancing platform security > > > > > > Basically, it will be a good idea. > > > 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. > > > > > > > === > > > > > > > > I am planning to hook the existing "bootefi bootmgr" boot process. > > > > In "bootefi bootmgr", the planned process will be as follows. > > > > 1) check "BootNext" > > > > > > What do you mean by "check"? > > > > I meant the existing bootmgr implementation. If "BootNext" is > > specified, system boots with "BootNext". > > > > > > > > > 2) show efi bootmenu (*NEW*) > > > > 3) if user quits efi bootmenu, then boot in accordance with > "BootOrder" > > > > It means efi bootmenu is native u-boot program. > > > > > > > > I would like to hear your opinion how this efi bootmenu should be > implemented. > > > > Is it better to implement as EFI application? > > > > > > In my personal opinion, we should implement the feature as a separate > > > EFI application. One of benefits of UEFI interfaces are the ability > > > to expand functionality with driver modules and applications without > > > modifying the core. > > > (One example is iPXE boot that Heinrich often picks up in his > comments.) > > > > > > If it is an EFI application, it can be easily replaced with others > > > per system and we may be able to use secure boot to authorise the app > > > itself. > > > > Thank you, I understand the benefit of implementing as EFI App. > > > > > > > > But implementing it as an EFI app is not the goal, and I think you can > > > start with what you want to do first. > > > > > > > Note that I tried to run edk2 UiApp on U-Boot, I found that the > > > > following protocol > > > > are required and assertion occurs in DEBUG build. > > > > gEfiHiiConfigRoutingProtocolGuid > > > > gEfiHiiFontProtocolGuid > > > > gEfiHiiImageProtocolGuid > > > > Probably these protocols can be implemented as dummy stub. > > > > If I run UiApp in RELEASE build, I encounter exception on UiApp, > > > > I have not debugged it. > > > > > > I didn't investigate this failure in details before, but it might be > > > related to a (bogus) device path installed into the efi image which > > > is to be loaded into and invoked from the main memory. > > > > > > -Takahiro Akashi > > > > > > > Regards, > > > > Masahisa Kojima > > > > Thanks, > > Masahisa Kojima > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-28 10:14 ` François Ozog @ 2021-12-29 13:36 ` Simon Glass 2021-12-29 13:39 ` François Ozog 0 siblings, 1 reply; 12+ messages in thread From: Simon Glass @ 2021-12-29 13:36 UTC (permalink / raw) To: François Ozog Cc: Heinrich Schuchardt, Ilias Apalodimas, Masahisa Kojima, Takahiro Akashi, U-Boot Mailing List Hi François, On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> wrote: > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : >> >> Hi Masahisa, >> >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima >> <masahisa.kojima@linaro.org> wrote: >> > >> > Hi Takahiro, >> > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi >> > <takahiro.akashi@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. [..] Regards, Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-29 13:36 ` Simon Glass @ 2021-12-29 13:39 ` François Ozog 2021-12-29 16:04 ` Mark Kettenis 0 siblings, 1 reply; 12+ messages in thread From: François Ozog @ 2021-12-29 13:39 UTC (permalink / raw) To: Simon Glass Cc: Heinrich Schuchardt, Ilias Apalodimas, Masahisa Kojima, Takahiro Akashi, U-Boot Mailing List HI Simon On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: > Hi François, > > On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> > wrote: > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > >> > >> Hi Masahisa, > >> > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > >> <masahisa.kojima@linaro.org> wrote: > >> > > >> > Hi Takahiro, > >> > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > >> > <takahiro.akashi@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. > > [..] > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-29 13:39 ` François Ozog @ 2021-12-29 16:04 ` Mark Kettenis 2022-01-05 8:52 ` Heinrich Schuchardt 2022-01-06 3:02 ` AKASHI Takahiro 0 siblings, 2 replies; 12+ messages in thread From: Mark Kettenis @ 2021-12-29 16:04 UTC (permalink / raw) To: François Ozog Cc: sjg, xypron.glpk, ilias.apalodimas, masahisa.kojima, takahiro.akashi, u-boot > From: François Ozog <francois.ozog@linaro.org> > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > HI Simon > > On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: > > > Hi François, > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> > > wrote: > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > > >> > > >> Hi Masahisa, > > >> > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > >> <masahisa.kojima@linaro.org> wrote: > > >> > > > >> > Hi Takahiro, > > >> > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > >> > <takahiro.akashi@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. 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-29 16:04 ` Mark Kettenis @ 2022-01-05 8:52 ` Heinrich Schuchardt 2022-01-06 13:14 ` Mark Kettenis 2022-01-06 3:02 ` AKASHI Takahiro 1 sibling, 1 reply; 12+ messages in thread From: Heinrich Schuchardt @ 2022-01-05 8:52 UTC (permalink / raw) To: Mark Kettenis Cc: sjg, ilias.apalodimas, masahisa.kojima, takahiro.akashi, u-boot, François Ozog On 12/29/21 17:04, Mark Kettenis wrote: >> From: François Ozog <francois.ozog@linaro.org> >> Date: Wed, 29 Dec 2021 14:39:36 +0100 >> >> HI Simon >> >> On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: >> >>> Hi François, >>> >>> On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> >>> wrote: >>>> >>>> >>>> >>>> Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : >>>>> >>>>> Hi Masahisa, >>>>> >>>>> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima >>>>> <masahisa.kojima@linaro.org> wrote: >>>>>> >>>>>> Hi Takahiro, >>>>>> >>>>>> On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi >>>>>> <takahiro.akashi@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2022-01-05 8:52 ` Heinrich Schuchardt @ 2022-01-06 13:14 ` Mark Kettenis 2022-01-07 9:20 ` Ilias Apalodimas 0 siblings, 1 reply; 12+ messages in thread From: Mark Kettenis @ 2022-01-06 13:14 UTC (permalink / raw) To: Heinrich Schuchardt Cc: sjg, ilias.apalodimas, masahisa.kojima, takahiro.akashi, u-boot, francois.ozog > Date: Wed, 5 Jan 2022 09:52:41 +0100 > From: Heinrich Schuchardt <xypron.glpk@gmx.de> > > On 12/29/21 17:04, Mark Kettenis wrote: > >> From: François Ozog <francois.ozog@linaro.org> > >> Date: Wed, 29 Dec 2021 14:39:36 +0100 > >> > >> HI Simon > >> > >> On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: > >> > >>> Hi François, > >>> > >>> On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> > >>> wrote: > >>>> > >>>> > >>>> > >>>> Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > >>>>> > >>>>> Hi Masahisa, > >>>>> > >>>>> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > >>>>> <masahisa.kojima@linaro.org> wrote: > >>>>>> > >>>>>> Hi Takahiro, > >>>>>> > >>>>>> On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > >>>>>> <takahiro.akashi@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2022-01-06 13:14 ` Mark Kettenis @ 2022-01-07 9:20 ` Ilias Apalodimas 2022-01-08 14:53 ` Simon Glass 0 siblings, 1 reply; 12+ messages in thread From: Ilias Apalodimas @ 2022-01-07 9:20 UTC (permalink / raw) To: Mark Kettenis Cc: Heinrich Schuchardt, sjg, masahisa.kojima, takahiro.akashi, u-boot, francois.ozog Hi Mark, [...] > > > > 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. The concept here is fine, but I think we should agree on how we implement that. IMHO Simon's boot series patches is a huge step forward compared to the distro_bootcmd. However EFI has it's own boot manager and logic. So I see two ways forward: 1. Simon's bootmethod has an abstract entry called 'EFI' or something similar. In that case we just invoke the efi bootmgr. 2. We merge the efibootmgr code into Simon's patches. But isn't that orthogonal to the current discussion? We can just go implement it for EFI now and then wire it up to whatever Simon does. Cheers /Ilias > > Cheers, > > Mark ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2022-01-07 9:20 ` Ilias Apalodimas @ 2022-01-08 14:53 ` Simon Glass 0 siblings, 0 replies; 12+ messages in thread From: Simon Glass @ 2022-01-08 14:53 UTC (permalink / raw) To: Ilias Apalodimas Cc: Mark Kettenis, Heinrich Schuchardt, Masahisa Kojima, AKASHI Takahiro, U-Boot Mailing List, François Ozog Hi Ilias, On Fri, 7 Jan 2022 at 02:20, Ilias Apalodimas <ilias.apalodimas@linaro.org> wrote: > > Hi Mark, > > [...] > > > > > > 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. > > The concept here is fine, but I think we should agree on how we > implement that. IMHO Simon's boot series patches is a huge step > forward compared to the distro_bootcmd. However EFI has it's own boot > manager and logic. So I see two ways forward: > 1. Simon's bootmethod has an abstract entry called 'EFI' or something > similar. In that case we just invoke the efi bootmgr. > 2. We merge the efibootmgr code into Simon's patches. > > But isn't that orthogonal to the current discussion? We can just go > implement it for EFI now and then wire it up to whatever Simon does. Just one tweak here...I think the concept of a boot device (bootdev) could be useful as a way for EFI to find boot devices, so that U-Boot and EFI can share this logic / configuration. Regards, Simon ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2021-12-29 16:04 ` Mark Kettenis 2022-01-05 8:52 ` Heinrich Schuchardt @ 2022-01-06 3:02 ` AKASHI Takahiro 2022-01-06 10:38 ` Masahisa Kojima 1 sibling, 1 reply; 12+ messages in thread From: AKASHI Takahiro @ 2022-01-06 3:02 UTC (permalink / raw) To: Mark Kettenis Cc: Fran??ois Ozog, sjg, xypron.glpk, ilias.apalodimas, masahisa.kojima, u-boot On Wed, Dec 29, 2021 at 05:04:17PM +0100, Mark Kettenis wrote: > > From: François Ozog <francois.ozog@linaro.org> > > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > > > HI Simon > > > > On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: > > > > > Hi François, > > > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> > > > wrote: > > > > > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > > > >> > > > >> Hi Masahisa, > > > >> > > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > > >> <masahisa.kojima@linaro.org> wrote: > > > >> > > > > >> > Hi Takahiro, > > > >> > > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > > >> > <takahiro.akashi@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. > > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: efi bootmenu 2022-01-06 3:02 ` AKASHI Takahiro @ 2022-01-06 10:38 ` Masahisa Kojima 0 siblings, 0 replies; 12+ messages in thread From: Masahisa Kojima @ 2022-01-06 10:38 UTC (permalink / raw) To: AKASHI Takahiro, Mark Kettenis, Fran??ois Ozog, sjg, xypron.glpk, ilias.apalodimas, masahisa.kojima, u-boot On Thu, 6 Jan 2022 at 12:02, AKASHI Takahiro <takahiro.akashi@linaro.org> wrote: > > On Wed, Dec 29, 2021 at 05:04:17PM +0100, Mark Kettenis wrote: > > > From: François Ozog <francois.ozog@linaro.org> > > > Date: Wed, 29 Dec 2021 14:39:36 +0100 > > > > > > HI Simon > > > > > > On Wed, 29 Dec 2021 at 14:36, Simon Glass <sjg@chromium.org> wrote: > > > > > > > Hi François, > > > > > > > > On Tue, 28 Dec 2021 at 03:15, François Ozog <francois.ozog@linaro.org> > > > > wrote: > > > > > > > > > > > > > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass <sjg@chromium.org> a écrit : > > > > >> > > > > >> Hi Masahisa, > > > > >> > > > > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > > > > >> <masahisa.kojima@linaro.org> wrote: > > > > >> > > > > > >> > Hi Takahiro, > > > > >> > > > > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > > > >> > <takahiro.akashi@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. > > > > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-01-08 14:53 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CADQ0-X_vOJoFbv8s8U_GvDXZUAviYw6wX4S0D9sb+PeYyBYTXw@mail.gmail.com> [not found] ` <20211221024709.GC40272@laputa> 2021-12-21 7:37 ` efi bootmenu Masahisa Kojima 2021-12-28 8:31 ` Simon Glass 2021-12-28 10:14 ` François Ozog 2021-12-29 13:36 ` Simon Glass 2021-12-29 13:39 ` François Ozog 2021-12-29 16:04 ` Mark Kettenis 2022-01-05 8:52 ` Heinrich Schuchardt 2022-01-06 13:14 ` Mark Kettenis 2022-01-07 9:20 ` Ilias Apalodimas 2022-01-08 14:53 ` Simon Glass 2022-01-06 3:02 ` AKASHI Takahiro 2022-01-06 10:38 ` Masahisa Kojima
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.