[edk2][PATCH 0/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[edk2][PATCH 0/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

This single patch addresses what we consider to be an overlook of the
current EDK2 codeset in that the ReadyToBoot event is only signaled when
a formal Boot Manager option is executed but not when a Platform Recovery
one is, whereas the boot loaders executed in both cases tend to be similar
in terms of requirements, and therefore, since there is no dedicated event
associated with pre Platform Recovery execution, ReadyToBoot should also
apply there.

Especially, this patch is required to fix an issue that we encounter on
the Raspberry Pi platform (https://github.com/pftf/RPi4/issues/64), as
it uses EmbeddedPkg/Drivers/ConsolePrefDxe to set up the graphical console
as default, but the code to switch to graphical is tied to the ReadyToBoot
event being triggered.

This means that, currently, unless users go to the UEFI options to save
their boot preferences, the console defaults to a non-initialized instance
that happens to be serial.

Obviously, this is very problematic as it means that installation of an
OS such as Debian-Linux (which Platform Recovery will boot into if the
ISO content have been extracted to a bootable drive) will occur on the
serial console rather than the graphical console by default, leaving
users, who do not have a serial adapter plugged in, getting only an
unexpected a black screen instead of the Debian installer...

Also, due to the nature of the UEFI firmware for the Raspberry Pi
platform, which actually resides on the bootable USB or SD media rather
than flash, and therefore is something that platform users are excepted
to update on a whim (with the effect of resetting all the UEFI variables
when they do so), and as opposed to what might be the case for other
platforms, it is not reasonable to expect for users to go to their
settings to set up the Boot Manager options so that they don't end up
using Platform Recovery. As a matter of fact, it's the opposite that is
likely to hold true, with most Raspberry Pi users using Platform
Recovery for their boot process. Especially, considering that the
platform defaults should be fine for most users, we do expect that
the bulk of UEFI vanilla Linux installations on the Raspberry Pi 4 are
going to use Platform Recovery instead of Boot Manager.

As such it is crucial that the Platform Recovery and formal Boot Manager
boot processes do behave similarly in terms of ReadyToBoot event being
signaled, hence the reason for this patch.


Note however that this may require a specs update, as the current UEFI
specs for EFI_BOOT_SERVICES.CreateEventEx() have:

> EFI_EVENT_GROUP_READY_TO_BOOT
>   This event group is notified by the system when the Boot Manager
>   is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this
section to mention that it applies to both Boot Manager and Platform
Recovery.

Regards,

/Pete

Pete Batard (1):
  MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
    recovery

 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
 1 file changed, 9 insertions(+)

-- 
2.21.0.windows.1

[edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Currently, the ReadyToBoot event is only signaled when a formal Boot
Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5, which may
lead to the execution of a boot loader that has similar requirements to a
regular one, yet is not launched as a Boot Manager option, it also becomes
necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical console
is actually usable during platform recovery, as some platforms do rely on
the ConsolePrefDxe driver, which only performs console initialization after
ReadyToBoot is triggered.

This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in
EfiBootManagerProcessLoadOption (), which is the function that sets up the
platform recovery boot process.

Signed-off-by: Pete Batard <pete@akeo.ie>
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
     return EFI_SUCCESS;
   }
 
+  //
+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled
+  //
+  REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
   //
   // Load and start the load option.
   //
-- 
2.21.0.windows.1

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Wang, Sunny (HPS SW)]

Hi Pete. 

Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option. 
	
To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.

By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####). Therefore, your change may also require specification change.

Regards,
Sunny Wang

-----Original Message-----
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Pete Batard
Sent: Tuesday, June 16, 2020 5:56 PM
To: devel@edk2.groups.io
Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
Subject: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).

However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.

Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.

This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.

Signed-off-by: Pete Batard <pete@akeo.ie>
---
 MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index 89372b3b97b8..117f1f5b124c 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
     return EFI_SUCCESS;
   }
 
+  //
+  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
+  //
+  EfiSignalEventReadyToBoot ();
+  //
+  // Report Status Code to indicate ReadyToBoot was signalled  //
+ REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
+ EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+
   //
   // Load and start the load option.
   //
--
2.21.0.windows.1

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> Hi Pete.
> 
> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.

I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is signalled for 
the PlatformRecovery option, so isn't what you describe above exactly 
what we want?

Or is the "one more" the issue, meaning that it would get signalled more 
than once?

> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.

Yes, I've been wondering about that, because BdsEntry.c's 
ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(), 
mentions that it will load will load and start every Driver####, 
SysPrep#### or PlatformRecovery####. But the comment about the while() 
loop in EfiBootManagerProcessLoadOption() only mentions 
PlatformRecovery####.

If needed, I guess we could amend the patch to detect the type of option 
and only signal ReadyToBoot for PlatformRecovery####.

> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.

I don't mind trying an alternative approach, but I don't understand how 
what you describe would help. Can you please be more specific about what 
you have in mind?

Our main issue here is that we must have ReadyToBoot signalled so that 
the ReadyToBoot() function callback from 
EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot 
loader invoked from PlatformRecovery####  to use a properly initialized 
graphical console. So I'm not sure I quite get how switching from one 
PlatformRecovery#### option to another would improve things.

If it helps, here is what we currently default to, in terms of boot 
options, on a Raspberry Pi 4 platform with a newly build firmware:

[Bds]=============Begin Load Options Dumping ...=============
   Driver Options:
   SysPrep Options:
   Boot Options:
     Boot0000: UiApp              0x0109
     Boot0001: UEFI Shell                 0x0000
   PlatformRecovery Options:
     PlatformRecovery0000: Default PlatformRecovery               0x0001
[Bds]=============End Load Options Dumping=============

With this, PlatformRecovery0000 gets executed by default, which is what 
we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB 
and run it, the only issue being that, because ReadyToBoot has not been 
executed, the graphical console is not operative so users can't interact 
with the OS installer.

So I'm really not sure how adding an extra PlatformRecovery#### would 
help. And I'm also not too familiar with how one would go around to add 
such an entry...

> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).

That's something I considered too, but I disagree with this conclusion.

My reasoning is that, if PlatformRecovery#### can execute a regular 
bootloader like /efi/boot/boot####.efi from installation media, then it 
should go through the same kind of initialization that happens for a 
regular boot option, and that should include signalling the ReadyToBoot 
event.

If there was a special bootloader for PlatformRecovery#### (e.g. 
/efi/boot/recovery####.efi) then I would agree with only signalling 
ReadyToBoot for a formal Boot#### option. But that isn't the case, so I 
think it is reasonable to want to have ReadyToBoot also occur when a 
/efi/boot/boot####.efi bootloader is executed from 
PlatformRecovery####., especially when we know it can be crucial to 
ensuring that the end user can actually use the graphical console.

> Therefore, your change may also require specification change.

Yes, I mentioned that in the cover letter for this patch 
(https://edk2.groups.io/g/devel/message/61327), which also describes the 
issue we are trying to solve in greater details. This is what I wrote:

------------------------------------------------------------------------
Note however that this may require a specs update, as the current UEFI
specs for EFI_BOOT_SERVICES.CreateEventEx() have:

 >  EFI_EVENT_GROUP_READY_TO_BOOT
 >    This event group is notified by the system when the Boot Manager
 >    is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this
section to mention that it applies to both Boot Manager and Platform
Recovery.
------------------------------------------------------------------------


Again, I don't have an issue with trying to use an alternate approach to 
solve our problem (though I ultimately believe that, if 
PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then 
we must update the specs and the code to have ReadyToBoot also signalled 
then, because that's the logical thing to do). But right now, I'm not 
seeing how to achieve that when PlatformRecovery#### is the option that 
is used to launch the OS installation the bootloader. So if you can 
provide mode details on how exactly you think creating an alternate 
PlatformRecovery option would help, I would appreciate it.

Regards,

/Pete

> 
> Regards,
> Sunny Wang
> 
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Pete Batard
> Sent: Tuesday, June 16, 2020 5:56 PM
> To: devel@edk2.groups.io
> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
> Subject: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> 
> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
> 
> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
> 
> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
> 
> Signed-off-by: Pete Batard <pete@akeo.ie>
> ---
>   MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 89372b3b97b8..117f1f5b124c 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>       return EFI_SUCCESS;
>     }
>   
> +  //
> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
> +  //
> +  EfiSignalEventReadyToBoot ();
> +  //
> +  // Report Status Code to indicate ReadyToBoot was signalled  //
> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> +
>     //
>     // Load and start the load option.
>     //
> --
> 2.21.0.windows.1
> 
> 
> 
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Wang, Sunny (HPS SW)]

Thanks for checking my comments, Pete. 

> Or is the "one more" the issue, meaning that it would get signaled more than once?
[Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.      

> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
[Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
     1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.
     2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:  
  Status = EfiBootManagerInitializeLoadOption (
             &LoadOption,
             0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
             LoadOptionTypePlatformRecovery,
             LOAD_OPTION_ACTIVE,
             L"Application for recovering boot options",
             FilePath,                                                                -> FilePath is the Application's device path,
             NULL,
             0
             );


> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event. 
[Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option, and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option. If the alternative approach I mentioned works for you, I think that would be an easier solution.

Regards,
Sunny Wang

-----Original Message-----
From: Pete Batard [mailto:pete@akeo.ie] 
Sent: Wednesday, June 17, 2020 6:59 PM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io
Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

Hi Sunny, thanks for looking into this.

On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> Hi Pete.
> 
> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.

I'm not sure I understand how this part is unwanted.

The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?

Or is the "one more" the issue, meaning that it would get signalled more than once?


> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.

Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.

If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.

> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.

I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?

Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.

If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:

[Bds]=============Begin Load Options Dumping ...=============
   Driver Options:
   SysPrep Options:
   Boot Options:
     Boot0000: UiApp              0x0109
     Boot0001: UEFI Shell                 0x0000
   PlatformRecovery Options:
     PlatformRecovery0000: Default PlatformRecovery               0x0001
[Bds]=============End Load Options Dumping=============

With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.

So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...

> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).

That's something I considered too, but I disagree with this conclusion.

My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.

If there was a special bootloader for PlatformRecovery#### (e.g. 
/efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.

> Therefore, your change may also require specification change.

Yes, I mentioned that in the cover letter for this patch (https://edk2.groups.io/g/devel/message/61327 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:

------------------------------------------------------------------------
Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:

 >  EFI_EVENT_GROUP_READY_TO_BOOT
 >    This event group is notified by the system when the Boot Manager
 >    is about to load and execute a boot option.

and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
------------------------------------------------------------------------


Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.

Regards,

/Pete

> 
> Regards,
> Sunny Wang
> 
> -----Original Message-----
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Pete Batard
> Sent: Tuesday, June 16, 2020 5:56 PM
> To: devel@edk2.groups.io
> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; 
> leif@nuviainc.com
> Subject: [edk2-devel] [edk2][PATCH 1/1] 
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
> recovery
> 
> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> 
> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
> 
> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
> 
> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
> 
> Signed-off-by: Pete Batard <pete@akeo.ie>
> ---
>   MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> index 89372b3b97b8..117f1f5b124c 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>       return EFI_SUCCESS;
>     }
>   
> +  //
> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
> +  //
> +  EfiSignalEventReadyToBoot ();
> +  //
> +  // Report Status Code to indicate ReadyToBoot was signalled  // 
> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | 
> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> +
>     //
>     // Load and start the load option.
>     //
> --
> 2.21.0.windows.1
> 
> 
> 
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
> 
>> Or is the "one more" the issue, meaning that it would get signaled more than once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2 
code (i.e. without this proposal applied), and after a user goes into 
the setup to save their boot options in order for regular boot options 
to get executed instead of PlaformRecovery, the OnReadyToBoot event is 
actually called twice.

So my understanding is that, while we of course want to avoid this and 
any patch proposal should actively try to prevent it, it seems we 
already have behaviour in EDK2 that can lead to OnReadyToBoot being 
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For 
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's 
OnReadyToBoot() call. I've also confirmed more specifically that 
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options 
for the Pi platform, so my guess is that it's probably not the only 
platform where OnReadyToBoot might be signalled more than once, and that 
this might be tied to a default EDK2 behaviour. Therefore I don't see 
having a repeated event as a major deal breaker (though, again, if we 
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>       1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what 
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require, 
I don't really like the idea of having to write our own application, as 
it will introduce new possible points of failures and require extra 
maintenance (especially as we will want to be able to handle network 
boot and other options, and before long, I fear that we're going to have 
to write our own Pi specific boot manager). Doing so simply because the 
current Platform Recovery, which does suit our needs otherwise, is not 
designed to call ReadyToBoot does not seem like the best course of 
action in my book.

Instead, I still logically believe that any option that calls a boot 
loader should signal ReadyToBoot, regardless of whether it was launched 
from Boot Manager or Platform Recovery, and that it shouldn't be left to 
each platform to work around that.

Of course, I understand that this would require a specs change, and that 
it also may have ramifications for existing platforms that interpret the 
current specs pedantically. But to me, regardless of what the specs 
appear to be limiting it to right now, the logic of a "ReadyToBoot" 
event is that it should be signalled whenever a bootloader is about to 
be executed, rather than only when a bootloader happened to be launched 
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this 
matter, to see if I'm the only one who believes that we could ultimately 
have more to gain from signalling ReadyToBoot with PlatformRecovery 
options than leaving things as they stand right now...

>       2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>    Status = EfiBootManagerInitializeLoadOption (
>               &LoadOption,
>               0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>               LoadOptionTypePlatformRecovery,
>               LOAD_OPTION_ACTIVE,
>               L"Application for recovering boot options",
>               FilePath,                                                                -> FilePath is the Application's device path,
>               NULL,
>               0
>               );
> 
> 
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,

The way I see it is that the Pi platform is unlikely to be the only one 
where PlatformRecovery is seen as a means to install an OS. Granted, 
this may seem like abusing the option, but since UEFI doesn't provide an 
"Initial OS Install" mode, I would assert that it as good a use of this 
option as any.

In other words, I don't think this improvement would only benefit the Pi 
platform.

> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.

That's a legitimate concern, and I would agree the one major potential 
pitfall of this proposal, if there happens to exist a system where an 
OnReadyToBoot even before running the recovery option can have adverse 
effects.

I don't really believe that such a system exists, because I expect most 
recovery boot loaders to also work (or at least have been designed to 
work) as regular boot options. But I don't have enough experience with 
platform recovery to know if that's a correct assertion to make...

> If the alternative approach I mentioned works for you, I think that would be an easier solution.

Right now, even as the patch proposal has multiple issues that require 
it to be amended (Don't signal ReadyToBoot except for PlatformRecovery 
+ Prevent situations where ReadyToBoot could be signalled multiple 
times) I still see it as both an easier solution than the alternative, 
as well as one that *should* benefit people who design Platform Recovery 
UEFI applications in the long run. So that is why I am still trying to 
advocate for it.

But I very much hear your concerns, and I agree that specs changes are 
better avoided when possible.

Thus, at this stage, even as I don't want to drag this discussion much 
further, I don't feel like I want to commit to one solution or the other 
before we have had a chance to hear other people, who may have their own 
opinion on the matter, express their views.

Regards,

/Pete


> 
> Regards,
> Sunny Wang
> 
> -----Original Message-----
> From: Pete Batard [mailto:pete@akeo.ie]
> Sent: Wednesday, June 17, 2020 6:59 PM
> To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io
> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> Hi Sunny, thanks for looking into this.
> 
> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>> Hi Pete.
>>
>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
> 
> I'm not sure I understand how this part is unwanted.
> 
> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
> 
> Or is the "one more" the issue, meaning that it would get signalled more than once?
> 
> 
>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
> 
> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
> 
> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
> 
>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
> 
> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> 
> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
> 
> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
> 
> [Bds]=============Begin Load Options Dumping ...=============
>     Driver Options:
>     SysPrep Options:
>     Boot Options:
>       Boot0000: UiApp              0x0109
>       Boot0001: UEFI Shell                 0x0000
>     PlatformRecovery Options:
>       PlatformRecovery0000: Default PlatformRecovery               0x0001
> [Bds]=============End Load Options Dumping=============
> 
> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
> 
> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
> 
>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
> 
> That's something I considered too, but I disagree with this conclusion.
> 
> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
> 
> If there was a special bootloader for PlatformRecovery#### (e.g.
> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
> 
>> Therefore, your change may also require specification change.
> 
> Yes, I mentioned that in the cover letter for this patch (https://edk2.groups.io/g/devel/message/61327 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
> 
> ------------------------------------------------------------------------
> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
> 
>   >  EFI_EVENT_GROUP_READY_TO_BOOT
>   >    This event group is notified by the system when the Boot Manager
>   >    is about to load and execute a boot option.
> 
> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
> ------------------------------------------------------------------------
> 
> 
> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
> 
> Regards,
> 
> /Pete
> 
>>
>> Regards,
>> Sunny Wang
>>
>> -----Original Message-----
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Pete Batard
>> Sent: Tuesday, June 16, 2020 5:56 PM
>> To: devel@edk2.groups.io
>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com;
>> leif@nuviainc.com
>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>> recovery
>>
>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>
>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>
>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>
>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>
>> Signed-off-by: Pete Batard <pete@akeo.ie>
>> ---
>>    MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>    1 file changed, 9 insertions(+)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> index 89372b3b97b8..117f1f5b124c 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>        return EFI_SUCCESS;
>>      }
>>    
>> +  //
>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>> +  //
>> +  EfiSignalEventReadyToBoot ();
>> +  //
>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>> +
>>      //
>>      // Load and start the load option.
>>      //
>> --
>> 2.21.0.windows.1
>>
>>
>> 
>>
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Andrei Warkentin]

[-- Attachment #1: Type: text/plain, Size: 16840 bytes --]

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?


A


________________________________
From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Pete Batard via groups.io <pete=akeo.ie@groups.io>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io <devel@edk2.groups.io>
Cc: zhichao.gao@intel.com <zhichao.gao@intel.com>; ray.ni@intel.com <ray.ni@intel.com>; ard.biesheuvel@arm.com <ard.biesheuvel@arm.com>; leif@nuviainc.com <leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
>
>> Or is the "one more" the issue, meaning that it would get signaled more than once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>       1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...

>       2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>    Status = EfiBootManagerInitializeLoadOption (
>               &LoadOption,
>               0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>               LoadOptionTypePlatformRecovery,
>               LOAD_OPTION_ACTIVE,
>               L"Application for recovering boot options",
>               FilePath,                                                                -> FilePath is the Application's device path,
>               NULL,
>               0
>               );
>
>
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,

The way I see it is that the Pi platform is unlikely to be the only one
where PlatformRecovery is seen as a means to install an OS. Granted,
this may seem like abusing the option, but since UEFI doesn't provide an
"Initial OS Install" mode, I would assert that it as good a use of this
option as any.

In other words, I don't think this improvement would only benefit the Pi
platform.

> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.

That's a legitimate concern, and I would agree the one major potential
pitfall of this proposal, if there happens to exist a system where an
OnReadyToBoot even before running the recovery option can have adverse
effects.

I don't really believe that such a system exists, because I expect most
recovery boot loaders to also work (or at least have been designed to
work) as regular boot options. But I don't have enough experience with
platform recovery to know if that's a correct assertion to make...

> If the alternative approach I mentioned works for you, I think that would be an easier solution.

Right now, even as the patch proposal has multiple issues that require
it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
+ Prevent situations where ReadyToBoot could be signalled multiple
times) I still see it as both an easier solution than the alternative,
as well as one that *should* benefit people who design Platform Recovery
UEFI applications in the long run. So that is why I am still trying to
advocate for it.

But I very much hear your concerns, and I agree that specs changes are
better avoided when possible.

Thus, at this stage, even as I don't want to drag this discussion much
further, I don't feel like I want to commit to one solution or the other
before we have had a chance to hear other people, who may have their own
opinion on the matter, express their views.

Regards,

/Pete


>
> Regards,
> Sunny Wang
>
> -----Original Message-----
> From: Pete Batard [mailto:pete@akeo.ie]
> Sent: Wednesday, June 17, 2020 6:59 PM
> To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io
> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>
> Hi Sunny, thanks for looking into this.
>
> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>> Hi Pete.
>>
>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>
> I'm not sure I understand how this part is unwanted.
>
> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>
> Or is the "one more" the issue, meaning that it would get signalled more than once?
>
>
>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>
> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>
> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>
>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>
> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>
> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
>
> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>
> [Bds]=============Begin Load Options Dumping ...=============
>     Driver Options:
>     SysPrep Options:
>     Boot Options:
>       Boot0000: UiApp              0x0109
>       Boot0001: UEFI Shell                 0x0000
>     PlatformRecovery Options:
>       PlatformRecovery0000: Default PlatformRecovery               0x0001
> [Bds]=============End Load Options Dumping=============
>
> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
>
> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>
>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>
> That's something I considered too, but I disagree with this conclusion.
>
> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
>
> If there was a special bootloader for PlatformRecovery#### (e.g.
> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
>
>> Therefore, your change may also require specification change.
>
> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
>
> ------------------------------------------------------------------------
> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>
>   >  EFI_EVENT_GROUP_READY_TO_BOOT
>   >    This event group is notified by the system when the Boot Manager
>   >    is about to load and execute a boot option.
>
> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
> ------------------------------------------------------------------------
>
>
> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
>
> Regards,
>
> /Pete
>
>>
>> Regards,
>> Sunny Wang
>>
>> -----Original Message-----
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Pete Batard
>> Sent: Tuesday, June 16, 2020 5:56 PM
>> To: devel@edk2.groups.io
>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com;
>> leif@nuviainc.com
>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>> recovery
>>
>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>
>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>
>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>
>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>
>> Signed-off-by: Pete Batard <pete@akeo.ie>
>> ---
>>    MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>    1 file changed, 9 insertions(+)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> index 89372b3b97b8..117f1f5b124c 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>        return EFI_SUCCESS;
>>      }
>>
>> +  //
>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>> +  //
>> +  EfiSignalEventReadyToBoot ();
>> +  //
>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>> +
>>      //
>>      // Load and start the load option.
>>      //
>> --
>> 2.21.0.windows.1
>>
>>
>>
>>
>





[-- Attachment #2: Type: text/html, Size: 22587 bytes --]

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

On 2020.06.17 17:36, Andrei Warkentin wrote:
> Thanks Pete.
> 
> I think the question I have, that I hope Tiano veterans can chime in, is 
> whether we are doing the right thing, or if we should be overriding the 
> boot mode? I.e. is it normal that we boot up in recovery until options 
> are saved?

Yes, that's the other part of the problem, that I didn't want to bring 
in because it's Pi-platform specific and I still see OnReadyToBoot as an 
event we logically want to signal during Platform Recovery.

Still, that doesn't mean I wouldn't want to have feedback on this too.

Regards,

/Pete

> 
> 
> A
> 
> 
> ------------------------------------------------------------------------
> *From:* devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Pete 
> Batard via groups.io <pete=akeo.ie@groups.io>
> *Sent:* Wednesday, June 17, 2020 11:34 AM
> *To:* Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io 
> <devel@edk2.groups.io>
> *Cc:* zhichao.gao@intel.com <zhichao.gao@intel.com>; ray.ni@intel.com 
> <ray.ni@intel.com>; ard.biesheuvel@arm.com <ard.biesheuvel@arm.com>; 
> leif@nuviainc.com <leif@nuviainc.com>
> *Subject:* Re: [edk2-devel] [edk2][PATCH 1/1] 
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>> Thanks for checking my comments, Pete.
>> 
>>> Or is the "one more" the issue, meaning that it would get signaled more than once?
>> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.
> 
> Okay.
> 
> One element that I'm going to point out is that, with the current EDK2
> code (i.e. without this proposal applied), and after a user goes into
> the setup to save their boot options in order for regular boot options
> to get executed instead of PlaformRecovery, the OnReadyToBoot event is
> actually called twice.
> 
> So my understanding is that, while we of course want to avoid this and
> any patch proposal should actively try to prevent it, it seems we
> already have behaviour in EDK2 that can lead to OnReadyToBoot being
> signalled more than once.
> 
> At least the current Pi 4 platform does demonstrate this behaviour. For
> instance, if you run DEBUG, you will see two instances of:
> 
>     RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> 
> which is a one-instance message generated from the ConsolePrefDxe's
> OnReadyToBoot() call. I've also confirmed more specifically that
> OnReadyToBoot() is indeed called twice.
> 
> I don't recall us doing much of any special with regards to boot options
> for the Pi platform, so my guess is that it's probably not the only
> platform where OnReadyToBoot might be signalled more than once, and that
> this might be tied to a default EDK2 behaviour. Therefore I don't see
> having a repeated event as a major deal breaker (though, again, if we
> can avoid that, we of course will want to).
> 
>>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>>       1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.
> 
> So that would basically be adding code that duplicates, in part, what
> Platform Recovery already does.
> 
> I have to be honest: Even outside of the extra work this would require,
> I don't really like the idea of having to write our own application, as
> it will introduce new possible points of failures and require extra
> maintenance (especially as we will want to be able to handle network
> boot and other options, and before long, I fear that we're going to have
> to write our own Pi specific boot manager). Doing so simply because the
> current Platform Recovery, which does suit our needs otherwise, is not
> designed to call ReadyToBoot does not seem like the best course of
> action in my book.
> 
> Instead, I still logically believe that any option that calls a boot
> loader should signal ReadyToBoot, regardless of whether it was launched
> from Boot Manager or Platform Recovery, and that it shouldn't be left to
> each platform to work around that.
> 
> Of course, I understand that this would require a specs change, and that
> it also may have ramifications for existing platforms that interpret the
> current specs pedantically. But to me, regardless of what the specs
> appear to be limiting it to right now, the logic of a "ReadyToBoot"
> event is that it should be signalled whenever a bootloader is about to
> be executed, rather than only when a bootloader happened to be launched
> through a formal Boot Manager option.
> 
> I would therefore appreciate if other people could weigh in on this
> matter, to see if I'm the only one who believes that we could ultimately
> have more to gain from signalling ReadyToBoot with PlatformRecovery
> options than leaving things as they stand right now...
> 
>>       2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>>    Status = EfiBootManagerInitializeLoadOption (
>>               &LoadOption,
>>               0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>>               LoadOptionTypePlatformRecovery,
>>               LOAD_OPTION_ACTIVE,
>>               L"Application for recovering boot options",
>>               FilePath,                                                                -> FilePath is the Application's device path,
>>               NULL,
>>               0
>>               );
>> 
>> 
>>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include  signaling the ReadyToBoot event.
>> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to  the case that OS is loaded by "Default PlatformRecovery" option,
> 
> The way I see it is that the Pi platform is unlikely to be the only one
> where PlatformRecovery is seen as a means to install an OS. Granted,
> this may seem like abusing the option, but since UEFI doesn't provide an
> "Initial OS Install" mode, I would assert that it as good a use of this
> option as any.
> 
> In other words, I don't think this improvement would only benefit the Pi
> platform.
> 
>> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.
> 
> That's a legitimate concern, and I would agree the one major potential
> pitfall of this proposal, if there happens to exist a system where an
> OnReadyToBoot even before running the recovery option can have adverse
> effects.
> 
> I don't really believe that such a system exists, because I expect most
> recovery boot loaders to also work (or at least have been designed to
> work) as regular boot options. But I don't have enough experience with
> platform recovery to know if that's a correct assertion to make...
> 
>> If the alternative approach I mentioned works for you, I think that would be an easier solution.
> 
> Right now, even as the patch proposal has multiple issues that require
> it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
> + Prevent situations where ReadyToBoot could be signalled multiple
> times) I still see it as both an easier solution than the alternative,
> as well as one that *should* benefit people who design Platform Recovery
> UEFI applications in the long run. So that is why I am still trying to
> advocate for it.
> 
> But I very much hear your concerns, and I agree that specs changes are
> better avoided when possible.
> 
> Thus, at this stage, even as I don't want to drag this discussion much
> further, I don't feel like I want to commit to one solution or the other
> before we have had a chance to hear other people, who may have their own
> opinion on the matter, express their views.
> 
> Regards,
> 
> /Pete
> 
> 
>> 
>> Regards,
>> Sunny Wang
>> 
>> -----Original Message-----
>> From: Pete Batard [mailto:pete@akeo.ie]
>> Sent: Wednesday, June 17, 2020 6:59 PM
>> To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io
>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com; leif@nuviainc.com
>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>> 
>> Hi Sunny, thanks for looking into this.
>> 
>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>> Hi Pete.
>>>
>>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>> 
>> I'm not sure I understand how this part is unwanted.
>> 
>> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>> 
>> Or is the "one more" the issue, meaning that it would get signalled more than once?
>> 
>> 
>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>> 
>> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
>> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>> 
>> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>> 
>>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>> 
>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>> 
>> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized  graphical console. So I'm not sure I quite get how switching from one 
> PlatformRecovery#### option to another would improve things.
>> 
>> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>> 
>> [Bds]=============Begin Load Options Dumping ...=============
>>     Driver Options:
>>     SysPrep Options:
>>     Boot Options:
>>       Boot0000: UiApp              0x0109
>>       Boot0001: UEFI Shell                 0x0000
>>     PlatformRecovery Options:
>>       PlatformRecovery0000: Default PlatformRecovery               0x0001
>> [Bds]=============End Load Options Dumping=============
>> 
>> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not  operative so users can't interact with the OS installer.
>> 
>> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>> 
>>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>> 
>> That's something I considered too, but I disagree with this conclusion.
>> 
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling  the ReadyToBoot event.
>> 
>> If there was a special bootloader for PlatformRecovery#### (e.g.
>> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed  from PlatformRecovery####., especially when we know it can be crucial 
> to ensuring that the end user can actually use the graphical console.
>> 
>>> Therefore, your change may also require specification change.
>> 
>> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 
> ), which also describes the issue we are trying to solve in greater 
> details. This is what I wrote:
>> 
>> ------------------------------------------------------------------------
>> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>> 
>>   >  EFI_EVENT_GROUP_READY_TO_BOOT
>>   >    This event group is notified by the system when the Boot Manager
>>   >    is about to load and execute a boot option.
>> 
>> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
>> ------------------------------------------------------------------------
>> 
>> 
>> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot  also signalled then, because that's the logical thing to do). But 
> right now, I'm not seeing how to achieve that when PlatformRecovery#### 
> is the option that is used to launch the OS installation the bootloader. 
> So if you can provide mode details on how exactly you think creating an 
> alternate PlatformRecovery option would help, I would appreciate it.
>> 
>> Regards,
>> 
>> /Pete
>> 
>>>
>>> Regards,
>>> Sunny Wang
>>>
>>> -----Original Message-----
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> Pete Batard
>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>> To: devel@edk2.groups.io
>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; ard.biesheuvel@arm.com;
>>> leif@nuviainc.com
>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>> recovery
>>>
>>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>>
>>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot  when a Platform Recovery boot loader runs.
>>>
>>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>>
>>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>>
>>> Signed-off-by: Pete Batard <pete@akeo.ie>
>>> ---
>>>    MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>>    1 file changed, 9 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> index 89372b3b97b8..117f1f5b124c 100644
>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>        return EFI_SUCCESS;
>>>      }
>>>    
>>> +  //
>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>>> +  //
>>> +  EfiSignalEventReadyToBoot ();
>>> +  //
>>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>> +
>>>      //
>>>      // Load and start the load option.
>>>      //
>>> --
>>> 2.21.0.windows.1
>>>
>>>
>>> 
>>>
>> 
> 
> 
> 
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

[-- Attachment #1: Type: text/plain, Size: 19254 bytes --]

The UEFI spec (3.1.7) says:


"After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

The way I read this, I expect ReadyToBoot to be signaled after SysPrep#### (if any) are processed, but before Boot#### are processed. Is my understanding correct that this language implies ReadyToBoot need to be signaled even if BootOrder does not contain any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to this patch (signaling it in PlatformRecovery?)



From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Andrei Warkentin via groups.io
Sent: Wednesday, June 17, 2020 12:37 PM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; devel@edk2.groups.io; pete@akeo.ie
Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?


A


________________________________
From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> on behalf of Pete Batard via groups.io <pete=akeo.ie@groups.io<mailto:pete=akeo.ie@groups.io>>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>
Cc: zhichao.gao@intel.com<mailto:zhichao.gao@intel.com> <zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>>; ray.ni@intel.com<mailto:ray.ni@intel.com> <ray.ni@intel.com<mailto:ray.ni@intel.com>>; ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com> <ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com>>; leif@nuviainc.com<mailto:leif@nuviainc.com> <leif@nuviainc.com<mailto:leif@nuviainc.com>>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
>
>> Or is the "one more" the issue, meaning that it would get signaled more than once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>       1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...

>       2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>    Status = EfiBootManagerInitializeLoadOption (
>               &LoadOption,
>               0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>               LoadOptionTypePlatformRecovery,
>               LOAD_OPTION_ACTIVE,
>               L"Application for recovering boot options",
>               FilePath,                                                                -> FilePath is the Application's device path,
>               NULL,
>               0
>               );
>
>
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,

The way I see it is that the Pi platform is unlikely to be the only one
where PlatformRecovery is seen as a means to install an OS. Granted,
this may seem like abusing the option, but since UEFI doesn't provide an
"Initial OS Install" mode, I would assert that it as good a use of this
option as any.

In other words, I don't think this improvement would only benefit the Pi
platform.

> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.

That's a legitimate concern, and I would agree the one major potential
pitfall of this proposal, if there happens to exist a system where an
OnReadyToBoot even before running the recovery option can have adverse
effects.

I don't really believe that such a system exists, because I expect most
recovery boot loaders to also work (or at least have been designed to
work) as regular boot options. But I don't have enough experience with
platform recovery to know if that's a correct assertion to make...

> If the alternative approach I mentioned works for you, I think that would be an easier solution.

Right now, even as the patch proposal has multiple issues that require
it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
+ Prevent situations where ReadyToBoot could be signalled multiple
times) I still see it as both an easier solution than the alternative,
as well as one that *should* benefit people who design Platform Recovery
UEFI applications in the long run. So that is why I am still trying to
advocate for it.

But I very much hear your concerns, and I agree that specs changes are
better avoided when possible.

Thus, at this stage, even as I don't want to drag this discussion much
further, I don't feel like I want to commit to one solution or the other
before we have had a chance to hear other people, who may have their own
opinion on the matter, express their views.

Regards,

/Pete


>
> Regards,
> Sunny Wang
>
> -----Original Message-----
> From: Pete Batard [mailto:pete@akeo.ie]
> Sent: Wednesday, June 17, 2020 6:59 PM
> To: Wang, Sunny (HPS SW) <sunnywang@hpe.com<mailto:sunnywang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>
> Cc: zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>; ray.ni@intel.com<mailto:ray.ni@intel.com>; ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com>; leif@nuviainc.com<mailto:leif@nuviainc.com>
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>
> Hi Sunny, thanks for looking into this.
>
> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>> Hi Pete.
>>
>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>
> I'm not sure I understand how this part is unwanted.
>
> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>
> Or is the "one more" the issue, meaning that it would get signalled more than once?
>
>
>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>
> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>
> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>
>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>
> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>
> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
>
> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>
> [Bds]=============Begin Load Options Dumping ...=============
>     Driver Options:
>     SysPrep Options:
>     Boot Options:
>       Boot0000: UiApp              0x0109
>       Boot0001: UEFI Shell                 0x0000
>     PlatformRecovery Options:
>       PlatformRecovery0000: Default PlatformRecovery               0x0001
> [Bds]=============End Load Options Dumping=============
>
> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
>
> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>
>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>
> That's something I considered too, but I disagree with this conclusion.
>
> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
>
> If there was a special bootloader for PlatformRecovery#### (e.g.
> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
>
>> Therefore, your change may also require specification change.
>
> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
>
> ------------------------------------------------------------------------
> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>
>   >  EFI_EVENT_GROUP_READY_TO_BOOT
>   >    This event group is notified by the system when the Boot Manager
>   >    is about to load and execute a boot option.
>
> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
> ------------------------------------------------------------------------
>
>
> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
>
> Regards,
>
> /Pete
>
>>
>> Regards,
>> Sunny Wang
>>
>> -----Original Message-----
>> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of
>> Pete Batard
>> Sent: Tuesday, June 16, 2020 5:56 PM
>> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
>> Cc: zhichao.gao@intel.com<mailto:zhichao.gao@intel.com>; ray.ni@intel.com<mailto:ray.ni@intel.com>; ard.biesheuvel@arm.com<mailto:ard.biesheuvel@arm.com>;
>> leif@nuviainc.com<mailto:leif@nuviainc.com>
>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>> recovery
>>
>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>
>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>
>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>
>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>
>> Signed-off-by: Pete Batard <pete@akeo.ie<mailto:pete@akeo.ie>>
>> ---
>>    MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>    1 file changed, 9 insertions(+)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> index 89372b3b97b8..117f1f5b124c 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>        return EFI_SUCCESS;
>>      }
>>
>> +  //
>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>> +  //
>> +  EfiSignalEventReadyToBoot ();
>> +  //
>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>> +
>>      //
>>      // Load and start the load option.
>>      //
>> --
>> 2.21.0.windows.1
>>
>>
>>
>>
>




IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[-- Attachment #2: Type: text/html, Size: 28555 bytes --]

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

I worked with Pete offline on this..

This code seems to be violating the UEFI Spec:

https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763

  //
  // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute
  //    the boot option.
  //
  if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
    DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
    BmStopHotkeyService (NULL, NULL);
  } else {
    EfiSignalEventReadyToBoot();
    //
    // Report Status Code to indicate ReadyToBoot was signalled
    //
    REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
    //
    // 4. Repair system through DriverHealth protocol
    //
    BmRepairAllControllers (0);
  }

The UEFI Spec section 3.1.7 clearly states that Boot Options (and their FilePathList) *shall not* be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:

"After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

This is a prescriptive language that is stronger than the language in section 7.1 which defines the ReadyToBoot event group in a general way:

"EFI_EVENT_GROUP_RESET_SYSTEM
This event group is notified by the system when ResetSystem() is invoked and the system is about to be reset. The event group is only notified prior to ExitBootServices() invocation."

The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) need to move before the code that is processing BootOption->FilePath. In fact, why is this signaling even a BootManager task? It should be a higher level BDS task (after processing SysPrp and before processing Boot options, per the spec). This would be somewhere around https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007 where SysPrep is processed.

This should also take care of the issue Pete reported in this thread, without the need for explicitly signaling ReadyToBoot from PlatformRecovery (or changing the UEFI spec).

Thanks,
--Samer



From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
Sent: Wednesday, June 17, 2020 12:42 PM
To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; pete@akeo.ie
Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

The UEFI spec (3.1.7) says:

"After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."

The way I read this, I expect ReadyToBoot to be signaled after SysPrep#### (if any) are processed, but before Boot#### are processed. Is my understanding correct that this language implies ReadyToBoot need to be signaled even if BootOrder does not contain any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to this patch (signaling it in PlatformRecovery?)



From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On Behalf Of Andrei Warkentin via groups.io
Sent: Wednesday, June 17, 2020 12:37 PM
To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; mailto:leif@nuviainc.com
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

Thanks Pete.

I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?


A


________________________________________
From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
Sent: Wednesday, June 17, 2020 11:34 AM
To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>; mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>; mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>; mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> Thanks for checking my comments, Pete.
>
>> Or is the "one more" the issue, meaning that it would get signaled more than once?
> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.

Okay.

One element that I'm going to point out is that, with the current EDK2
code (i.e. without this proposal applied), and after a user goes into
the setup to save their boot options in order for regular boot options
to get executed instead of PlaformRecovery, the OnReadyToBoot event is
actually called twice.

So my understanding is that, while we of course want to avoid this and
any patch proposal should actively try to prevent it, it seems we
already have behaviour in EDK2 that can lead to OnReadyToBoot being
signalled more than once.

At least the current Pi 4 platform does demonstrate this behaviour. For
instance, if you run DEBUG, you will see two instances of:

   RemoveDtStdoutPath: could not retrieve DT blob - Not Found

which is a one-instance message generated from the ConsolePrefDxe's
OnReadyToBoot() call. I've also confirmed more specifically that
OnReadyToBoot() is indeed called twice.

I don't recall us doing much of any special with regards to boot options
for the Pi platform, so my guess is that it's probably not the only
platform where OnReadyToBoot might be signalled more than once, and that
this might be tied to a default EDK2 behaviour. Therefore I don't see
having a repeated event as a major deal breaker (though, again, if we
can avoid that, we of course will want to).

>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>       1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.

So that would basically be adding code that duplicates, in part, what
Platform Recovery already does.

I have to be honest: Even outside of the extra work this would require,
I don't really like the idea of having to write our own application, as
it will introduce new possible points of failures and require extra
maintenance (especially as we will want to be able to handle network
boot and other options, and before long, I fear that we're going to have
to write our own Pi specific boot manager). Doing so simply because the
current Platform Recovery, which does suit our needs otherwise, is not
designed to call ReadyToBoot does not seem like the best course of
action in my book.

Instead, I still logically believe that any option that calls a boot
loader should signal ReadyToBoot, regardless of whether it was launched
from Boot Manager or Platform Recovery, and that it shouldn't be left to
each platform to work around that.

Of course, I understand that this would require a specs change, and that
it also may have ramifications for existing platforms that interpret the
current specs pedantically. But to me, regardless of what the specs
appear to be limiting it to right now, the logic of a "ReadyToBoot"
event is that it should be signalled whenever a bootloader is about to
be executed, rather than only when a bootloader happened to be launched
through a formal Boot Manager option.

I would therefore appreciate if other people could weigh in on this
matter, to see if I'm the only one who believes that we could ultimately
have more to gain from signalling ReadyToBoot with PlatformRecovery
options than leaving things as they stand right now...

>       2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>    Status = EfiBootManagerInitializeLoadOption (
>               &LoadOption,
>               0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>               LoadOptionTypePlatformRecovery,
>               LOAD_OPTION_ACTIVE,
>               L"Application for recovering boot options",
>               FilePath,                                                                -> FilePath is the Application's device path,
>               NULL,
>               0
>               );
>
>
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,

The way I see it is that the Pi platform is unlikely to be the only one
where PlatformRecovery is seen as a means to install an OS. Granted,
this may seem like abusing the option, but since UEFI doesn't provide an
"Initial OS Install" mode, I would assert that it as good a use of this
option as any.

In other words, I don't think this improvement would only benefit the Pi
platform.

> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.

That's a legitimate concern, and I would agree the one major potential
pitfall of this proposal, if there happens to exist a system where an
OnReadyToBoot even before running the recovery option can have adverse
effects.

I don't really believe that such a system exists, because I expect most
recovery boot loaders to also work (or at least have been designed to
work) as regular boot options. But I don't have enough experience with
platform recovery to know if that's a correct assertion to make...

> If the alternative approach I mentioned works for you, I think that would be an easier solution.

Right now, even as the patch proposal has multiple issues that require
it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
+ Prevent situations where ReadyToBoot could be signalled multiple
times) I still see it as both an easier solution than the alternative,
as well as one that *should* benefit people who design Platform Recovery
UEFI applications in the long run. So that is why I am still trying to
advocate for it.

But I very much hear your concerns, and I agree that specs changes are
better avoided when possible.

Thus, at this stage, even as I don't want to drag this discussion much
further, I don't feel like I want to commit to one solution or the other
before we have had a chance to hear other people, who may have their own
opinion on the matter, express their views.

Regards,

/Pete


>
> Regards,
> Sunny Wang
>
> -----Original Message-----
> From: Pete Batard [mailto:pete@akeo.ie]
> Sent: Wednesday, June 17, 2020 6:59 PM
> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io
> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>
> Hi Sunny, thanks for looking into this.
>
> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>> Hi Pete.
>>
>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>
> I'm not sure I understand how this part is unwanted.
>
> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>
> Or is the "one more" the issue, meaning that it would get signalled more than once?
>
>
>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>
> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>
> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>
>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>
> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>
> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
>
> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>
> [Bds]=============Begin Load Options Dumping ...=============
>     Driver Options:
>     SysPrep Options:
>     Boot Options:
>       Boot0000: UiApp              0x0109
>       Boot0001: UEFI Shell                 0x0000
>     PlatformRecovery Options:
>       PlatformRecovery0000: Default PlatformRecovery               0x0001
> [Bds]=============End Load Options Dumping=============
>
> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
>
> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>
>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>
> That's something I considered too, but I disagree with this conclusion.
>
> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
>
> If there was a special bootloader for PlatformRecovery#### (e.g.
> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
>
>> Therefore, your change may also require specification change.
>
> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
>
> ------------------------------------------------------------------------
> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>
>   >  EFI_EVENT_GROUP_READY_TO_BOOT
>   >    This event group is notified by the system when the Boot Manager
>   >    is about to load and execute a boot option.
>
> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
> ------------------------------------------------------------------------
>
>
> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
>
> Regards,
>
> /Pete
>
>>
>> Regards,
>> Sunny Wang
>>
>> -----Original Message-----
>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Pete Batard
>> Sent: Tuesday, June 16, 2020 5:56 PM
>> To: mailto:devel@edk2.groups.io
>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com;
>> mailto:leif@nuviainc.com
>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>> recovery
>>
>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>
>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>
>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>
>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>
>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>> ---
>>    MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>    1 file changed, 9 insertions(+)
>>
>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> index 89372b3b97b8..117f1f5b124c 100644
>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>        return EFI_SUCCESS;
>>      }
>>
>> +  //
>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>> +  //
>> +  EfiSignalEventReadyToBoot ();
>> +  //
>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>> +
>>      //
>>      // Load and start the load option.
>>      //
>> --
>> 2.21.0.windows.1
>>
>>
>>
>>
>


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Please note that I have created a bug report 
(https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the 
non-compliance issue was raised during the course of the discussion below.

Regards,

/Pete


On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
> I worked with Pete offline on this..
> 
> This code seems to be violating the UEFI Spec:
> 
> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
> 
>    //
>    // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute
>    //    the boot option.
>    //
>    if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
>      DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
>      BmStopHotkeyService (NULL, NULL);
>    } else {
>      EfiSignalEventReadyToBoot();
>      //
>      // Report Status Code to indicate ReadyToBoot was signalled
>      //
>      REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>      //
>      // 4. Repair system through DriverHealth protocol
>      //
>      BmRepairAllControllers (0);
>    }
> 
> The UEFI Spec section 3.1.7 clearly states that Boot Options (and their FilePathList) *shall not* be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
> 
> "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
> 
> This is a prescriptive language that is stronger than the language in section 7.1 which defines the ReadyToBoot event group in a general way:
> 
> "EFI_EVENT_GROUP_RESET_SYSTEM
> This event group is notified by the system when ResetSystem() is invoked and the system is about to be reset. The event group is only notified prior to ExitBootServices() invocation."
> 
> The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) need to move before the code that is processing BootOption->FilePath. In fact, why is this signaling even a BootManager task? It should be a higher level BDS task (after processing SysPrp and before processing Boot options, per the spec). This would be somewhere around https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007 where SysPrep is processed.
> 
> This should also take care of the issue Pete reported in this thread, without the need for explicitly signaling ReadyToBoot from PlatformRecovery (or changing the UEFI spec).
> 
> Thanks,
> --Samer
> 
> 
> 
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
> Sent: Wednesday, June 17, 2020 12:42 PM
> To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; pete@akeo.ie
> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> The UEFI spec (3.1.7) says:
> 
> "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
> 
> The way I read this, I expect ReadyToBoot to be signaled after SysPrep#### (if any) are processed, but before Boot#### are processed. Is my understanding correct that this language implies ReadyToBoot need to be signaled even if BootOrder does not contain any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to this patch (signaling it in PlatformRecovery?)
> 
> 
> 
> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On Behalf Of Andrei Warkentin via groups.io
> Sent: Wednesday, June 17, 2020 12:37 PM
> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; mailto:leif@nuviainc.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> Thanks Pete.
> 
> I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?
> 
> 
> A
> 
> 
> ________________________________________
> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
> Sent: Wednesday, June 17, 2020 11:34 AM
> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>; mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>; mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>; mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>> Thanks for checking my comments, Pete.
>>
>>> Or is the "one more" the issue, meaning that it would get signaled more than once?
>> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.
> 
> Okay.
> 
> One element that I'm going to point out is that, with the current EDK2
> code (i.e. without this proposal applied), and after a user goes into
> the setup to save their boot options in order for regular boot options
> to get executed instead of PlaformRecovery, the OnReadyToBoot event is
> actually called twice.
> 
> So my understanding is that, while we of course want to avoid this and
> any patch proposal should actively try to prevent it, it seems we
> already have behaviour in EDK2 that can lead to OnReadyToBoot being
> signalled more than once.
> 
> At least the current Pi 4 platform does demonstrate this behaviour. For
> instance, if you run DEBUG, you will see two instances of:
> 
>     RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> 
> which is a one-instance message generated from the ConsolePrefDxe's
> OnReadyToBoot() call. I've also confirmed more specifically that
> OnReadyToBoot() is indeed called twice.
> 
> I don't recall us doing much of any special with regards to boot options
> for the Pi platform, so my guess is that it's probably not the only
> platform where OnReadyToBoot might be signalled more than once, and that
> this might be tied to a default EDK2 behaviour. Therefore I don't see
> having a repeated event as a major deal breaker (though, again, if we
> can avoid that, we of course will want to).
> 
>>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>>        1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.
> 
> So that would basically be adding code that duplicates, in part, what
> Platform Recovery already does.
> 
> I have to be honest: Even outside of the extra work this would require,
> I don't really like the idea of having to write our own application, as
> it will introduce new possible points of failures and require extra
> maintenance (especially as we will want to be able to handle network
> boot and other options, and before long, I fear that we're going to have
> to write our own Pi specific boot manager). Doing so simply because the
> current Platform Recovery, which does suit our needs otherwise, is not
> designed to call ReadyToBoot does not seem like the best course of
> action in my book.
> 
> Instead, I still logically believe that any option that calls a boot
> loader should signal ReadyToBoot, regardless of whether it was launched
> from Boot Manager or Platform Recovery, and that it shouldn't be left to
> each platform to work around that.
> 
> Of course, I understand that this would require a specs change, and that
> it also may have ramifications for existing platforms that interpret the
> current specs pedantically. But to me, regardless of what the specs
> appear to be limiting it to right now, the logic of a "ReadyToBoot"
> event is that it should be signalled whenever a bootloader is about to
> be executed, rather than only when a bootloader happened to be launched
> through a formal Boot Manager option.
> 
> I would therefore appreciate if other people could weigh in on this
> matter, to see if I'm the only one who believes that we could ultimately
> have more to gain from signalling ReadyToBoot with PlatformRecovery
> options than leaving things as they stand right now...
> 
>>        2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>>     Status = EfiBootManagerInitializeLoadOption (
>>                &LoadOption,
>>                0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>>                LoadOptionTypePlatformRecovery,
>>                LOAD_OPTION_ACTIVE,
>>                L"Application for recovering boot options",
>>                FilePath,                                                                -> FilePath is the Application's device path,
>>                NULL,
>>                0
>>                );
>>
>>
>>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
>> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,
> 
> The way I see it is that the Pi platform is unlikely to be the only one
> where PlatformRecovery is seen as a means to install an OS. Granted,
> this may seem like abusing the option, but since UEFI doesn't provide an
> "Initial OS Install" mode, I would assert that it as good a use of this
> option as any.
> 
> In other words, I don't think this improvement would only benefit the Pi
> platform.
> 
>> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.
> 
> That's a legitimate concern, and I would agree the one major potential
> pitfall of this proposal, if there happens to exist a system where an
> OnReadyToBoot even before running the recovery option can have adverse
> effects.
> 
> I don't really believe that such a system exists, because I expect most
> recovery boot loaders to also work (or at least have been designed to
> work) as regular boot options. But I don't have enough experience with
> platform recovery to know if that's a correct assertion to make...
> 
>> If the alternative approach I mentioned works for you, I think that would be an easier solution.
> 
> Right now, even as the patch proposal has multiple issues that require
> it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
> + Prevent situations where ReadyToBoot could be signalled multiple
> times) I still see it as both an easier solution than the alternative,
> as well as one that *should* benefit people who design Platform Recovery
> UEFI applications in the long run. So that is why I am still trying to
> advocate for it.
> 
> But I very much hear your concerns, and I agree that specs changes are
> better avoided when possible.
> 
> Thus, at this stage, even as I don't want to drag this discussion much
> further, I don't feel like I want to commit to one solution or the other
> before we have had a chance to hear other people, who may have their own
> opinion on the matter, express their views.
> 
> Regards,
> 
> /Pete
> 
> 
>>
>> Regards,
>> Sunny Wang
>>
>> -----Original Message-----
>> From: Pete Batard [mailto:pete@akeo.ie]
>> Sent: Wednesday, June 17, 2020 6:59 PM
>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io
>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>>
>> Hi Sunny, thanks for looking into this.
>>
>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>> Hi Pete.
>>>
>>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>>
>> I'm not sure I understand how this part is unwanted.
>>
>> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>>
>> Or is the "one more" the issue, meaning that it would get signalled more than once?
>>
>>
>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>>
>> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
>> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>>
>> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>>
>>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>>
>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>>
>> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
>>
>> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>>
>> [Bds]=============Begin Load Options Dumping ...=============
>>      Driver Options:
>>      SysPrep Options:
>>      Boot Options:
>>        Boot0000: UiApp              0x0109
>>        Boot0001: UEFI Shell                 0x0000
>>      PlatformRecovery Options:
>>        PlatformRecovery0000: Default PlatformRecovery               0x0001
>> [Bds]=============End Load Options Dumping=============
>>
>> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
>>
>> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>>
>>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>>
>> That's something I considered too, but I disagree with this conclusion.
>>
>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
>>
>> If there was a special bootloader for PlatformRecovery#### (e.g.
>> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
>>
>>> Therefore, your change may also require specification change.
>>
>> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
>>
>> ------------------------------------------------------------------------
>> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>>
>>    >  EFI_EVENT_GROUP_READY_TO_BOOT
>>    >    This event group is notified by the system when the Boot Manager
>>    >    is about to load and execute a boot option.
>>
>> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
>> ------------------------------------------------------------------------
>>
>>
>> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
>>
>> Regards,
>>
>> /Pete
>>
>>>
>>> Regards,
>>> Sunny Wang
>>>
>>> -----Original Message-----
>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> Pete Batard
>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>> To: mailto:devel@edk2.groups.io
>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com;
>>> mailto:leif@nuviainc.com
>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>> recovery
>>>
>>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>>
>>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>>
>>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>>
>>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>>
>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>>> ---
>>>     MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>>     1 file changed, 9 insertions(+)
>>>
>>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> index 89372b3b97b8..117f1f5b124c 100644
>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>         return EFI_SUCCESS;
>>>       }
>>>
>>> +  //
>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>>> +  //
>>> +  EfiSignalEventReadyToBoot ();
>>> +  //
>>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>> +
>>>       //
>>>       // Load and start the load option.
>>>       //
>>> --
>>> 2.21.0.windows.1
>>>
>>>
>>>
>>>
>>
> 
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> 

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Leif Lindholm]

Hi Pete, +various

Resurrecting this old thread since Ard pointed out an issue I ran into
myself had already been encountered by Pete.
And the bugzilla ticket (directly below this reply) has had no
relevant progress since August.

Executive summary:
The current UefiBootManagerLib implementation of the PlatformRecovery
path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.

The argument has been made that since changing this would affect an
unnamed number of non-public platforms, the behaviour cannot be
changed even though it violates the UEFI specification.

I disagree with that statement. If we want to fork UefiBootManagerLib
into a BrokenLegacyUefiBootManagerLib and an actually correct one, and
have those platforms move to the BrokenLegacy variant, I'm OK with
that.

But using the default version should give specification-compliant
behaviour.

/
    Leif

On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
> Please note that I have created a bug report
> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
> non-compliance issue was raised during the course of the discussion below.
> 
> Regards,
> 
> /Pete
> 
> 
> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
> > I worked with Pete offline on this..
> > 
> > This code seems to be violating the UEFI Spec:
> > 
> > https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
> > 
> >    //
> >    // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute
> >    //    the boot option.
> >    //
> >    if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
> >      DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
> >      BmStopHotkeyService (NULL, NULL);
> >    } else {
> >      EfiSignalEventReadyToBoot();
> >      //
> >      // Report Status Code to indicate ReadyToBoot was signalled
> >      //
> >      REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >      //
> >      // 4. Repair system through DriverHealth protocol
> >      //
> >      BmRepairAllControllers (0);
> >    }
> > 
> > The UEFI Spec section 3.1.7 clearly states that Boot Options (and their FilePathList) *shall not* be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
> > 
> > "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
> > 
> > This is a prescriptive language that is stronger than the language in section 7.1 which defines the ReadyToBoot event group in a general way:
> > 
> > "EFI_EVENT_GROUP_RESET_SYSTEM
> > This event group is notified by the system when ResetSystem() is invoked and the system is about to be reset. The event group is only notified prior to ExitBootServices() invocation."
> > 
> > The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) need to move before the code that is processing BootOption->FilePath. In fact, why is this signaling even a BootManager task? It should be a higher level BDS task (after processing SysPrp and before processing Boot options, per the spec). This would be somewhere around https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007 where SysPrep is processed.
> > 
> > This should also take care of the issue Pete reported in this thread, without the need for explicitly signaling ReadyToBoot from PlatformRecovery (or changing the UEFI spec).
> > 
> > Thanks,
> > --Samer
> > 
> > 
> > 
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
> > Sent: Wednesday, June 17, 2020 12:42 PM
> > To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; pete@akeo.ie
> > Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
> > Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> > 
> > The UEFI spec (3.1.7) says:
> > 
> > "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
> > 
> > The way I read this, I expect ReadyToBoot to be signaled after SysPrep#### (if any) are processed, but before Boot#### are processed. Is my understanding correct that this language implies ReadyToBoot need to be signaled even if BootOrder does not contain any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to this patch (signaling it in PlatformRecovery?)
> > 
> > 
> > 
> > From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On Behalf Of Andrei Warkentin via groups.io
> > Sent: Wednesday, June 17, 2020 12:37 PM
> > To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
> > Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; mailto:leif@nuviainc.com
> > Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> > 
> > Thanks Pete.
> > 
> > I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?
> > 
> > 
> > A
> > 
> > 
> > ________________________________________
> > From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
> > Sent: Wednesday, June 17, 2020 11:34 AM
> > To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>; mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>; mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>; mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
> > Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> > 
> > On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> > > Thanks for checking my comments, Pete.
> > > 
> > > > Or is the "one more" the issue, meaning that it would get signaled more than once?
> > > [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.
> > 
> > Okay.
> > 
> > One element that I'm going to point out is that, with the current EDK2
> > code (i.e. without this proposal applied), and after a user goes into
> > the setup to save their boot options in order for regular boot options
> > to get executed instead of PlaformRecovery, the OnReadyToBoot event is
> > actually called twice.
> > 
> > So my understanding is that, while we of course want to avoid this and
> > any patch proposal should actively try to prevent it, it seems we
> > already have behaviour in EDK2 that can lead to OnReadyToBoot being
> > signalled more than once.
> > 
> > At least the current Pi 4 platform does demonstrate this behaviour. For
> > instance, if you run DEBUG, you will see two instances of:
> > 
> >     RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> > 
> > which is a one-instance message generated from the ConsolePrefDxe's
> > OnReadyToBoot() call. I've also confirmed more specifically that
> > OnReadyToBoot() is indeed called twice.
> > 
> > I don't recall us doing much of any special with regards to boot options
> > for the Pi platform, so my guess is that it's probably not the only
> > platform where OnReadyToBoot might be signalled more than once, and that
> > this might be tied to a default EDK2 behaviour. Therefore I don't see
> > having a repeated event as a major deal breaker (though, again, if we
> > can avoid that, we of course will want to).
> > 
> > > > I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> > > [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
> > >        1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.
> > 
> > So that would basically be adding code that duplicates, in part, what
> > Platform Recovery already does.
> > 
> > I have to be honest: Even outside of the extra work this would require,
> > I don't really like the idea of having to write our own application, as
> > it will introduce new possible points of failures and require extra
> > maintenance (especially as we will want to be able to handle network
> > boot and other options, and before long, I fear that we're going to have
> > to write our own Pi specific boot manager). Doing so simply because the
> > current Platform Recovery, which does suit our needs otherwise, is not
> > designed to call ReadyToBoot does not seem like the best course of
> > action in my book.
> > 
> > Instead, I still logically believe that any option that calls a boot
> > loader should signal ReadyToBoot, regardless of whether it was launched
> > from Boot Manager or Platform Recovery, and that it shouldn't be left to
> > each platform to work around that.
> > 
> > Of course, I understand that this would require a specs change, and that
> > it also may have ramifications for existing platforms that interpret the
> > current specs pedantically. But to me, regardless of what the specs
> > appear to be limiting it to right now, the logic of a "ReadyToBoot"
> > event is that it should be signalled whenever a bootloader is about to
> > be executed, rather than only when a bootloader happened to be launched
> > through a formal Boot Manager option.
> > 
> > I would therefore appreciate if other people could weigh in on this
> > matter, to see if I'm the only one who believes that we could ultimately
> > have more to gain from signalling ReadyToBoot with PlatformRecovery
> > options than leaving things as they stand right now...
> > 
> > >        2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
> > >     Status = EfiBootManagerInitializeLoadOption (
> > >                &LoadOption,
> > >                0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
> > >                LoadOptionTypePlatformRecovery,
> > >                LOAD_OPTION_ACTIVE,
> > >                L"Application for recovering boot options",
> > >                FilePath,                                                                -> FilePath is the Application's device path,
> > >                NULL,
> > >                0
> > >                );
> > > 
> > > 
> > > > My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
> > > [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,
> > 
> > The way I see it is that the Pi platform is unlikely to be the only one
> > where PlatformRecovery is seen as a means to install an OS. Granted,
> > this may seem like abusing the option, but since UEFI doesn't provide an
> > "Initial OS Install" mode, I would assert that it as good a use of this
> > option as any.
> > 
> > In other words, I don't think this improvement would only benefit the Pi
> > platform.
> > 
> > > and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.
> > 
> > That's a legitimate concern, and I would agree the one major potential
> > pitfall of this proposal, if there happens to exist a system where an
> > OnReadyToBoot even before running the recovery option can have adverse
> > effects.
> > 
> > I don't really believe that such a system exists, because I expect most
> > recovery boot loaders to also work (or at least have been designed to
> > work) as regular boot options. But I don't have enough experience with
> > platform recovery to know if that's a correct assertion to make...
> > 
> > > If the alternative approach I mentioned works for you, I think that would be an easier solution.
> > 
> > Right now, even as the patch proposal has multiple issues that require
> > it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
> > + Prevent situations where ReadyToBoot could be signalled multiple
> > times) I still see it as both an easier solution than the alternative,
> > as well as one that *should* benefit people who design Platform Recovery
> > UEFI applications in the long run. So that is why I am still trying to
> > advocate for it.
> > 
> > But I very much hear your concerns, and I agree that specs changes are
> > better avoided when possible.
> > 
> > Thus, at this stage, even as I don't want to drag this discussion much
> > further, I don't feel like I want to commit to one solution or the other
> > before we have had a chance to hear other people, who may have their own
> > opinion on the matter, express their views.
> > 
> > Regards,
> > 
> > /Pete
> > 
> > 
> > > 
> > > Regards,
> > > Sunny Wang
> > > 
> > > -----Original Message-----
> > > From: Pete Batard [mailto:pete@akeo.ie]
> > > Sent: Wednesday, June 17, 2020 6:59 PM
> > > To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io
> > > Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> > > Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> > > 
> > > Hi Sunny, thanks for looking into this.
> > > 
> > > On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> > > > Hi Pete.
> > > > 
> > > > Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
> > > > 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
> > > 
> > > I'm not sure I understand how this part is unwanted.
> > > 
> > > The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
> > > 
> > > Or is the "one more" the issue, meaning that it would get signalled more than once?
> > > 
> > > 
> > > > 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
> > > 
> > > Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
> > > mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
> > > 
> > > If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
> > > 
> > > > To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
> > > 
> > > I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
> > > 
> > > Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
> > > 
> > > If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
> > > 
> > > [Bds]=============Begin Load Options Dumping ...=============
> > >      Driver Options:
> > >      SysPrep Options:
> > >      Boot Options:
> > >        Boot0000: UiApp              0x0109
> > >        Boot0001: UEFI Shell                 0x0000
> > >      PlatformRecovery Options:
> > >        PlatformRecovery0000: Default PlatformRecovery               0x0001
> > > [Bds]=============End Load Options Dumping=============
> > > 
> > > With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
> > > 
> > > So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
> > > 
> > > > By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
> > > 
> > > That's something I considered too, but I disagree with this conclusion.
> > > 
> > > My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
> > > 
> > > If there was a special bootloader for PlatformRecovery#### (e.g.
> > > /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
> > > 
> > > > Therefore, your change may also require specification change.
> > > 
> > > Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
> > > 
> > > ------------------------------------------------------------------------
> > > Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
> > > 
> > >    >  EFI_EVENT_GROUP_READY_TO_BOOT
> > >    >    This event group is notified by the system when the Boot Manager
> > >    >    is about to load and execute a boot option.
> > > 
> > > and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
> > > ------------------------------------------------------------------------
> > > 
> > > 
> > > Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
> > > 
> > > Regards,
> > > 
> > > /Pete
> > > 
> > > > 
> > > > Regards,
> > > > Sunny Wang
> > > > 
> > > > -----Original Message-----
> > > > From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > > > Pete Batard
> > > > Sent: Tuesday, June 16, 2020 5:56 PM
> > > > To: mailto:devel@edk2.groups.io
> > > > Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com;
> > > > mailto:leif@nuviainc.com
> > > > Subject: [edk2-devel] [edk2][PATCH 1/1]
> > > > MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> > > > recovery
> > > > 
> > > > Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
> > > > 
> > > > However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
> > > > 
> > > > Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
> > > > 
> > > > This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
> > > > 
> > > > Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
> > > > ---
> > > >     MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
> > > >     1 file changed, 9 insertions(+)
> > > > 
> > > > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > > > b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > > > index 89372b3b97b8..117f1f5b124c 100644
> > > > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > > > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > > > @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
> > > >         return EFI_SUCCESS;
> > > >       }
> > > > 
> > > > +  //
> > > > +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
> > > > +  //
> > > > +  EfiSignalEventReadyToBoot ();
> > > > +  //
> > > > +  // Report Status Code to indicate ReadyToBoot was signalled  //
> > > > + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
> > > > + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > > > +
> > > >       //
> > > >       // Load and start the load option.
> > > >       //
> > > > --
> > > > 2.21.0.windows.1
> > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> > 
> > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> > 
> 
> 
> 
> 

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Hi Leif,

Thanks for trying to resurrect this issue.

At this stage, and despite some initial pushback in the bugzilla ticket, 
I believe we can all agree with the consensus that UefiBootManagerLib is 
not in fact specs-compliant and therefore needs to be fixed, one way or 
another, to make it specs-compliant.

My take on this is that, rather than propose a new patch, I'd much 
rather have the current maintainers agree on the course of action to fix 
the library (which, as Leif suggests, might very well be to split the 
library into a specs-compliant and non-specs-compliant version), as it 
would of course be better if the fix came from people who have better 
understanding of the ramifications we might face with trying to correct 
the current behaviour, and especially, who have knowledge of the 
platforms that might be impacted from making the lib specs-compliant.

Especially, I don't think that the patch that I originally submitted for 
this, or the additional proposals we made, are still receivable, as they 
seem to fall short of fixing the issue in a manner that all platforms 
can be happy with. And that is why I'd like to hear from the maintainers 
on what their preferred approach would be.

Regards,

/Pete

On 2021.02.17 11:42, Leif Lindholm wrote:
> Hi Pete, +various
> 
> Resurrecting this old thread since Ard pointed out an issue I ran into
> myself had already been encountered by Pete.
> And the bugzilla ticket (directly below this reply) has had no
> relevant progress since August.
> 
> Executive summary:
> The current UefiBootManagerLib implementation of the PlatformRecovery
> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
> 
> The argument has been made that since changing this would affect an
> unnamed number of non-public platforms, the behaviour cannot be
> changed even though it violates the UEFI specification.
> 
> I disagree with that statement. If we want to fork UefiBootManagerLib
> into a BrokenLegacyUefiBootManagerLib and an actually correct one, and
> have those platforms move to the BrokenLegacy variant, I'm OK with
> that.
> 
> But using the default version should give specification-compliant
> behaviour.
> 
> /
>      Leif
> 
> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
>> Please note that I have created a bug report
>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
>> non-compliance issue was raised during the course of the discussion below.
>>
>> Regards,
>>
>> /Pete
>>
>>
>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
>>> I worked with Pete offline on this..
>>>
>>> This code seems to be violating the UEFI Spec:
>>>
>>> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
>>>
>>>     //
>>>     // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute
>>>     //    the boot option.
>>>     //
>>>     if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
>>>       DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
>>>       BmStopHotkeyService (NULL, NULL);
>>>     } else {
>>>       EfiSignalEventReadyToBoot();
>>>       //
>>>       // Report Status Code to indicate ReadyToBoot was signalled
>>>       //
>>>       REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>       //
>>>       // 4. Repair system through DriverHealth protocol
>>>       //
>>>       BmRepairAllControllers (0);
>>>     }
>>>
>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and their FilePathList) *shall not* be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
>>>
>>> "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>
>>> This is a prescriptive language that is stronger than the language in section 7.1 which defines the ReadyToBoot event group in a general way:
>>>
>>> "EFI_EVENT_GROUP_RESET_SYSTEM
>>> This event group is notified by the system when ResetSystem() is invoked and the system is about to be reset. The event group is only notified prior to ExitBootServices() invocation."
>>>
>>> The EDK2 code in the else block above (to call EfiSignalEventReadyToBoot() ) need to move before the code that is processing BootOption->FilePath. In fact, why is this signaling even a BootManager task? It should be a higher level BDS task (after processing SysPrp and before processing Boot options, per the spec). This would be somewhere around https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007 where SysPrep is processed.
>>>
>>> This should also take care of the issue Pete reported in this thread, without the need for explicitly signaling ReadyToBoot from PlatformRecovery (or changing the UEFI spec).
>>>
>>> Thanks,
>>> --Samer
>>>
>>>
>>>
>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer El-Haj-Mahmoud via groups.io
>>> Sent: Wednesday, June 17, 2020 12:42 PM
>>> To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; pete@akeo.ie
>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>>>
>>> The UEFI spec (3.1.7) says:
>>>
>>> "After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>
>>> The way I read this, I expect ReadyToBoot to be signaled after SysPrep#### (if any) are processed, but before Boot#### are processed. Is my understanding correct that this language implies ReadyToBoot need to be signaled even if BootOrder does not contain any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so, is EDK2 not doing this, which leads us to this patch (signaling it in PlatformRecovery?)
>>>
>>>
>>>
>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On Behalf Of Andrei Warkentin via groups.io
>>> Sent: Wednesday, June 17, 2020 12:37 PM
>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; mailto:leif@nuviainc.com
>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>>>
>>> Thanks Pete.
>>>
>>> I think the question I have, that I hope Tiano veterans can chime in, is whether we are doing the right thing, or if we should be overriding the boot mode? I.e. is it normal that we boot up in recovery until options are saved?
>>>
>>>
>>> A
>>>
>>>
>>> ________________________________________
>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
>>> Sent: Wednesday, June 17, 2020 11:34 AM
>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>; mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>; mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>; mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>>>
>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>>>> Thanks for checking my comments, Pete.
>>>>
>>>>> Or is the "one more" the issue, meaning that it would get signaled more than once?
>>>> [Sunny] Yeah, it would get signaled more than once if the PlatformRecovery option (a UEFI application) calls EfiBootManagerBoot() to launch the recovered boot option inside of the application.
>>>
>>> Okay.
>>>
>>> One element that I'm going to point out is that, with the current EDK2
>>> code (i.e. without this proposal applied), and after a user goes into
>>> the setup to save their boot options in order for regular boot options
>>> to get executed instead of PlaformRecovery, the OnReadyToBoot event is
>>> actually called twice.
>>>
>>> So my understanding is that, while we of course want to avoid this and
>>> any patch proposal should actively try to prevent it, it seems we
>>> already have behaviour in EDK2 that can lead to OnReadyToBoot being
>>> signalled more than once.
>>>
>>> At least the current Pi 4 platform does demonstrate this behaviour. For
>>> instance, if you run DEBUG, you will see two instances of:
>>>
>>>      RemoveDtStdoutPath: could not retrieve DT blob - Not Found
>>>
>>> which is a one-instance message generated from the ConsolePrefDxe's
>>> OnReadyToBoot() call. I've also confirmed more specifically that
>>> OnReadyToBoot() is indeed called twice.
>>>
>>> I don't recall us doing much of any special with regards to boot options
>>> for the Pi platform, so my guess is that it's probably not the only
>>> platform where OnReadyToBoot might be signalled more than once, and that
>>> this might be tied to a default EDK2 behaviour. Therefore I don't see
>>> having a repeated event as a major deal breaker (though, again, if we
>>> can avoid that, we of course will want to).
>>>
>>>>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>>>> [Sunny] Sure. I added more information below. If it is still not clear enough, feel free to let me know.
>>>>         1. Create a UEFI application with the code to signal ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB and run it.
>>>
>>> So that would basically be adding code that duplicates, in part, what
>>> Platform Recovery already does.
>>>
>>> I have to be honest: Even outside of the extra work this would require,
>>> I don't really like the idea of having to write our own application, as
>>> it will introduce new possible points of failures and require extra
>>> maintenance (especially as we will want to be able to handle network
>>> boot and other options, and before long, I fear that we're going to have
>>> to write our own Pi specific boot manager). Doing so simply because the
>>> current Platform Recovery, which does suit our needs otherwise, is not
>>> designed to call ReadyToBoot does not seem like the best course of
>>> action in my book.
>>>
>>> Instead, I still logically believe that any option that calls a boot
>>> loader should signal ReadyToBoot, regardless of whether it was launched
>>> from Boot Manager or Platform Recovery, and that it shouldn't be left to
>>> each platform to work around that.
>>>
>>> Of course, I understand that this would require a specs change, and that
>>> it also may have ramifications for existing platforms that interpret the
>>> current specs pedantically. But to me, regardless of what the specs
>>> appear to be limiting it to right now, the logic of a "ReadyToBoot"
>>> event is that it should be signalled whenever a bootloader is about to
>>> be executed, rather than only when a bootloader happened to be launched
>>> through a formal Boot Manager option.
>>>
>>> I would therefore appreciate if other people could weigh in on this
>>> matter, to see if I'm the only one who believes that we could ultimately
>>> have more to gain from signalling ReadyToBoot with PlatformRecovery
>>> options than leaving things as they stand right now...
>>>
>>>>         2. Then, call EfiBootManagerInitializeLoadOption like the following in a DXE driver or other places before "Default PlatformRecovery" registration:
>>>>      Status = EfiBootManagerInitializeLoadOption (
>>>>                 &LoadOption,
>>>>                 0,                                                                             -> 0 is the OptionNumber to let application be load before " Default PlatformRecovery" option
>>>>                 LoadOptionTypePlatformRecovery,
>>>>                 LOAD_OPTION_ACTIVE,
>>>>                 L"Application for recovering boot options",
>>>>                 FilePath,                                                                -> FilePath is the Application's device path,
>>>>                 NULL,
>>>>                 0
>>>>                 );
>>>>
>>>>
>>>>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signaling the ReadyToBoot event.
>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed your cover letter for this patch.  I was just thinking that we may not really need to make this behavior change in both EDK II code and UEFI specification for solving the problem specific to the case that OS is loaded by "Default PlatformRecovery" option,
>>>
>>> The way I see it is that the Pi platform is unlikely to be the only one
>>> where PlatformRecovery is seen as a means to install an OS. Granted,
>>> this may seem like abusing the option, but since UEFI doesn't provide an
>>> "Initial OS Install" mode, I would assert that it as good a use of this
>>> option as any.
>>>
>>> In other words, I don't think this improvement would only benefit the Pi
>>> platform.
>>>
>>>> and I'm also not sure if it is worth making this change to affect some of the system or BIOS vendors who have implemented their PlatformRecovery option.
>>>
>>> That's a legitimate concern, and I would agree the one major potential
>>> pitfall of this proposal, if there happens to exist a system where an
>>> OnReadyToBoot even before running the recovery option can have adverse
>>> effects.
>>>
>>> I don't really believe that such a system exists, because I expect most
>>> recovery boot loaders to also work (or at least have been designed to
>>> work) as regular boot options. But I don't have enough experience with
>>> platform recovery to know if that's a correct assertion to make...
>>>
>>>> If the alternative approach I mentioned works for you, I think that would be an easier solution.
>>>
>>> Right now, even as the patch proposal has multiple issues that require
>>> it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
>>> + Prevent situations where ReadyToBoot could be signalled multiple
>>> times) I still see it as both an easier solution than the alternative,
>>> as well as one that *should* benefit people who design Platform Recovery
>>> UEFI applications in the long run. So that is why I am still trying to
>>> advocate for it.
>>>
>>> But I very much hear your concerns, and I agree that specs changes are
>>> better avoided when possible.
>>>
>>> Thus, at this stage, even as I don't want to drag this discussion much
>>> further, I don't feel like I want to commit to one solution or the other
>>> before we have had a chance to hear other people, who may have their own
>>> opinion on the matter, express their views.
>>>
>>> Regards,
>>>
>>> /Pete
>>>
>>>
>>>>
>>>> Regards,
>>>> Sunny Wang
>>>>
>>>> -----Original Message-----
>>>> From: Pete Batard [mailto:pete@akeo.ie]
>>>> Sent: Wednesday, June 17, 2020 6:59 PM
>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; mailto:devel@edk2.groups.io
>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
>>>>
>>>> Hi Sunny, thanks for looking into this.
>>>>
>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>>>> Hi Pete.
>>>>>
>>>>> Since the EfiBootManagerProcessLoadOption is called by ProcessLoadOptions as well, your change would also cause some unexpected behavior like:
>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option which is an application that calls EfiBootManagerBoot() to launch its recovered boot option.
>>>>
>>>> I'm not sure I understand how this part is unwanted.
>>>>
>>>> The point of this patch is to ensure that ReadyToBoot is signalled for the PlatformRecovery option, so isn't what you describe above exactly what we want?
>>>>
>>>> Or is the "one more" the issue, meaning that it would get signalled more than once?
>>>>
>>>>
>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not really a "boot" option.
>>>>
>>>> Yes, I've been wondering about that, because BdsEntry.c's ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
>>>> mentions that it will load will load and start every Driver####, SysPrep#### or PlatformRecovery####. But the comment about the while() loop in EfiBootManagerProcessLoadOption() only mentions PlatformRecovery####.
>>>>
>>>> If needed, I guess we could amend the patch to detect the type of option and only signal ReadyToBoot for PlatformRecovery####.
>>>>
>>>>> To solve your problem, creating a PlatformRecovery option with the smallest option number and using it instead of default one (with short-form File Path Media Device Path) looks like a simpler solution.
>>>>
>>>> I don't mind trying an alternative approach, but I don't understand how what you describe would help. Can you please be more specific about what you have in mind?
>>>>
>>>> Our main issue here is that we must have ReadyToBoot signalled so that the ReadyToBoot() function callback from EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the boot loader invoked from PlatformRecovery####  to use a properly initialized graphical console. So I'm not sure I quite get how switching from one PlatformRecovery#### option to another would improve things.
>>>>
>>>> If it helps, here is what we currently default to, in terms of boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>>>>
>>>> [Bds]=============Begin Load Options Dumping ...=============
>>>>       Driver Options:
>>>>       SysPrep Options:
>>>>       Boot Options:
>>>>         Boot0000: UiApp              0x0109
>>>>         Boot0001: UEFI Shell                 0x0000
>>>>       PlatformRecovery Options:
>>>>         PlatformRecovery0000: Default PlatformRecovery               0x0001
>>>> [Bds]=============End Load Options Dumping=============
>>>>
>>>> With this, PlatformRecovery0000 gets executed by default, which is what we want, since it will pick /efi/boot/bootaa64.efi from either SD or USB and run it, the only issue being that, because ReadyToBoot has not been executed, the graphical console is not operative so users can't interact with the OS installer.
>>>>
>>>> So I'm really not sure how adding an extra PlatformRecovery#### would help. And I'm also not too familiar with how one would go around to add such an entry...
>>>>
>>>>> By the way, I also checked the UEFI specification. It looks making sense to only signal ReadyToBoot for boot option (Boot####).
>>>>
>>>> That's something I considered too, but I disagree with this conclusion.
>>>>
>>>> My reasoning is that, if PlatformRecovery#### can execute a regular bootloader like /efi/boot/boot####.efi from installation media, then it should go through the same kind of initialization that happens for a regular boot option, and that should include signalling the ReadyToBoot event.
>>>>
>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
>>>> /efi/boot/recovery####.efi) then I would agree with only signalling ReadyToBoot for a formal Boot#### option. But that isn't the case, so I think it is reasonable to want to have ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is executed from PlatformRecovery####., especially when we know it can be crucial to ensuring that the end user can actually use the graphical console.
>>>>
>>>>> Therefore, your change may also require specification change.
>>>>
>>>> Yes, I mentioned that in the cover letter for this patch (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0 ), which also describes the issue we are trying to solve in greater details. This is what I wrote:
>>>>
>>>> ------------------------------------------------------------------------
>>>> Note however that this may require a specs update, as the current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>>>>
>>>>     >  EFI_EVENT_GROUP_READY_TO_BOOT
>>>>     >    This event group is notified by the system when the Boot Manager
>>>>     >    is about to load and execute a boot option.
>>>>
>>>> and, once this patch has been applied, we may want to update this section to mention that it applies to both Boot Manager and Platform Recovery.
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> Again, I don't have an issue with trying to use an alternate approach to solve our problem (though I ultimately believe that, if PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader then we must update the specs and the code to have ReadyToBoot also signalled then, because that's the logical thing to do). But right now, I'm not seeing how to achieve that when PlatformRecovery#### is the option that is used to launch the OS installation the bootloader. So if you can provide mode details on how exactly you think creating an alternate PlatformRecovery option would help, I would appreciate it.
>>>>
>>>> Regards,
>>>>
>>>> /Pete
>>>>
>>>>>
>>>>> Regards,
>>>>> Sunny Wang
>>>>>
>>>>> -----Original Message-----
>>>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>>>> Pete Batard
>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>>>> To: mailto:devel@edk2.groups.io
>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; mailto:ard.biesheuvel@arm.com;
>>>>> mailto:leif@nuviainc.com
>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>> recovery
>>>>>
>>>>> Currently, the ReadyToBoot event is only signaled when a formal Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot ()).
>>>>>
>>>>> However, with the introduction of Platform Recovery in UEFI 2.5, which may lead to the execution of a boot loader that has similar requirements to a regular one, yet is not launched as a Boot Manager option, it also becomes necessary to signal ReadyToBoot when a Platform Recovery boot loader runs.
>>>>>
>>>>> Especially, this can be critical to ensuring that the graphical console is actually usable during platform recovery, as some platforms do rely on the ConsolePrefDxe driver, which only performs console initialization after ReadyToBoot is triggered.
>>>>>
>>>>> This patch fixes that behaviour by calling EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption (), which is the function that sets up the platform recovery boot process.
>>>>>
>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>>>>> ---
>>>>>      MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9 +++++++++
>>>>>      1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>> index 89372b3b97b8..117f1f5b124c 100644
>>>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>>>          return EFI_SUCCESS;
>>>>>        }
>>>>>
>>>>> +  //
>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
>>>>> +  //
>>>>> +  EfiSignalEventReadyToBoot ();
>>>>> +  //
>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>>>>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER |
>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>> +
>>>>>        //
>>>>>        // Load and start the load option.
>>>>>        //
>>>>> --
>>>>> 2.21.0.windows.1
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>
>>> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>>
>>
>>
>> 
>>

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Laszlo Ersek]

On 02/17/21 13:18, Pete Batard wrote:
> Hi Leif,
> 
> Thanks for trying to resurrect this issue.
> 
> At this stage, and despite some initial pushback in the bugzilla ticket,
> I believe we can all agree with the consensus that UefiBootManagerLib is
> not in fact specs-compliant and therefore needs to be fixed, one way or
> another, to make it specs-compliant.
> 
> My take on this is that, rather than propose a new patch, I'd much
> rather have the current maintainers agree on the course of action to fix
> the library (which, as Leif suggests, might very well be to split the
> library into a specs-compliant and non-specs-compliant version), as it
> would of course be better if the fix came from people who have better
> understanding of the ramifications we might face with trying to correct
> the current behaviour, and especially, who have knowledge of the
> platforms that might be impacted from making the lib specs-compliant.
> 
> Especially, I don't think that the patch that I originally submitted for
> this, or the additional proposals we made, are still receivable, as they
> seem to fall short of fixing the issue in a manner that all platforms
> can be happy with. And that is why I'd like to hear from the maintainers
> on what their preferred approach would be.

A new Feature PCD could satisfy both sets of platforms, could it not?

(Sorry if the original patch already had such a PCD; I don't remember.)

Of course then we'd have a debate around the DEC default for the new PCD
-- I'd say the default value of the PCD should match the spec-mandated
behavior.

I don't recall any specifics, but a bug-compat pattern that's sometimes
used is this:

  if (BugCompatEnabled) {
    //
    // do the right thing in the wrong place, for legacy platforms' sake
    //
   Foo ();
  }

  //
  // Do some stuff.
  //
  Bar ();

  if (!BugCompatEnabled) {
    //
    // do the right thing in the right place, for conformant platforms
    //
   Foo ();
  }

Not sure if it applies here.

Thanks
Laszlo


> On 2021.02.17 11:42, Leif Lindholm wrote:
>> Hi Pete, +various
>>
>> Resurrecting this old thread since Ard pointed out an issue I ran into
>> myself had already been encountered by Pete.
>> And the bugzilla ticket (directly below this reply) has had no
>> relevant progress since August.
>>
>> Executive summary:
>> The current UefiBootManagerLib implementation of the PlatformRecovery
>> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
>>
>> The argument has been made that since changing this would affect an
>> unnamed number of non-public platforms, the behaviour cannot be
>> changed even though it violates the UEFI specification.
>>
>> I disagree with that statement. If we want to fork UefiBootManagerLib
>> into a BrokenLegacyUefiBootManagerLib and an actually correct one, and
>> have those platforms move to the BrokenLegacy variant, I'm OK with
>> that.
>>
>> But using the default version should give specification-compliant
>> behaviour.
>>
>> /
>>      Leif
>>
>> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
>>> Please note that I have created a bug report
>>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
>>> non-compliance issue was raised during the course of the discussion
>>> below.
>>>
>>> Regards,
>>>
>>> /Pete
>>>
>>>
>>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
>>>> I worked with Pete offline on this..
>>>>
>>>> This code seems to be violating the UEFI Spec:
>>>>
>>>> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
>>>>
>>>>
>>>>     //
>>>>     // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
>>>> about to load and execute
>>>>     //    the boot option.
>>>>     //
>>>>     if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
>>>>       DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
>>>>       BmStopHotkeyService (NULL, NULL);
>>>>     } else {
>>>>       EfiSignalEventReadyToBoot();
>>>>       //
>>>>       // Report Status Code to indicate ReadyToBoot was signalled
>>>>       //
>>>>       REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
>>>> (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>       //
>>>>       // 4. Repair system through DriverHealth protocol
>>>>       //
>>>>       BmRepairAllControllers (0);
>>>>     }
>>>>
>>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and
>>>> their FilePathList) *shall not* be evaluated prior to the completion
>>>> of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
>>>>
>>>> "After all SysPrep#### variables have been launched and exited, the
>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and
>>>> begin to evaluate Boot#### variables with Attributes set to
>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
>>>> BootOrder. The FilePathList of variables marked
>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>
>>>> This is a prescriptive language that is stronger than the language
>>>> in section 7.1 which defines the ReadyToBoot event group in a
>>>> general way:
>>>>
>>>> "EFI_EVENT_GROUP_RESET_SYSTEM
>>>> This event group is notified by the system when ResetSystem() is
>>>> invoked and the system is about to be reset. The event group is only
>>>> notified prior to ExitBootServices() invocation."
>>>>
>>>> The EDK2 code in the else block above (to call
>>>> EfiSignalEventReadyToBoot() ) need to move before the code that is
>>>> processing BootOption->FilePath. In fact, why is this signaling even
>>>> a BootManager task? It should be a higher level BDS task (after
>>>> processing SysPrp and before processing Boot options, per the spec).
>>>> This would be somewhere around
>>>> https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea0214498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
>>>> where SysPrep is processed.
>>>>
>>>> This should also take care of the issue Pete reported in this
>>>> thread, without the need for explicitly signaling ReadyToBoot from
>>>> PlatformRecovery (or changing the UEFI spec).
>>>>
>>>> Thanks,
>>>> --Samer
>>>>
>>>>
>>>>
>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer
>>>> El-Haj-Mahmoud via groups.io
>>>> Sent: Wednesday, June 17, 2020 12:42 PM
>>>> To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com)
>>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>;
>>>> pete@akeo.ie
>>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
>>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud
>>>> <Samer.El-Haj-Mahmoud@arm.com>
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>> recovery
>>>>
>>>> The UEFI spec (3.1.7) says:
>>>>
>>>> "After all SysPrep#### variables have been launched and exited, the
>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and
>>>> begin to evaluate Boot#### variables with Attributes set to
>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
>>>> BootOrder. The FilePathList of variables marked
>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>
>>>> The way I read this, I expect ReadyToBoot to be signaled after
>>>> SysPrep#### (if any) are processed, but before Boot#### are
>>>> processed. Is my understanding correct that this language implies
>>>> ReadyToBoot need to be signaled even if BootOrder does not contain
>>>> any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if so,
>>>> is EDK2 not doing this, which leads us to this patch (signaling it
>>>> in PlatformRecovery?)
>>>>
>>>>
>>>>
>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On
>>>> Behalf Of Andrei Warkentin via groups.io
>>>> Sent: Wednesday, June 17, 2020 12:37 PM
>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
>>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; mailto:leif@nuviainc.com
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>> recovery
>>>>
>>>> Thanks Pete.
>>>>
>>>> I think the question I have, that I hope Tiano veterans can chime
>>>> in, is whether we are doing the right thing, or if we should be
>>>> overriding the boot mode? I.e. is it normal that we boot up in
>>>> recovery until options are saved?
>>>>
>>>>
>>>> A
>>>>
>>>>
>>>> ________________________________________
>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on
>>>> behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
>>>> Sent: Wednesday, June 17, 2020 11:34 AM
>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
>>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
>>>> mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>;
>>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>> recovery
>>>>
>>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>>>>> Thanks for checking my comments, Pete.
>>>>>
>>>>>> Or is the "one more" the issue, meaning that it would get signaled
>>>>>> more than once?
>>>>> [Sunny] Yeah, it would get signaled more than once if the
>>>>> PlatformRecovery option (a UEFI application) calls
>>>>> EfiBootManagerBoot() to launch the recovered boot option inside of
>>>>> the application.
>>>>
>>>> Okay.
>>>>
>>>> One element that I'm going to point out is that, with the current EDK2
>>>> code (i.e. without this proposal applied), and after a user goes into
>>>> the setup to save their boot options in order for regular boot options
>>>> to get executed instead of PlaformRecovery, the OnReadyToBoot event is
>>>> actually called twice.
>>>>
>>>> So my understanding is that, while we of course want to avoid this and
>>>> any patch proposal should actively try to prevent it, it seems we
>>>> already have behaviour in EDK2 that can lead to OnReadyToBoot being
>>>> signalled more than once.
>>>>
>>>> At least the current Pi 4 platform does demonstrate this behaviour. For
>>>> instance, if you run DEBUG, you will see two instances of:
>>>>
>>>>      RemoveDtStdoutPath: could not retrieve DT blob - Not Found
>>>>
>>>> which is a one-instance message generated from the ConsolePrefDxe's
>>>> OnReadyToBoot() call. I've also confirmed more specifically that
>>>> OnReadyToBoot() is indeed called twice.
>>>>
>>>> I don't recall us doing much of any special with regards to boot
>>>> options
>>>> for the Pi platform, so my guess is that it's probably not the only
>>>> platform where OnReadyToBoot might be signalled more than once, and
>>>> that
>>>> this might be tied to a default EDK2 behaviour. Therefore I don't see
>>>> having a repeated event as a major deal breaker (though, again, if we
>>>> can avoid that, we of course will want to).
>>>>
>>>>>> I don't mind trying an alternative approach, but I don't
>>>>>> understand how what you describe would help. Can you please be
>>>>>> more specific about what you have in mind?
>>>>> [Sunny] Sure. I added more information below. If it is still not
>>>>> clear enough, feel free to let me know.
>>>>>         1. Create a UEFI application with the code to signal
>>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB
>>>>> and run it.
>>>>
>>>> So that would basically be adding code that duplicates, in part, what
>>>> Platform Recovery already does.
>>>>
>>>> I have to be honest: Even outside of the extra work this would require,
>>>> I don't really like the idea of having to write our own application, as
>>>> it will introduce new possible points of failures and require extra
>>>> maintenance (especially as we will want to be able to handle network
>>>> boot and other options, and before long, I fear that we're going to
>>>> have
>>>> to write our own Pi specific boot manager). Doing so simply because the
>>>> current Platform Recovery, which does suit our needs otherwise, is not
>>>> designed to call ReadyToBoot does not seem like the best course of
>>>> action in my book.
>>>>
>>>> Instead, I still logically believe that any option that calls a boot
>>>> loader should signal ReadyToBoot, regardless of whether it was launched
>>>> from Boot Manager or Platform Recovery, and that it shouldn't be
>>>> left to
>>>> each platform to work around that.
>>>>
>>>> Of course, I understand that this would require a specs change, and
>>>> that
>>>> it also may have ramifications for existing platforms that interpret
>>>> the
>>>> current specs pedantically. But to me, regardless of what the specs
>>>> appear to be limiting it to right now, the logic of a "ReadyToBoot"
>>>> event is that it should be signalled whenever a bootloader is about to
>>>> be executed, rather than only when a bootloader happened to be launched
>>>> through a formal Boot Manager option.
>>>>
>>>> I would therefore appreciate if other people could weigh in on this
>>>> matter, to see if I'm the only one who believes that we could
>>>> ultimately
>>>> have more to gain from signalling ReadyToBoot with PlatformRecovery
>>>> options than leaving things as they stand right now...
>>>>
>>>>>         2. Then, call EfiBootManagerInitializeLoadOption like the
>>>>> following in a DXE driver or other places before "Default
>>>>> PlatformRecovery" registration:
>>>>>      Status = EfiBootManagerInitializeLoadOption (
>>>>>                 &LoadOption,
>>>>>                
>>>>> 0,                                                                            
>>>>> -> 0 is the OptionNumber to let application be load before "
>>>>> Default PlatformRecovery" option
>>>>>                 LoadOptionTypePlatformRecovery,
>>>>>                 LOAD_OPTION_ACTIVE,
>>>>>                 L"Application for recovering boot options",
>>>>>                
>>>>> FilePath,                                                               
>>>>> -> FilePath is the Application's device path,
>>>>>                 NULL,
>>>>>                 0
>>>>>                 );
>>>>>
>>>>>
>>>>>> My reasoning is that, if PlatformRecovery#### can execute a
>>>>>> regular bootloader like /efi/boot/boot####.efi from installation
>>>>>> media, then it should go through the same kind of initialization
>>>>>> that happens for a regular boot option, and that should include
>>>>>> signaling the ReadyToBoot event.
>>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed
>>>>> your cover letter for this patch.  I was just thinking that we may
>>>>> not really need to make this behavior change in both EDK II code
>>>>> and UEFI specification for solving the problem specific to the case
>>>>> that OS is loaded by "Default PlatformRecovery" option,
>>>>
>>>> The way I see it is that the Pi platform is unlikely to be the only one
>>>> where PlatformRecovery is seen as a means to install an OS. Granted,
>>>> this may seem like abusing the option, but since UEFI doesn't
>>>> provide an
>>>> "Initial OS Install" mode, I would assert that it as good a use of this
>>>> option as any.
>>>>
>>>> In other words, I don't think this improvement would only benefit
>>>> the Pi
>>>> platform.
>>>>
>>>>> and I'm also not sure if it is worth making this change to affect
>>>>> some of the system or BIOS vendors who have implemented their
>>>>> PlatformRecovery option.
>>>>
>>>> That's a legitimate concern, and I would agree the one major potential
>>>> pitfall of this proposal, if there happens to exist a system where an
>>>> OnReadyToBoot even before running the recovery option can have adverse
>>>> effects.
>>>>
>>>> I don't really believe that such a system exists, because I expect most
>>>> recovery boot loaders to also work (or at least have been designed to
>>>> work) as regular boot options. But I don't have enough experience with
>>>> platform recovery to know if that's a correct assertion to make...
>>>>
>>>>> If the alternative approach I mentioned works for you, I think that
>>>>> would be an easier solution.
>>>>
>>>> Right now, even as the patch proposal has multiple issues that require
>>>> it to be amended (Don't signal ReadyToBoot except for PlatformRecovery
>>>> + Prevent situations where ReadyToBoot could be signalled multiple
>>>> times) I still see it as both an easier solution than the alternative,
>>>> as well as one that *should* benefit people who design Platform
>>>> Recovery
>>>> UEFI applications in the long run. So that is why I am still trying to
>>>> advocate for it.
>>>>
>>>> But I very much hear your concerns, and I agree that specs changes are
>>>> better avoided when possible.
>>>>
>>>> Thus, at this stage, even as I don't want to drag this discussion much
>>>> further, I don't feel like I want to commit to one solution or the
>>>> other
>>>> before we have had a chance to hear other people, who may have their
>>>> own
>>>> opinion on the matter, express their views.
>>>>
>>>> Regards,
>>>>
>>>> /Pete
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Sunny Wang
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pete Batard [mailto:pete@akeo.ie]
>>>>> Sent: Wednesday, June 17, 2020 6:59 PM
>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>>> mailto:devel@edk2.groups.io
>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>> recovery
>>>>>
>>>>> Hi Sunny, thanks for looking into this.
>>>>>
>>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>>>>> Hi Pete.
>>>>>>
>>>>>> Since the EfiBootManagerProcessLoadOption is called by
>>>>>> ProcessLoadOptions as well, your change would also cause some
>>>>>> unexpected behavior like:
>>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option
>>>>>> which is an application that calls EfiBootManagerBoot() to launch
>>>>>> its recovered boot option.
>>>>>
>>>>> I'm not sure I understand how this part is unwanted.
>>>>>
>>>>> The point of this patch is to ensure that ReadyToBoot is signalled
>>>>> for the PlatformRecovery option, so isn't what you describe above
>>>>> exactly what we want?
>>>>>
>>>>> Or is the "one more" the issue, meaning that it would get signalled
>>>>> more than once?
>>>>>
>>>>>
>>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not
>>>>>> really a "boot" option.
>>>>>
>>>>> Yes, I've been wondering about that, because BdsEntry.c's
>>>>> ProcessLoadOptions(), which calls EfiBootManagerProcessLoadOption(),
>>>>> mentions that it will load will load and start every Driver####,
>>>>> SysPrep#### or PlatformRecovery####. But the comment about the
>>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions
>>>>> PlatformRecovery####.
>>>>>
>>>>> If needed, I guess we could amend the patch to detect the type of
>>>>> option and only signal ReadyToBoot for PlatformRecovery####.
>>>>>
>>>>>> To solve your problem, creating a PlatformRecovery option with the
>>>>>> smallest option number and using it instead of default one (with
>>>>>> short-form File Path Media Device Path) looks like a simpler
>>>>>> solution.
>>>>>
>>>>> I don't mind trying an alternative approach, but I don't understand
>>>>> how what you describe would help. Can you please be more specific
>>>>> about what you have in mind?
>>>>>
>>>>> Our main issue here is that we must have ReadyToBoot signalled so
>>>>> that the ReadyToBoot() function callback from
>>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the
>>>>> boot loader invoked from PlatformRecovery####  to use a properly
>>>>> initialized graphical console. So I'm not sure I quite get how
>>>>> switching from one PlatformRecovery#### option to another would
>>>>> improve things.
>>>>>
>>>>> If it helps, here is what we currently default to, in terms of boot
>>>>> options, on a Raspberry Pi 4 platform with a newly build firmware:
>>>>>
>>>>> [Bds]=============Begin Load Options Dumping ...=============
>>>>>       Driver Options:
>>>>>       SysPrep Options:
>>>>>       Boot Options:
>>>>>         Boot0000: UiApp              0x0109
>>>>>         Boot0001: UEFI Shell                 0x0000
>>>>>       PlatformRecovery Options:
>>>>>         PlatformRecovery0000: Default
>>>>> PlatformRecovery               0x0001
>>>>> [Bds]=============End Load Options Dumping=============
>>>>>
>>>>> With this, PlatformRecovery0000 gets executed by default, which is
>>>>> what we want, since it will pick /efi/boot/bootaa64.efi from either
>>>>> SD or USB and run it, the only issue being that, because
>>>>> ReadyToBoot has not been executed, the graphical console is not
>>>>> operative so users can't interact with the OS installer.
>>>>>
>>>>> So I'm really not sure how adding an extra PlatformRecovery####
>>>>> would help. And I'm also not too familiar with how one would go
>>>>> around to add such an entry...
>>>>>
>>>>>> By the way, I also checked the UEFI specification. It looks making
>>>>>> sense to only signal ReadyToBoot for boot option (Boot####).
>>>>>
>>>>> That's something I considered too, but I disagree with this
>>>>> conclusion.
>>>>>
>>>>> My reasoning is that, if PlatformRecovery#### can execute a regular
>>>>> bootloader like /efi/boot/boot####.efi from installation media,
>>>>> then it should go through the same kind of initialization that
>>>>> happens for a regular boot option, and that should include
>>>>> signalling the ReadyToBoot event.
>>>>>
>>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
>>>>> /efi/boot/recovery####.efi) then I would agree with only signalling
>>>>> ReadyToBoot for a formal Boot#### option. But that isn't the case,
>>>>> so I think it is reasonable to want to have ReadyToBoot also occur
>>>>> when a /efi/boot/boot####.efi bootloader is executed from
>>>>> PlatformRecovery####., especially when we know it can be crucial to
>>>>> ensuring that the end user can actually use the graphical console.
>>>>>
>>>>>> Therefore, your change may also require specification change.
>>>>>
>>>>> Yes, I mentioned that in the cover letter for this patch
>>>>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Cawarkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0
>>>>> ), which also describes the issue we are trying to solve in greater
>>>>> details. This is what I wrote:
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> Note however that this may require a specs update, as the current
>>>>> UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>>>>>
>>>>>     >  EFI_EVENT_GROUP_READY_TO_BOOT
>>>>>     >    This event group is notified by the system when the Boot
>>>>> Manager
>>>>>     >    is about to load and execute a boot option.
>>>>>
>>>>> and, once this patch has been applied, we may want to update this
>>>>> section to mention that it applies to both Boot Manager and
>>>>> Platform Recovery.
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> Again, I don't have an issue with trying to use an alternate
>>>>> approach to solve our problem (though I ultimately believe that, if
>>>>> PlatformRecovery#### can launch a /efi/boot/boot####.efi bootloader
>>>>> then we must update the specs and the code to have ReadyToBoot also
>>>>> signalled then, because that's the logical thing to do). But right
>>>>> now, I'm not seeing how to achieve that when PlatformRecovery####
>>>>> is the option that is used to launch the OS installation the
>>>>> bootloader. So if you can provide mode details on how exactly you
>>>>> think creating an alternate PlatformRecovery option would help, I
>>>>> would appreciate it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> /Pete
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Sunny Wang
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] On
>>>>>> Behalf Of
>>>>>> Pete Batard
>>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>>>>> To: mailto:devel@edk2.groups.io
>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
>>>>>> mailto:ard.biesheuvel@arm.com;
>>>>>> mailto:leif@nuviainc.com
>>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>>> recovery
>>>>>>
>>>>>> Currently, the ReadyToBoot event is only signaled when a formal
>>>>>> Boot Manager option is executed (in BmBoot.c -> EfiBootManagerBoot
>>>>>> ()).
>>>>>>
>>>>>> However, with the introduction of Platform Recovery in UEFI 2.5,
>>>>>> which may lead to the execution of a boot loader that has similar
>>>>>> requirements to a regular one, yet is not launched as a Boot
>>>>>> Manager option, it also becomes necessary to signal ReadyToBoot
>>>>>> when a Platform Recovery boot loader runs.
>>>>>>
>>>>>> Especially, this can be critical to ensuring that the graphical
>>>>>> console is actually usable during platform recovery, as some
>>>>>> platforms do rely on the ConsolePrefDxe driver, which only
>>>>>> performs console initialization after ReadyToBoot is triggered.
>>>>>>
>>>>>> This patch fixes that behaviour by calling
>>>>>> EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption
>>>>>> (), which is the function that sets up the platform recovery boot
>>>>>> process.
>>>>>>
>>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>>>>>> ---
>>>>>>      MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9
>>>>>> +++++++++
>>>>>>      1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> index 89372b3b97b8..117f1f5b124c 100644
>>>>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>>>>          return EFI_SUCCESS;
>>>>>>        }
>>>>>>
>>>>>> +  //
>>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
>>>>>> to load and execute the boot option.
>>>>>> +  //
>>>>>> +  EfiSignalEventReadyToBoot ();
>>>>>> +  //
>>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled  //
>>>>>> + REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
>>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
>>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>>> +
>>>>>>        //
>>>>>>        // Load and start the load option.
>>>>>>        //
>>>>>> -- 
>>>>>> 2.21.0.windows.1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>>> confidential and may also be privileged. If you are not the intended
>>>> recipient, please notify the sender immediately and do not disclose
>>>> the contents to any other person, use it for any purpose, or store
>>>> or copy the information in any medium. Thank you.
>>>>
>>>> IMPORTANT NOTICE: The contents of this email and any attachments are
>>>> confidential and may also be privileged. If you are not the intended
>>>> recipient, please notify the sender immediately and do not disclose
>>>> the contents to any other person, use it for any purpose, or store
>>>> or copy the information in any medium. Thank you.
>>>>
>>>
>>>
>>> 
>>>
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Wang, Sunny (HPS SW)]

Hi all, 

How about we signal ReadyToBoot ONLY for the default platform recovery option?  The default platform recovery option here means the one created by the code below in BdsEntry(). 
  Status = EfiBootManagerInitializeLoadOption (
             &PlatformDefaultBootOption,
             LoadOptionNumberUnassigned,
             LoadOptionTypePlatformRecovery,
             LOAD_OPTION_ACTIVE,
             L"Default PlatformRecovery",
             FilePath,
             NULL,
             0
             );

In other words, we just need to slightly update Pete's patch as the following (adding the code below to EfiBootManagerProcessLoadOption()): 

+   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery) &&
          StrCmp (LoadOption ->Description, L"Default PlatformRecovery")) {
+    //
+    // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
+    //
+    EfiSignalEventReadyToBoot ();

+    //
+    // Report Status Code to indicate ReadyToBoot was signalled  
+    //  
+    REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
+  }

I think the existing platforms that have their platform-specific PlatformRecovery option may also do either of the following things to make the system have no chance to load the default platform recovery option because they do have a better way to recover the boot options:
    1. Make their PlatformRecovery option have higher priority than the default platform recovery option (has a lower number (####) than the default platform recovery option) 
    2. Remove the default platform recovery option. 
Therefore, if we only signal ReadyToBoot for the default platform recovery option, this may not affect the existing platforms because the code may never be run on these platforms. 





If the solution above doesn't work, I think the suggestion (Solution 2: adding a new application as a PlatformRecovery####) I mentioned, in the beginning, can be re-considered. The suggestion (solution 2) is based on the thoughts below: 
     1.  I think that processing/evaluating the Boot#### can be interpreted as the code after the comment " 6. Load EFI boot option to ImageHandle" in EfiBootManagerBoot() because these code are similar to the code in EfiBootManagerProcessLoadOption(). Based on this, I think our current implementation is compliant with the description below in the UEFI spec. Of course, we can improve our implementation by moving the code for processing/evaluating the Boot#### from EfiBootManagerBoot() to EfiBootManagerProcessLoadOption() and make EfiBootManagerBoot() call EfiBootManagerProcessLoadOption(). 
              “After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
     2. Moreover, it looks like we want to process PlatformRecovery#### option in the same way as Boot#### (do more things like setting BootCurrent for PlatformRecovery####). If so, I would still prefer to do what I suggest in the beginning to create a new application as a new PlatformRecovery#### option for generating and launching a boot option for the bootable image that is found by using a short-form File Path Media Device Path so that we won't run into other difficulties. At least, I already saw the difficulty of no connection between BootCurrent variable and PlatformRecovery#### variable. Of course, this application can be implemented without platform specific stuff, so it can be commonly used by all platforms that need to load a boot image discovered by using short-form File Path Media Device Path. 




Regards,
Sunny Wang

-----Original Message-----
From: Laszlo Ersek <lersek@redhat.com> 
Sent: Wednesday, February 17, 2021 10:26 PM
To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io
Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish <afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>; Jian J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

On 02/17/21 13:18, Pete Batard wrote:
> Hi Leif,
> 
> Thanks for trying to resurrect this issue.
> 
> At this stage, and despite some initial pushback in the bugzilla 
> ticket, I believe we can all agree with the consensus that 
> UefiBootManagerLib is not in fact specs-compliant and therefore needs 
> to be fixed, one way or another, to make it specs-compliant.
> 
> My take on this is that, rather than propose a new patch, I'd much 
> rather have the current maintainers agree on the course of action to 
> fix the library (which, as Leif suggests, might very well be to split 
> the library into a specs-compliant and non-specs-compliant version), 
> as it would of course be better if the fix came from people who have 
> better understanding of the ramifications we might face with trying to 
> correct the current behaviour, and especially, who have knowledge of 
> the platforms that might be impacted from making the lib specs-compliant.
> 
> Especially, I don't think that the patch that I originally submitted 
> for this, or the additional proposals we made, are still receivable, 
> as they seem to fall short of fixing the issue in a manner that all 
> platforms can be happy with. And that is why I'd like to hear from the 
> maintainers on what their preferred approach would be.

A new Feature PCD could satisfy both sets of platforms, could it not?

(Sorry if the original patch already had such a PCD; I don't remember.)

Of course then we'd have a debate around the DEC default for the new PCD
-- I'd say the default value of the PCD should match the spec-mandated behavior.

I don't recall any specifics, but a bug-compat pattern that's sometimes used is this:

  if (BugCompatEnabled) {
    //
    // do the right thing in the wrong place, for legacy platforms' sake
    //
   Foo ();
  }

  //
  // Do some stuff.
  //
  Bar ();

  if (!BugCompatEnabled) {
    //
    // do the right thing in the right place, for conformant platforms
    //
   Foo ();
  }

Not sure if it applies here.

Thanks
Laszlo


> On 2021.02.17 11:42, Leif Lindholm wrote:
>> Hi Pete, +various
>>
>> Resurrecting this old thread since Ard pointed out an issue I ran 
>> into myself had already been encountered by Pete.
>> And the bugzilla ticket (directly below this reply) has had no 
>> relevant progress since August.
>>
>> Executive summary:
>> The current UefiBootManagerLib implementation of the PlatformRecovery 
>> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
>>
>> The argument has been made that since changing this would affect an 
>> unnamed number of non-public platforms, the behaviour cannot be 
>> changed even though it violates the UEFI specification.
>>
>> I disagree with that statement. If we want to fork UefiBootManagerLib 
>> into a BrokenLegacyUefiBootManagerLib and an actually correct one, 
>> and have those platforms move to the BrokenLegacy variant, I'm OK 
>> with that.
>>
>> But using the default version should give specification-compliant 
>> behaviour.
>>
>> /
>>      Leif
>>
>> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
>>> Please note that I have created a bug report
>>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the 
>>> non-compliance issue was raised during the course of the discussion 
>>> below.
>>>
>>> Regards,
>>>
>>> /Pete
>>>
>>>
>>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
>>>> I worked with Pete offline on this..
>>>>
>>>> This code seems to be violating the UEFI Spec:
>>>>
>>>> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de
>>>> 7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
>>>>
>>>>
>>>>     //
>>>>     // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are 
>>>> about to load and execute
>>>>     //    the boot option.
>>>>     //
>>>>     if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
>>>>       DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
>>>>       BmStopHotkeyService (NULL, NULL);
>>>>     } else {
>>>>       EfiSignalEventReadyToBoot();
>>>>       //
>>>>       // Report Status Code to indicate ReadyToBoot was signalled
>>>>       //
>>>>       REPORT_STATUS_CODE (EFI_PROGRESS_CODE, 
>>>> (EFI_SOFTWARE_DXE_BS_DRIVER | 
>>>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>       //
>>>>       // 4. Repair system through DriverHealth protocol
>>>>       //
>>>>       BmRepairAllControllers (0);
>>>>     }
>>>>
>>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and 
>>>> their FilePathList) *shall not* be evaluated prior to the 
>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
>>>>
>>>> "After all SysPrep#### variables have been launched and exited, the 
>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and 
>>>> begin to evaluate Boot#### variables with Attributes set to 
>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by 
>>>> BootOrder. The FilePathList of variables marked 
>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the 
>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>
>>>> This is a prescriptive language that is stronger than the language 
>>>> in section 7.1 which defines the ReadyToBoot event group in a 
>>>> general way:
>>>>
>>>> "EFI_EVENT_GROUP_RESET_SYSTEM
>>>> This event group is notified by the system when ResetSystem() is 
>>>> invoked and the system is about to be reset. The event group is 
>>>> only notified prior to ExitBootServices() invocation."
>>>>
>>>> The EDK2 code in the else block above (to call
>>>> EfiSignalEventReadyToBoot() ) need to move before the code that is 
>>>> processing BootOption->FilePath. In fact, why is this signaling 
>>>> even a BootManager task? It should be a higher level BDS task 
>>>> (after processing SysPrp and before processing Boot options, per the spec).
>>>> This would be somewhere around
>>>> https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea021
>>>> 4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
>>>> where SysPrep is processed.
>>>>
>>>> This should also take care of the issue Pete reported in this 
>>>> thread, without the need for explicitly signaling ReadyToBoot from 
>>>> PlatformRecovery (or changing the UEFI spec).
>>>>
>>>> Thanks,
>>>> --Samer
>>>>
>>>>
>>>>
>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of 
>>>> Samer El-Haj-Mahmoud via groups.io
>>>> Sent: Wednesday, June 17, 2020 12:42 PM
>>>> To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com) 
>>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; 
>>>> pete@akeo.ie
>>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel 
>>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud 
>>>> <Samer.El-Haj-Mahmoud@arm.com>
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
>>>> recovery
>>>>
>>>> The UEFI spec (3.1.7) says:
>>>>
>>>> "After all SysPrep#### variables have been launched and exited, the 
>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and 
>>>> begin to evaluate Boot#### variables with Attributes set to 
>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by 
>>>> BootOrder. The FilePathList of variables marked 
>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the 
>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>
>>>> The way I read this, I expect ReadyToBoot to be signaled after 
>>>> SysPrep#### (if any) are processed, but before Boot#### are 
>>>> processed. Is my understanding correct that this language implies 
>>>> ReadyToBoot need to be signaled even if BootOrder does not contain 
>>>> any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if 
>>>> so, is EDK2 not doing this, which leads us to this patch (signaling 
>>>> it in PlatformRecovery?)
>>>>
>>>>
>>>>
>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On 
>>>> Behalf Of Andrei Warkentin via groups.io
>>>> Sent: Wednesday, June 17, 2020 12:37 PM
>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; 
>>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard 
>>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>; 
>>>> mailto:leif@nuviainc.com
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
>>>> recovery
>>>>
>>>> Thanks Pete.
>>>>
>>>> I think the question I have, that I hope Tiano veterans can chime 
>>>> in, is whether we are doing the right thing, or if we should be 
>>>> overriding the boot mode? I.e. is it normal that we boot up in 
>>>> recovery until options are saved?
>>>>
>>>>
>>>> A
>>>>
>>>>
>>>> ________________________________________
>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on 
>>>> behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
>>>> Sent: Wednesday, June 17, 2020 11:34 AM
>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; 
>>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>; 
>>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>; 
>>>> mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>; 
>>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
>>>> recovery
>>>>
>>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>>>>> Thanks for checking my comments, Pete.
>>>>>
>>>>>> Or is the "one more" the issue, meaning that it would get 
>>>>>> signaled more than once?
>>>>> [Sunny] Yeah, it would get signaled more than once if the 
>>>>> PlatformRecovery option (a UEFI application) calls
>>>>> EfiBootManagerBoot() to launch the recovered boot option inside of 
>>>>> the application.
>>>>
>>>> Okay.
>>>>
>>>> One element that I'm going to point out is that, with the current 
>>>> EDK2 code (i.e. without this proposal applied), and after a user 
>>>> goes into the setup to save their boot options in order for regular 
>>>> boot options to get executed instead of PlaformRecovery, the 
>>>> OnReadyToBoot event is actually called twice.
>>>>
>>>> So my understanding is that, while we of course want to avoid this 
>>>> and any patch proposal should actively try to prevent it, it seems 
>>>> we already have behaviour in EDK2 that can lead to OnReadyToBoot 
>>>> being signalled more than once.
>>>>
>>>> At least the current Pi 4 platform does demonstrate this behaviour. 
>>>> For instance, if you run DEBUG, you will see two instances of:
>>>>
>>>>      RemoveDtStdoutPath: could not retrieve DT blob - Not Found
>>>>
>>>> which is a one-instance message generated from the ConsolePrefDxe's
>>>> OnReadyToBoot() call. I've also confirmed more specifically that
>>>> OnReadyToBoot() is indeed called twice.
>>>>
>>>> I don't recall us doing much of any special with regards to boot 
>>>> options for the Pi platform, so my guess is that it's probably not 
>>>> the only platform where OnReadyToBoot might be signalled more than 
>>>> once, and that this might be tied to a default EDK2 behaviour. 
>>>> Therefore I don't see having a repeated event as a major deal 
>>>> breaker (though, again, if we can avoid that, we of course will 
>>>> want to).
>>>>
>>>>>> I don't mind trying an alternative approach, but I don't 
>>>>>> understand how what you describe would help. Can you please be 
>>>>>> more specific about what you have in mind?
>>>>> [Sunny] Sure. I added more information below. If it is still not 
>>>>> clear enough, feel free to let me know.
>>>>>         1. Create a UEFI application with the code to signal 
>>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB 
>>>>> and run it.
>>>>
>>>> So that would basically be adding code that duplicates, in part, 
>>>> what Platform Recovery already does.
>>>>
>>>> I have to be honest: Even outside of the extra work this would 
>>>> require, I don't really like the idea of having to write our own 
>>>> application, as it will introduce new possible points of failures 
>>>> and require extra maintenance (especially as we will want to be 
>>>> able to handle network boot and other options, and before long, I 
>>>> fear that we're going to have to write our own Pi specific boot 
>>>> manager). Doing so simply because the current Platform Recovery, 
>>>> which does suit our needs otherwise, is not designed to call 
>>>> ReadyToBoot does not seem like the best course of action in my 
>>>> book.
>>>>
>>>> Instead, I still logically believe that any option that calls a 
>>>> boot loader should signal ReadyToBoot, regardless of whether it was 
>>>> launched from Boot Manager or Platform Recovery, and that it 
>>>> shouldn't be left to each platform to work around that.
>>>>
>>>> Of course, I understand that this would require a specs change, and 
>>>> that it also may have ramifications for existing platforms that 
>>>> interpret the current specs pedantically. But to me, regardless of 
>>>> what the specs appear to be limiting it to right now, the logic of 
>>>> a "ReadyToBoot"
>>>> event is that it should be signalled whenever a bootloader is about 
>>>> to be executed, rather than only when a bootloader happened to be 
>>>> launched through a formal Boot Manager option.
>>>>
>>>> I would therefore appreciate if other people could weigh in on this 
>>>> matter, to see if I'm the only one who believes that we could 
>>>> ultimately have more to gain from signalling ReadyToBoot with 
>>>> PlatformRecovery options than leaving things as they stand right 
>>>> now...
>>>>
>>>>>         2. Then, call EfiBootManagerInitializeLoadOption like the 
>>>>> following in a DXE driver or other places before "Default 
>>>>> PlatformRecovery" registration:
>>>>>      Status = EfiBootManagerInitializeLoadOption (
>>>>>                 &LoadOption,
>>>>>                
>>>>> 0,
>>>>> -> 0 is the OptionNumber to let application be load before "
>>>>> Default PlatformRecovery" option
>>>>>                 LoadOptionTypePlatformRecovery,
>>>>>                 LOAD_OPTION_ACTIVE,
>>>>>                 L"Application for recovering boot options",
>>>>>                
>>>>> FilePath,
>>>>> -> FilePath is the Application's device path,
>>>>>                 NULL,
>>>>>                 0
>>>>>                 );
>>>>>
>>>>>
>>>>>> My reasoning is that, if PlatformRecovery#### can execute a 
>>>>>> regular bootloader like /efi/boot/boot####.efi from installation 
>>>>>> media, then it should go through the same kind of initialization 
>>>>>> that happens for a regular boot option, and that should include 
>>>>>> signaling the ReadyToBoot event.
>>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed 
>>>>> your cover letter for this patch.  I was just thinking that we may 
>>>>> not really need to make this behavior change in both EDK II code 
>>>>> and UEFI specification for solving the problem specific to the 
>>>>> case that OS is loaded by "Default PlatformRecovery" option,
>>>>
>>>> The way I see it is that the Pi platform is unlikely to be the only 
>>>> one where PlatformRecovery is seen as a means to install an OS. 
>>>> Granted, this may seem like abusing the option, but since UEFI 
>>>> doesn't provide an "Initial OS Install" mode, I would assert that 
>>>> it as good a use of this option as any.
>>>>
>>>> In other words, I don't think this improvement would only benefit 
>>>> the Pi platform.
>>>>
>>>>> and I'm also not sure if it is worth making this change to affect 
>>>>> some of the system or BIOS vendors who have implemented their 
>>>>> PlatformRecovery option.
>>>>
>>>> That's a legitimate concern, and I would agree the one major 
>>>> potential pitfall of this proposal, if there happens to exist a 
>>>> system where an OnReadyToBoot even before running the recovery 
>>>> option can have adverse effects.
>>>>
>>>> I don't really believe that such a system exists, because I expect 
>>>> most recovery boot loaders to also work (or at least have been 
>>>> designed to
>>>> work) as regular boot options. But I don't have enough experience 
>>>> with platform recovery to know if that's a correct assertion to make...
>>>>
>>>>> If the alternative approach I mentioned works for you, I think 
>>>>> that would be an easier solution.
>>>>
>>>> Right now, even as the patch proposal has multiple issues that 
>>>> require it to be amended (Don't signal ReadyToBoot except for 
>>>> PlatformRecovery
>>>> + Prevent situations where ReadyToBoot could be signalled multiple
>>>> times) I still see it as both an easier solution than the 
>>>> alternative, as well as one that *should* benefit people who design 
>>>> Platform Recovery UEFI applications in the long run. So that is why 
>>>> I am still trying to advocate for it.
>>>>
>>>> But I very much hear your concerns, and I agree that specs changes 
>>>> are better avoided when possible.
>>>>
>>>> Thus, at this stage, even as I don't want to drag this discussion 
>>>> much further, I don't feel like I want to commit to one solution or 
>>>> the other before we have had a chance to hear other people, who may 
>>>> have their own opinion on the matter, express their views.
>>>>
>>>> Regards,
>>>>
>>>> /Pete
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> Sunny Wang
>>>>>
>>>>> -----Original Message-----
>>>>> From: Pete Batard [mailto:pete@akeo.ie]
>>>>> Sent: Wednesday, June 17, 2020 6:59 PM
>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>; 
>>>>> mailto:devel@edk2.groups.io
>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; 
>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
>>>>> recovery
>>>>>
>>>>> Hi Sunny, thanks for looking into this.
>>>>>
>>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>>>>> Hi Pete.
>>>>>>
>>>>>> Since the EfiBootManagerProcessLoadOption is called by 
>>>>>> ProcessLoadOptions as well, your change would also cause some 
>>>>>> unexpected behavior like:
>>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option 
>>>>>> which is an application that calls EfiBootManagerBoot() to launch 
>>>>>> its recovered boot option.
>>>>>
>>>>> I'm not sure I understand how this part is unwanted.
>>>>>
>>>>> The point of this patch is to ensure that ReadyToBoot is signalled 
>>>>> for the PlatformRecovery option, so isn't what you describe above 
>>>>> exactly what we want?
>>>>>
>>>>> Or is the "one more" the issue, meaning that it would get 
>>>>> signalled more than once?
>>>>>
>>>>>
>>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not 
>>>>>> really a "boot" option.
>>>>>
>>>>> Yes, I've been wondering about that, because BdsEntry.c's 
>>>>> ProcessLoadOptions(), which calls 
>>>>> EfiBootManagerProcessLoadOption(),
>>>>> mentions that it will load will load and start every Driver####, 
>>>>> SysPrep#### or PlatformRecovery####. But the comment about the
>>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions 
>>>>> PlatformRecovery####.
>>>>>
>>>>> If needed, I guess we could amend the patch to detect the type of 
>>>>> option and only signal ReadyToBoot for PlatformRecovery####.
>>>>>
>>>>>> To solve your problem, creating a PlatformRecovery option with 
>>>>>> the smallest option number and using it instead of default one 
>>>>>> (with short-form File Path Media Device Path) looks like a 
>>>>>> simpler solution.
>>>>>
>>>>> I don't mind trying an alternative approach, but I don't 
>>>>> understand how what you describe would help. Can you please be 
>>>>> more specific about what you have in mind?
>>>>>
>>>>> Our main issue here is that we must have ReadyToBoot signalled so 
>>>>> that the ReadyToBoot() function callback from 
>>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the 
>>>>> boot loader invoked from PlatformRecovery####  to use a properly 
>>>>> initialized graphical console. So I'm not sure I quite get how 
>>>>> switching from one PlatformRecovery#### option to another would 
>>>>> improve things.
>>>>>
>>>>> If it helps, here is what we currently default to, in terms of 
>>>>> boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>>>>>
>>>>> [Bds]=============Begin Load Options Dumping ...=============
>>>>>       Driver Options:
>>>>>       SysPrep Options:
>>>>>       Boot Options:
>>>>>         Boot0000: UiApp              0x0109
>>>>>         Boot0001: UEFI Shell                 0x0000
>>>>>       PlatformRecovery Options:
>>>>>         PlatformRecovery0000: Default PlatformRecovery               
>>>>> 0x0001 [Bds]=============End Load Options Dumping=============
>>>>>
>>>>> With this, PlatformRecovery0000 gets executed by default, which is 
>>>>> what we want, since it will pick /efi/boot/bootaa64.efi from 
>>>>> either SD or USB and run it, the only issue being that, because 
>>>>> ReadyToBoot has not been executed, the graphical console is not 
>>>>> operative so users can't interact with the OS installer.
>>>>>
>>>>> So I'm really not sure how adding an extra PlatformRecovery#### 
>>>>> would help. And I'm also not too familiar with how one would go 
>>>>> around to add such an entry...
>>>>>
>>>>>> By the way, I also checked the UEFI specification. It looks 
>>>>>> making sense to only signal ReadyToBoot for boot option (Boot####).
>>>>>
>>>>> That's something I considered too, but I disagree with this 
>>>>> conclusion.
>>>>>
>>>>> My reasoning is that, if PlatformRecovery#### can execute a 
>>>>> regular bootloader like /efi/boot/boot####.efi from installation 
>>>>> media, then it should go through the same kind of initialization 
>>>>> that happens for a regular boot option, and that should include 
>>>>> signalling the ReadyToBoot event.
>>>>>
>>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
>>>>> /efi/boot/recovery####.efi) then I would agree with only 
>>>>> signalling ReadyToBoot for a formal Boot#### option. But that 
>>>>> isn't the case, so I think it is reasonable to want to have 
>>>>> ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is 
>>>>> executed from PlatformRecovery####., especially when we know it 
>>>>> can be crucial to ensuring that the end user can actually use the graphical console.
>>>>>
>>>>>> Therefore, your change may also require specification change.
>>>>>
>>>>> Yes, I mentioned that in the cover letter for this patch
>>>>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>> Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Ca
>>>>> warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138
>>>>> ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=
>>>>> 2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0
>>>>> ), which also describes the issue we are trying to solve in 
>>>>> greater details. This is what I wrote:
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> ------
>>>>>
>>>>> Note however that this may require a specs update, as the current 
>>>>> UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>>>>>
>>>>>     >  EFI_EVENT_GROUP_READY_TO_BOOT
>>>>>     >    This event group is notified by the system when the Boot 
>>>>> Manager
>>>>>     >    is about to load and execute a boot option.
>>>>>
>>>>> and, once this patch has been applied, we may want to update this 
>>>>> section to mention that it applies to both Boot Manager and 
>>>>> Platform Recovery.
>>>>> ------------------------------------------------------------------
>>>>> ------
>>>>>
>>>>>
>>>>>
>>>>> Again, I don't have an issue with trying to use an alternate 
>>>>> approach to solve our problem (though I ultimately believe that, 
>>>>> if PlatformRecovery#### can launch a /efi/boot/boot####.efi 
>>>>> bootloader then we must update the specs and the code to have 
>>>>> ReadyToBoot also signalled then, because that's the logical thing 
>>>>> to do). But right now, I'm not seeing how to achieve that when 
>>>>> PlatformRecovery#### is the option that is used to launch the OS 
>>>>> installation the bootloader. So if you can provide mode details on 
>>>>> how exactly you think creating an alternate PlatformRecovery 
>>>>> option would help, I would appreciate it.
>>>>>
>>>>> Regards,
>>>>>
>>>>> /Pete
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Sunny Wang
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io] 
>>>>>> On Behalf Of Pete Batard
>>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>>>>> To: mailto:devel@edk2.groups.io
>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; 
>>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform 
>>>>>> recovery
>>>>>>
>>>>>> Currently, the ReadyToBoot event is only signaled when a formal 
>>>>>> Boot Manager option is executed (in BmBoot.c -> 
>>>>>> EfiBootManagerBoot ()).
>>>>>>
>>>>>> However, with the introduction of Platform Recovery in UEFI 2.5, 
>>>>>> which may lead to the execution of a boot loader that has similar 
>>>>>> requirements to a regular one, yet is not launched as a Boot 
>>>>>> Manager option, it also becomes necessary to signal ReadyToBoot 
>>>>>> when a Platform Recovery boot loader runs.
>>>>>>
>>>>>> Especially, this can be critical to ensuring that the graphical 
>>>>>> console is actually usable during platform recovery, as some 
>>>>>> platforms do rely on the ConsolePrefDxe driver, which only 
>>>>>> performs console initialization after ReadyToBoot is triggered.
>>>>>>
>>>>>> This patch fixes that behaviour by calling 
>>>>>> EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption 
>>>>>> (), which is the function that sets up the platform recovery boot 
>>>>>> process.
>>>>>>
>>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>>>>>> ---
>>>>>>      MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9
>>>>>> +++++++++
>>>>>>      1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git 
>>>>>> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> index 89372b3b97b8..117f1f5b124c 100644
>>>>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>>>>          return EFI_SUCCESS;
>>>>>>        }
>>>>>>
>>>>>> +  //
>>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
>>>>>> to load and execute the boot option.
>>>>>> +  //
>>>>>> +  EfiSignalEventReadyToBoot ();
>>>>>> +  //
>>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled  
>>>>>> +//  REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
>>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
>>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>>> +
>>>>>>        //
>>>>>>        // Load and start the load option.
>>>>>>        //
>>>>>> --
>>>>>> 2.21.0.windows.1
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> IMPORTANT NOTICE: The contents of this email and any attachments 
>>>> are confidential and may also be privileged. If you are not the 
>>>> intended recipient, please notify the sender immediately and do not 
>>>> disclose the contents to any other person, use it for any purpose, 
>>>> or store or copy the information in any medium. Thank you.
>>>>
>>>> IMPORTANT NOTICE: The contents of this email and any attachments 
>>>> are confidential and may also be privileged. If you are not the 
>>>> intended recipient, please notify the sender immediately and do not 
>>>> disclose the contents to any other person, use it for any purpose, 
>>>> or store or copy the information in any medium. Thank you.
>>>>
>>>
>>>
>>> 
>>>
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Pete Batard]

Hi Sunny,

I appreciate the input, but seeing that it is clear that no consensus 
has been reached with regards to how the specs should be interpreted, 
and that at least 4 separate people have now indicated that their 
interpretation is different from the one you are putting forward (i.e. 
you assert that the current code implementation is specs compliant 
whereas we assert that the current code implementation is not specs 
compliant), I believe that any further work on this will have to be 
conditioned, first, by a specs update, that removes any ambiguity as to 
the scope in which ReadyToBoot should apply.

Until that has happened, it seems very pointless to me to start talking 
possible code workarounds, because we still can't appear to be in 
agreement as to whether the current code implementation of ReadyToBoot 
is specs compliant or not.

Now, even as I am the one proposing it, I'm afraid that I am not 
planning to be the one opening a formal specs update request, since 
there really is only so much more time I am willing to devote to this 
matter. But I am hoping somebody else will.

Regards,

/Pete

On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
> Hi all,
> 
> How about we signal ReadyToBoot ONLY for the default platform recovery option?  The default platform recovery option here means the one created by the code below in BdsEntry().
>    Status = EfiBootManagerInitializeLoadOption (
>               &PlatformDefaultBootOption,
>               LoadOptionNumberUnassigned,
>               LoadOptionTypePlatformRecovery,
>               LOAD_OPTION_ACTIVE,
>               L"Default PlatformRecovery",
>               FilePath,
>               NULL,
>               0
>               );
> 
> In other words, we just need to slightly update Pete's patch as the following (adding the code below to EfiBootManagerProcessLoadOption()):
> 
> +   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery) &&
>            StrCmp (LoadOption ->Description, L"Default PlatformRecovery")) {
> +    //
> +    // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about to load and execute the boot option.
> +    //
> +    EfiSignalEventReadyToBoot ();
> 
> +    //
> +    // Report Status Code to indicate ReadyToBoot was signalled
> +    //
> +    REPORT_STATUS_CODE (EFI_PROGRESS_CODE, (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> +  }
> 
> I think the existing platforms that have their platform-specific PlatformRecovery option may also do either of the following things to make the system have no chance to load the default platform recovery option because they do have a better way to recover the boot options:
>      1. Make their PlatformRecovery option have higher priority than the default platform recovery option (has a lower number (####) than the default platform recovery option)
>      2. Remove the default platform recovery option.
> Therefore, if we only signal ReadyToBoot for the default platform recovery option, this may not affect the existing platforms because the code may never be run on these platforms.
> 
> 
> 
> 
> 
> If the solution above doesn't work, I think the suggestion (Solution 2: adding a new application as a PlatformRecovery####) I mentioned, in the beginning, can be re-considered. The suggestion (solution 2) is based on the thoughts below:
>       1.  I think that processing/evaluating the Boot#### can be interpreted as the code after the comment " 6. Load EFI boot option to ImageHandle" in EfiBootManagerBoot() because these code are similar to the code in EfiBootManagerProcessLoadOption(). Based on this, I think our current implementation is compliant with the description below in the UEFI spec. Of course, we can improve our implementation by moving the code for processing/evaluating the Boot#### from EfiBootManagerBoot() to EfiBootManagerProcessLoadOption() and make EfiBootManagerBoot() call EfiBootManagerProcessLoadOption().
>                “After all SysPrep#### variables have been launched and exited, the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and begin to evaluate Boot#### variables with Attributes set to LOAD_OPTION_CATEGORY_BOOT according to the order defined by BootOrder. The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>       2. Moreover, it looks like we want to process PlatformRecovery#### option in the same way as Boot#### (do more things like setting BootCurrent for PlatformRecovery####). If so, I would still prefer to do what I suggest in the beginning to create a new application as a new PlatformRecovery#### option for generating and launching a boot option for the bootable image that is found by using a short-form File Path Media Device Path so that we won't run into other difficulties. At least, I already saw the difficulty of no connection between BootCurrent variable and PlatformRecovery#### variable. Of course, this application can be implemented without platform specific stuff, so it can be commonly used by all platforms that need to load a boot image discovered by using short-form File Path Media Device Path.
> 
> 
> 
> 
> Regards,
> Sunny Wang
> 
> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, February 17, 2021 10:26 PM
> To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>; devel@edk2.groups.io
> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish <afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>; Jian J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
> Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery
> 
> On 02/17/21 13:18, Pete Batard wrote:
>> Hi Leif,
>>
>> Thanks for trying to resurrect this issue.
>>
>> At this stage, and despite some initial pushback in the bugzilla
>> ticket, I believe we can all agree with the consensus that
>> UefiBootManagerLib is not in fact specs-compliant and therefore needs
>> to be fixed, one way or another, to make it specs-compliant.
>>
>> My take on this is that, rather than propose a new patch, I'd much
>> rather have the current maintainers agree on the course of action to
>> fix the library (which, as Leif suggests, might very well be to split
>> the library into a specs-compliant and non-specs-compliant version),
>> as it would of course be better if the fix came from people who have
>> better understanding of the ramifications we might face with trying to
>> correct the current behaviour, and especially, who have knowledge of
>> the platforms that might be impacted from making the lib specs-compliant.
>>
>> Especially, I don't think that the patch that I originally submitted
>> for this, or the additional proposals we made, are still receivable,
>> as they seem to fall short of fixing the issue in a manner that all
>> platforms can be happy with. And that is why I'd like to hear from the
>> maintainers on what their preferred approach would be.
> 
> A new Feature PCD could satisfy both sets of platforms, could it not?
> 
> (Sorry if the original patch already had such a PCD; I don't remember.)
> 
> Of course then we'd have a debate around the DEC default for the new PCD
> -- I'd say the default value of the PCD should match the spec-mandated behavior.
> 
> I don't recall any specifics, but a bug-compat pattern that's sometimes used is this:
> 
>    if (BugCompatEnabled) {
>      //
>      // do the right thing in the wrong place, for legacy platforms' sake
>      //
>     Foo ();
>    }
> 
>    //
>    // Do some stuff.
>    //
>    Bar ();
> 
>    if (!BugCompatEnabled) {
>      //
>      // do the right thing in the right place, for conformant platforms
>      //
>     Foo ();
>    }
> 
> Not sure if it applies here.
> 
> Thanks
> Laszlo
> 
> 
>> On 2021.02.17 11:42, Leif Lindholm wrote:
>>> Hi Pete, +various
>>>
>>> Resurrecting this old thread since Ard pointed out an issue I ran
>>> into myself had already been encountered by Pete.
>>> And the bugzilla ticket (directly below this reply) has had no
>>> relevant progress since August.
>>>
>>> Executive summary:
>>> The current UefiBootManagerLib implementation of the PlatformRecovery
>>> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
>>>
>>> The argument has been made that since changing this would affect an
>>> unnamed number of non-public platforms, the behaviour cannot be
>>> changed even though it violates the UEFI specification.
>>>
>>> I disagree with that statement. If we want to fork UefiBootManagerLib
>>> into a BrokenLegacyUefiBootManagerLib and an actually correct one,
>>> and have those platforms move to the BrokenLegacy variant, I'm OK
>>> with that.
>>>
>>> But using the default version should give specification-compliant
>>> behaviour.
>>>
>>> /
>>>       Leif
>>>
>>> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
>>>> Please note that I have created a bug report
>>>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
>>>> non-compliance issue was raised during the course of the discussion
>>>> below.
>>>>
>>>> Regards,
>>>>
>>>> /Pete
>>>>
>>>>
>>>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
>>>>> I worked with Pete offline on this..
>>>>>
>>>>> This code seems to be violating the UEFI Spec:
>>>>>
>>>>> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de
>>>>> 7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L1763
>>>>>
>>>>>
>>>>>      //
>>>>>      // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
>>>>> about to load and execute
>>>>>      //    the boot option.
>>>>>      //
>>>>>      if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
>>>>>        DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
>>>>>        BmStopHotkeyService (NULL, NULL);
>>>>>      } else {
>>>>>        EfiSignalEventReadyToBoot();
>>>>>        //
>>>>>        // Report Status Code to indicate ReadyToBoot was signalled
>>>>>        //
>>>>>        REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
>>>>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>>        //
>>>>>        // 4. Repair system through DriverHealth protocol
>>>>>        //
>>>>>        BmRepairAllControllers (0);
>>>>>      }
>>>>>
>>>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and
>>>>> their FilePathList) *shall not* be evaluated prior to the
>>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing:
>>>>>
>>>>> "After all SysPrep#### variables have been launched and exited, the
>>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and
>>>>> begin to evaluate Boot#### variables with Attributes set to
>>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
>>>>> BootOrder. The FilePathList of variables marked
>>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
>>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>>
>>>>> This is a prescriptive language that is stronger than the language
>>>>> in section 7.1 which defines the ReadyToBoot event group in a
>>>>> general way:
>>>>>
>>>>> "EFI_EVENT_GROUP_RESET_SYSTEM
>>>>> This event group is notified by the system when ResetSystem() is
>>>>> invoked and the system is about to be reset. The event group is
>>>>> only notified prior to ExitBootServices() invocation."
>>>>>
>>>>> The EDK2 code in the else block above (to call
>>>>> EfiSignalEventReadyToBoot() ) need to move before the code that is
>>>>> processing BootOption->FilePath. In fact, why is this signaling
>>>>> even a BootManager task? It should be a higher level BDS task
>>>>> (after processing SysPrp and before processing Boot options, per the spec).
>>>>> This would be somewhere around
>>>>> https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea021
>>>>> 4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
>>>>> where SysPrep is processed.
>>>>>
>>>>> This should also take care of the issue Pete reported in this
>>>>> thread, without the need for explicitly signaling ReadyToBoot from
>>>>> PlatformRecovery (or changing the UEFI spec).
>>>>>
>>>>> Thanks,
>>>>> --Samer
>>>>>
>>>>>
>>>>>
>>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
>>>>> Samer El-Haj-Mahmoud via groups.io
>>>>> Sent: Wednesday, June 17, 2020 12:42 PM
>>>>> To: devel@edk2.groups.io; Andrei Warkentin (awarkentin@vmware.com)
>>>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW) <sunnywang@hpe.com>;
>>>>> pete@akeo.ie
>>>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
>>>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-Mahmoud
>>>>> <Samer.El-Haj-Mahmoud@arm.com>
>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>> recovery
>>>>>
>>>>> The UEFI spec (3.1.7) says:
>>>>>
>>>>> "After all SysPrep#### variables have been launched and exited, the
>>>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group and
>>>>> begin to evaluate Boot#### variables with Attributes set to
>>>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
>>>>> BootOrder. The FilePathList of variables marked
>>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
>>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
>>>>>
>>>>> The way I read this, I expect ReadyToBoot to be signaled after
>>>>> SysPrep#### (if any) are processed, but before Boot#### are
>>>>> processed. Is my understanding correct that this language implies
>>>>> ReadyToBoot need to be signaled even if BootOrder does not contain
>>>>> any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT? And if
>>>>> so, is EDK2 not doing this, which leads us to this patch (signaling
>>>>> it in PlatformRecovery?)
>>>>>
>>>>>
>>>>>
>>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> On
>>>>> Behalf Of Andrei Warkentin via groups.io
>>>>> Sent: Wednesday, June 17, 2020 12:37 PM
>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
>>>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>;
>>>>> mailto:leif@nuviainc.com
>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>> recovery
>>>>>
>>>>> Thanks Pete.
>>>>>
>>>>> I think the question I have, that I hope Tiano veterans can chime
>>>>> in, is whether we are doing the right thing, or if we should be
>>>>> overriding the boot mode? I.e. is it normal that we boot up in
>>>>> recovery until options are saved?
>>>>>
>>>>>
>>>>> A
>>>>>
>>>>>
>>>>> ________________________________________
>>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io> on
>>>>> behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
>>>>> Sent: Wednesday, June 17, 2020 11:34 AM
>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
>>>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
>>>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
>>>>> mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>;
>>>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>> recovery
>>>>>
>>>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
>>>>>> Thanks for checking my comments, Pete.
>>>>>>
>>>>>>> Or is the "one more" the issue, meaning that it would get
>>>>>>> signaled more than once?
>>>>>> [Sunny] Yeah, it would get signaled more than once if the
>>>>>> PlatformRecovery option (a UEFI application) calls
>>>>>> EfiBootManagerBoot() to launch the recovered boot option inside of
>>>>>> the application.
>>>>>
>>>>> Okay.
>>>>>
>>>>> One element that I'm going to point out is that, with the current
>>>>> EDK2 code (i.e. without this proposal applied), and after a user
>>>>> goes into the setup to save their boot options in order for regular
>>>>> boot options to get executed instead of PlaformRecovery, the
>>>>> OnReadyToBoot event is actually called twice.
>>>>>
>>>>> So my understanding is that, while we of course want to avoid this
>>>>> and any patch proposal should actively try to prevent it, it seems
>>>>> we already have behaviour in EDK2 that can lead to OnReadyToBoot
>>>>> being signalled more than once.
>>>>>
>>>>> At least the current Pi 4 platform does demonstrate this behaviour.
>>>>> For instance, if you run DEBUG, you will see two instances of:
>>>>>
>>>>>       RemoveDtStdoutPath: could not retrieve DT blob - Not Found
>>>>>
>>>>> which is a one-instance message generated from the ConsolePrefDxe's
>>>>> OnReadyToBoot() call. I've also confirmed more specifically that
>>>>> OnReadyToBoot() is indeed called twice.
>>>>>
>>>>> I don't recall us doing much of any special with regards to boot
>>>>> options for the Pi platform, so my guess is that it's probably not
>>>>> the only platform where OnReadyToBoot might be signalled more than
>>>>> once, and that this might be tied to a default EDK2 behaviour.
>>>>> Therefore I don't see having a repeated event as a major deal
>>>>> breaker (though, again, if we can avoid that, we of course will
>>>>> want to).
>>>>>
>>>>>>> I don't mind trying an alternative approach, but I don't
>>>>>>> understand how what you describe would help. Can you please be
>>>>>>> more specific about what you have in mind?
>>>>>> [Sunny] Sure. I added more information below. If it is still not
>>>>>> clear enough, feel free to let me know.
>>>>>>          1. Create a UEFI application with the code to signal
>>>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB
>>>>>> and run it.
>>>>>
>>>>> So that would basically be adding code that duplicates, in part,
>>>>> what Platform Recovery already does.
>>>>>
>>>>> I have to be honest: Even outside of the extra work this would
>>>>> require, I don't really like the idea of having to write our own
>>>>> application, as it will introduce new possible points of failures
>>>>> and require extra maintenance (especially as we will want to be
>>>>> able to handle network boot and other options, and before long, I
>>>>> fear that we're going to have to write our own Pi specific boot
>>>>> manager). Doing so simply because the current Platform Recovery,
>>>>> which does suit our needs otherwise, is not designed to call
>>>>> ReadyToBoot does not seem like the best course of action in my
>>>>> book.
>>>>>
>>>>> Instead, I still logically believe that any option that calls a
>>>>> boot loader should signal ReadyToBoot, regardless of whether it was
>>>>> launched from Boot Manager or Platform Recovery, and that it
>>>>> shouldn't be left to each platform to work around that.
>>>>>
>>>>> Of course, I understand that this would require a specs change, and
>>>>> that it also may have ramifications for existing platforms that
>>>>> interpret the current specs pedantically. But to me, regardless of
>>>>> what the specs appear to be limiting it to right now, the logic of
>>>>> a "ReadyToBoot"
>>>>> event is that it should be signalled whenever a bootloader is about
>>>>> to be executed, rather than only when a bootloader happened to be
>>>>> launched through a formal Boot Manager option.
>>>>>
>>>>> I would therefore appreciate if other people could weigh in on this
>>>>> matter, to see if I'm the only one who believes that we could
>>>>> ultimately have more to gain from signalling ReadyToBoot with
>>>>> PlatformRecovery options than leaving things as they stand right
>>>>> now...
>>>>>
>>>>>>          2. Then, call EfiBootManagerInitializeLoadOption like the
>>>>>> following in a DXE driver or other places before "Default
>>>>>> PlatformRecovery" registration:
>>>>>>       Status = EfiBootManagerInitializeLoadOption (
>>>>>>                  &LoadOption,
>>>>>>                 
>>>>>> 0,
>>>>>> -> 0 is the OptionNumber to let application be load before "
>>>>>> Default PlatformRecovery" option
>>>>>>                  LoadOptionTypePlatformRecovery,
>>>>>>                  LOAD_OPTION_ACTIVE,
>>>>>>                  L"Application for recovering boot options",
>>>>>>                 
>>>>>> FilePath,
>>>>>> -> FilePath is the Application's device path,
>>>>>>                  NULL,
>>>>>>                  0
>>>>>>                  );
>>>>>>
>>>>>>
>>>>>>> My reasoning is that, if PlatformRecovery#### can execute a
>>>>>>> regular bootloader like /efi/boot/boot####.efi from installation
>>>>>>> media, then it should go through the same kind of initialization
>>>>>>> that happens for a regular boot option, and that should include
>>>>>>> signaling the ReadyToBoot event.
>>>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed
>>>>>> your cover letter for this patch.  I was just thinking that we may
>>>>>> not really need to make this behavior change in both EDK II code
>>>>>> and UEFI specification for solving the problem specific to the
>>>>>> case that OS is loaded by "Default PlatformRecovery" option,
>>>>>
>>>>> The way I see it is that the Pi platform is unlikely to be the only
>>>>> one where PlatformRecovery is seen as a means to install an OS.
>>>>> Granted, this may seem like abusing the option, but since UEFI
>>>>> doesn't provide an "Initial OS Install" mode, I would assert that
>>>>> it as good a use of this option as any.
>>>>>
>>>>> In other words, I don't think this improvement would only benefit
>>>>> the Pi platform.
>>>>>
>>>>>> and I'm also not sure if it is worth making this change to affect
>>>>>> some of the system or BIOS vendors who have implemented their
>>>>>> PlatformRecovery option.
>>>>>
>>>>> That's a legitimate concern, and I would agree the one major
>>>>> potential pitfall of this proposal, if there happens to exist a
>>>>> system where an OnReadyToBoot even before running the recovery
>>>>> option can have adverse effects.
>>>>>
>>>>> I don't really believe that such a system exists, because I expect
>>>>> most recovery boot loaders to also work (or at least have been
>>>>> designed to
>>>>> work) as regular boot options. But I don't have enough experience
>>>>> with platform recovery to know if that's a correct assertion to make...
>>>>>
>>>>>> If the alternative approach I mentioned works for you, I think
>>>>>> that would be an easier solution.
>>>>>
>>>>> Right now, even as the patch proposal has multiple issues that
>>>>> require it to be amended (Don't signal ReadyToBoot except for
>>>>> PlatformRecovery
>>>>> + Prevent situations where ReadyToBoot could be signalled multiple
>>>>> times) I still see it as both an easier solution than the
>>>>> alternative, as well as one that *should* benefit people who design
>>>>> Platform Recovery UEFI applications in the long run. So that is why
>>>>> I am still trying to advocate for it.
>>>>>
>>>>> But I very much hear your concerns, and I agree that specs changes
>>>>> are better avoided when possible.
>>>>>
>>>>> Thus, at this stage, even as I don't want to drag this discussion
>>>>> much further, I don't feel like I want to commit to one solution or
>>>>> the other before we have had a chance to hear other people, who may
>>>>> have their own opinion on the matter, express their views.
>>>>>
>>>>> Regards,
>>>>>
>>>>> /Pete
>>>>>
>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Sunny Wang
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Pete Batard [mailto:pete@akeo.ie]
>>>>>> Sent: Wednesday, June 17, 2020 6:59 PM
>>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
>>>>>> mailto:devel@edk2.groups.io
>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
>>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>>> recovery
>>>>>>
>>>>>> Hi Sunny, thanks for looking into this.
>>>>>>
>>>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
>>>>>>> Hi Pete.
>>>>>>>
>>>>>>> Since the EfiBootManagerProcessLoadOption is called by
>>>>>>> ProcessLoadOptions as well, your change would also cause some
>>>>>>> unexpected behavior like:
>>>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option
>>>>>>> which is an application that calls EfiBootManagerBoot() to launch
>>>>>>> its recovered boot option.
>>>>>>
>>>>>> I'm not sure I understand how this part is unwanted.
>>>>>>
>>>>>> The point of this patch is to ensure that ReadyToBoot is signalled
>>>>>> for the PlatformRecovery option, so isn't what you describe above
>>>>>> exactly what we want?
>>>>>>
>>>>>> Or is the "one more" the issue, meaning that it would get
>>>>>> signalled more than once?
>>>>>>
>>>>>>
>>>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not
>>>>>>> really a "boot" option.
>>>>>>
>>>>>> Yes, I've been wondering about that, because BdsEntry.c's
>>>>>> ProcessLoadOptions(), which calls
>>>>>> EfiBootManagerProcessLoadOption(),
>>>>>> mentions that it will load will load and start every Driver####,
>>>>>> SysPrep#### or PlatformRecovery####. But the comment about the
>>>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions
>>>>>> PlatformRecovery####.
>>>>>>
>>>>>> If needed, I guess we could amend the patch to detect the type of
>>>>>> option and only signal ReadyToBoot for PlatformRecovery####.
>>>>>>
>>>>>>> To solve your problem, creating a PlatformRecovery option with
>>>>>>> the smallest option number and using it instead of default one
>>>>>>> (with short-form File Path Media Device Path) looks like a
>>>>>>> simpler solution.
>>>>>>
>>>>>> I don't mind trying an alternative approach, but I don't
>>>>>> understand how what you describe would help. Can you please be
>>>>>> more specific about what you have in mind?
>>>>>>
>>>>>> Our main issue here is that we must have ReadyToBoot signalled so
>>>>>> that the ReadyToBoot() function callback from
>>>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for the
>>>>>> boot loader invoked from PlatformRecovery####  to use a properly
>>>>>> initialized graphical console. So I'm not sure I quite get how
>>>>>> switching from one PlatformRecovery#### option to another would
>>>>>> improve things.
>>>>>>
>>>>>> If it helps, here is what we currently default to, in terms of
>>>>>> boot options, on a Raspberry Pi 4 platform with a newly build firmware:
>>>>>>
>>>>>> [Bds]=============Begin Load Options Dumping ...=============
>>>>>>        Driver Options:
>>>>>>        SysPrep Options:
>>>>>>        Boot Options:
>>>>>>          Boot0000: UiApp              0x0109
>>>>>>          Boot0001: UEFI Shell                 0x0000
>>>>>>        PlatformRecovery Options:
>>>>>>          PlatformRecovery0000: Default PlatformRecovery
>>>>>> 0x0001 [Bds]=============End Load Options Dumping=============
>>>>>>
>>>>>> With this, PlatformRecovery0000 gets executed by default, which is
>>>>>> what we want, since it will pick /efi/boot/bootaa64.efi from
>>>>>> either SD or USB and run it, the only issue being that, because
>>>>>> ReadyToBoot has not been executed, the graphical console is not
>>>>>> operative so users can't interact with the OS installer.
>>>>>>
>>>>>> So I'm really not sure how adding an extra PlatformRecovery####
>>>>>> would help. And I'm also not too familiar with how one would go
>>>>>> around to add such an entry...
>>>>>>
>>>>>>> By the way, I also checked the UEFI specification. It looks
>>>>>>> making sense to only signal ReadyToBoot for boot option (Boot####).
>>>>>>
>>>>>> That's something I considered too, but I disagree with this
>>>>>> conclusion.
>>>>>>
>>>>>> My reasoning is that, if PlatformRecovery#### can execute a
>>>>>> regular bootloader like /efi/boot/boot####.efi from installation
>>>>>> media, then it should go through the same kind of initialization
>>>>>> that happens for a regular boot option, and that should include
>>>>>> signalling the ReadyToBoot event.
>>>>>>
>>>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
>>>>>> /efi/boot/recovery####.efi) then I would agree with only
>>>>>> signalling ReadyToBoot for a formal Boot#### option. But that
>>>>>> isn't the case, so I think it is reasonable to want to have
>>>>>> ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is
>>>>>> executed from PlatformRecovery####., especially when we know it
>>>>>> can be crucial to ensuring that the end user can actually use the graphical console.
>>>>>>
>>>>>>> Therefore, your change may also require specification change.
>>>>>>
>>>>>> Yes, I mentioned that in the cover letter for this patch
>>>>>> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2
>>>>>> Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%7Ca
>>>>>> warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb39138
>>>>>> ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdata=
>>>>>> 2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;reserved=0
>>>>>> ), which also describes the issue we are trying to solve in
>>>>>> greater details. This is what I wrote:
>>>>>>
>>>>>> ------------------------------------------------------------------
>>>>>> ------
>>>>>>
>>>>>> Note however that this may require a specs update, as the current
>>>>>> UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
>>>>>>
>>>>>>      >  EFI_EVENT_GROUP_READY_TO_BOOT
>>>>>>      >    This event group is notified by the system when the Boot
>>>>>> Manager
>>>>>>      >    is about to load and execute a boot option.
>>>>>>
>>>>>> and, once this patch has been applied, we may want to update this
>>>>>> section to mention that it applies to both Boot Manager and
>>>>>> Platform Recovery.
>>>>>> ------------------------------------------------------------------
>>>>>> ------
>>>>>>
>>>>>>
>>>>>>
>>>>>> Again, I don't have an issue with trying to use an alternate
>>>>>> approach to solve our problem (though I ultimately believe that,
>>>>>> if PlatformRecovery#### can launch a /efi/boot/boot####.efi
>>>>>> bootloader then we must update the specs and the code to have
>>>>>> ReadyToBoot also signalled then, because that's the logical thing
>>>>>> to do). But right now, I'm not seeing how to achieve that when
>>>>>> PlatformRecovery#### is the option that is used to launch the OS
>>>>>> installation the bootloader. So if you can provide mode details on
>>>>>> how exactly you think creating an alternate PlatformRecovery
>>>>>> option would help, I would appreciate it.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> /Pete
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sunny Wang
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io]
>>>>>>> On Behalf Of Pete Batard
>>>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
>>>>>>> To: mailto:devel@edk2.groups.io
>>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
>>>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
>>>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
>>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
>>>>>>> recovery
>>>>>>>
>>>>>>> Currently, the ReadyToBoot event is only signaled when a formal
>>>>>>> Boot Manager option is executed (in BmBoot.c ->
>>>>>>> EfiBootManagerBoot ()).
>>>>>>>
>>>>>>> However, with the introduction of Platform Recovery in UEFI 2.5,
>>>>>>> which may lead to the execution of a boot loader that has similar
>>>>>>> requirements to a regular one, yet is not launched as a Boot
>>>>>>> Manager option, it also becomes necessary to signal ReadyToBoot
>>>>>>> when a Platform Recovery boot loader runs.
>>>>>>>
>>>>>>> Especially, this can be critical to ensuring that the graphical
>>>>>>> console is actually usable during platform recovery, as some
>>>>>>> platforms do rely on the ConsolePrefDxe driver, which only
>>>>>>> performs console initialization after ReadyToBoot is triggered.
>>>>>>>
>>>>>>> This patch fixes that behaviour by calling
>>>>>>> EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption
>>>>>>> (), which is the function that sets up the platform recovery boot
>>>>>>> process.
>>>>>>>
>>>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
>>>>>>> ---
>>>>>>>       MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c | 9
>>>>>>> +++++++++
>>>>>>>       1 file changed, 9 insertions(+)
>>>>>>>
>>>>>>> diff --git
>>>>>>> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>>> index 89372b3b97b8..117f1f5b124c 100644
>>>>>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>>> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
>>>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
>>>>>>>           return EFI_SUCCESS;
>>>>>>>         }
>>>>>>>
>>>>>>> +  //
>>>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
>>>>>>> to load and execute the boot option.
>>>>>>> +  //
>>>>>>> +  EfiSignalEventReadyToBoot ();
>>>>>>> +  //
>>>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled
>>>>>>> +//  REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
>>>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
>>>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
>>>>>>> +
>>>>>>>         //
>>>>>>>         // Load and start the load option.
>>>>>>>         //
>>>>>>> --
>>>>>>> 2.21.0.windows.1
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments
>>>>> are confidential and may also be privileged. If you are not the
>>>>> intended recipient, please notify the sender immediately and do not
>>>>> disclose the contents to any other person, use it for any purpose,
>>>>> or store or copy the information in any medium. Thank you.
>>>>>
>>>>> IMPORTANT NOTICE: The contents of this email and any attachments
>>>>> are confidential and may also be privileged. If you are not the
>>>>> intended recipient, please notify the sender immediately and do not
>>>>> disclose the contents to any other person, use it for any purpose,
>>>>> or store or copy the information in any medium. Thank you.
>>>>>
>>>>
>>>>
>>>> 
>>>>
>>
> 

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

In order to make progress on this, I opened a code-first ECR  against the UEFI spec to clarify the language around the Boot#### options processing.

Code First ECR: https://bugzilla.tianocore.org/show_bug.cgi?id=3336

Feedback on the proposed language is appreciated. Please provide the feedback directly in the BZ above.

I will update the thread/BZ with results from USWG.

Thanks,
--Samer

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pete
> Batard via groups.io
> Sent: Thursday, February 25, 2021 5:55 AM
> To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Laszlo Ersek
> <lersek@redhat.com>; Leif Lindholm <leif@nuviainc.com>;
> devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>; zhichao.gao@intel.com
> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
> Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Ard
> Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish <afish@apple.com>;
> Michael D Kinney <michael.d.kinney@intel.com>; Jian J Wang
> <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>;
> Sunny.Hsuanwen.Wang@gmail.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> Hi Sunny,
>
> I appreciate the input, but seeing that it is clear that no consensus has been
> reached with regards to how the specs should be interpreted, and that at
> least 4 separate people have now indicated that their interpretation is
> different from the one you are putting forward (i.e.
> you assert that the current code implementation is specs compliant whereas
> we assert that the current code implementation is not specs compliant), I
> believe that any further work on this will have to be conditioned, first, by a
> specs update, that removes any ambiguity as to the scope in which
> ReadyToBoot should apply.
>
> Until that has happened, it seems very pointless to me to start talking
> possible code workarounds, because we still can't appear to be in agreement
> as to whether the current code implementation of ReadyToBoot is specs
> compliant or not.
>
> Now, even as I am the one proposing it, I'm afraid that I am not planning to
> be the one opening a formal specs update request, since there really is only
> so much more time I am willing to devote to this matter. But I am hoping
> somebody else will.
>
> Regards,
>
> /Pete
>
> On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
> > Hi all,
> >
> > How about we signal ReadyToBoot ONLY for the default platform recovery
> option?  The default platform recovery option here means the one created
> by the code below in BdsEntry().
> >    Status = EfiBootManagerInitializeLoadOption (
> >               &PlatformDefaultBootOption,
> >               LoadOptionNumberUnassigned,
> >               LoadOptionTypePlatformRecovery,
> >               LOAD_OPTION_ACTIVE,
> >               L"Default PlatformRecovery",
> >               FilePath,
> >               NULL,
> >               0
> >               );
> >
> > In other words, we just need to slightly update Pete's patch as the
> following (adding the code below to EfiBootManagerProcessLoadOption()):
> >
> > +   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery) &&
> >            StrCmp (LoadOption ->Description, L"Default
> > PlatformRecovery")) {
> > +    //
> > +    // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
> to load and execute the boot option.
> > +    //
> > +    EfiSignalEventReadyToBoot ();
> >
> > +    //
> > +    // Report Status Code to indicate ReadyToBoot was signalled
> > +    //
> > +    REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> > + (EFI_SOFTWARE_DXE_BS_DRIVER |
> > + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > +  }
> >
> > I think the existing platforms that have their platform-specific
> PlatformRecovery option may also do either of the following things to make
> the system have no chance to load the default platform recovery option
> because they do have a better way to recover the boot options:
> >      1. Make their PlatformRecovery option have higher priority than the
> default platform recovery option (has a lower number (####) than the
> default platform recovery option)
> >      2. Remove the default platform recovery option.
> > Therefore, if we only signal ReadyToBoot for the default platform recovery
> option, this may not affect the existing platforms because the code may
> never be run on these platforms.
> >
> >
> >
> >
> >
> > If the solution above doesn't work, I think the suggestion (Solution 2:
> adding a new application as a PlatformRecovery####) I mentioned, in the
> beginning, can be re-considered. The suggestion (solution 2) is based on the
> thoughts below:
> >       1.  I think that processing/evaluating the Boot#### can be interpreted as
> the code after the comment " 6. Load EFI boot option to ImageHandle" in
> EfiBootManagerBoot() because these code are similar to the code in
> EfiBootManagerProcessLoadOption(). Based on this, I think our current
> implementation is compliant with the description below in the UEFI spec. Of
> course, we can improve our implementation by moving the code for
> processing/evaluating the Boot#### from EfiBootManagerBoot() to
> EfiBootManagerProcessLoadOption() and make EfiBootManagerBoot() call
> EfiBootManagerProcessLoadOption().
> >                “After all SysPrep#### variables have been launched and exited,
> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event group
> and begin to evaluate Boot#### variables with Attributes set to
> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
> BootOrder. The FilePathList of variables marked
> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing."
> >       2. Moreover, it looks like we want to process PlatformRecovery####
> option in the same way as Boot#### (do more things like setting BootCurrent
> for PlatformRecovery####). If so, I would still prefer to do what I suggest in
> the beginning to create a new application as a new PlatformRecovery####
> option for generating and launching a boot option for the bootable image
> that is found by using a short-form File Path Media Device Path so that we
> won't run into other difficulties. At least, I already saw the difficulty of no
> connection between BootCurrent variable and PlatformRecovery####
> variable. Of course, this application can be implemented without platform
> specific stuff, so it can be commonly used by all platforms that need to load a
> boot image discovered by using short-form File Path Media Device Path.
> >
> >
> >
> >
> > Regards,
> > Sunny Wang
> >
> > -----Original Message-----
> > From: Laszlo Ersek <lersek@redhat.com>
> > Sent: Wednesday, February 17, 2021 10:26 PM
> > To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>;
> > devel@edk2.groups.io
> > Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
> > Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>;
> Wang, Sunny
> > (HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com;
> ray.ni@intel.com;
> > Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish
> > <afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>; Jian
> > J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
> > Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1]
> > MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> > recovery
> >
> > On 02/17/21 13:18, Pete Batard wrote:
> >> Hi Leif,
> >>
> >> Thanks for trying to resurrect this issue.
> >>
> >> At this stage, and despite some initial pushback in the bugzilla
> >> ticket, I believe we can all agree with the consensus that
> >> UefiBootManagerLib is not in fact specs-compliant and therefore needs
> >> to be fixed, one way or another, to make it specs-compliant.
> >>
> >> My take on this is that, rather than propose a new patch, I'd much
> >> rather have the current maintainers agree on the course of action to
> >> fix the library (which, as Leif suggests, might very well be to split
> >> the library into a specs-compliant and non-specs-compliant version),
> >> as it would of course be better if the fix came from people who have
> >> better understanding of the ramifications we might face with trying
> >> to correct the current behaviour, and especially, who have knowledge
> >> of the platforms that might be impacted from making the lib specs-
> compliant.
> >>
> >> Especially, I don't think that the patch that I originally submitted
> >> for this, or the additional proposals we made, are still receivable,
> >> as they seem to fall short of fixing the issue in a manner that all
> >> platforms can be happy with. And that is why I'd like to hear from
> >> the maintainers on what their preferred approach would be.
> >
> > A new Feature PCD could satisfy both sets of platforms, could it not?
> >
> > (Sorry if the original patch already had such a PCD; I don't
> > remember.)
> >
> > Of course then we'd have a debate around the DEC default for the new
> > PCD
> > -- I'd say the default value of the PCD should match the spec-mandated
> behavior.
> >
> > I don't recall any specifics, but a bug-compat pattern that's sometimes used
> is this:
> >
> >    if (BugCompatEnabled) {
> >      //
> >      // do the right thing in the wrong place, for legacy platforms' sake
> >      //
> >     Foo ();
> >    }
> >
> >    //
> >    // Do some stuff.
> >    //
> >    Bar ();
> >
> >    if (!BugCompatEnabled) {
> >      //
> >      // do the right thing in the right place, for conformant platforms
> >      //
> >     Foo ();
> >    }
> >
> > Not sure if it applies here.
> >
> > Thanks
> > Laszlo
> >
> >
> >> On 2021.02.17 11:42, Leif Lindholm wrote:
> >>> Hi Pete, +various
> >>>
> >>> Resurrecting this old thread since Ard pointed out an issue I ran
> >>> into myself had already been encountered by Pete.
> >>> And the bugzilla ticket (directly below this reply) has had no
> >>> relevant progress since August.
> >>>
> >>> Executive summary:
> >>> The current UefiBootManagerLib implementation of the
> >>> PlatformRecovery path does not notify the
> EFI_EVENT_GROUP_READY_TO_BOOT event.
> >>>
> >>> The argument has been made that since changing this would affect an
> >>> unnamed number of non-public platforms, the behaviour cannot be
> >>> changed even though it violates the UEFI specification.
> >>>
> >>> I disagree with that statement. If we want to fork
> >>> UefiBootManagerLib into a BrokenLegacyUefiBootManagerLib and an
> >>> actually correct one, and have those platforms move to the
> >>> BrokenLegacy variant, I'm OK with that.
> >>>
> >>> But using the default version should give specification-compliant
> >>> behaviour.
> >>>
> >>> /
> >>>       Leif
> >>>
> >>> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
> >>>> Please note that I have created a bug report
> >>>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address
> >>>> the non-compliance issue was raised during the course of the
> >>>> discussion below.
> >>>>
> >>>> Regards,
> >>>>
> >>>> /Pete
> >>>>
> >>>>
> >>>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
> >>>>> I worked with Pete offline on this..
> >>>>>
> >>>>> This code seems to be violating the UEFI Spec:
> >>>>>
> >>>>>
> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64d
> >>>>> e
> >>>>>
> 7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L176
> >>>>> 3
> >>>>>
> >>>>>
> >>>>>      //
> >>>>>      // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> >>>>> about to load and execute
> >>>>>      //    the boot option.
> >>>>>      //
> >>>>>      if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
> >>>>>        DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
> >>>>>        BmStopHotkeyService (NULL, NULL);
> >>>>>      } else {
> >>>>>        EfiSignalEventReadyToBoot();
> >>>>>        //
> >>>>>        // Report Status Code to indicate ReadyToBoot was signalled
> >>>>>        //
> >>>>>        REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> >>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> >>>>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >>>>>        //
> >>>>>        // 4. Repair system through DriverHealth protocol
> >>>>>        //
> >>>>>        BmRepairAllControllers (0);
> >>>>>      }
> >>>>>
> >>>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and
> >>>>> their FilePathList) *shall not* be evaluated prior to the
> >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing:
> >>>>>
> >>>>> "After all SysPrep#### variables have been launched and exited,
> >>>>> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
> >>>>> group and begin to evaluate Boot#### variables with Attributes set
> >>>>> to LOAD_OPTION_CATEGORY_BOOT according to the order defined
> by
> >>>>> BootOrder. The FilePathList of variables marked
> >>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
> >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing."
> >>>>>
> >>>>> This is a prescriptive language that is stronger than the language
> >>>>> in section 7.1 which defines the ReadyToBoot event group in a
> >>>>> general way:
> >>>>>
> >>>>> "EFI_EVENT_GROUP_RESET_SYSTEM
> >>>>> This event group is notified by the system when ResetSystem() is
> >>>>> invoked and the system is about to be reset. The event group is
> >>>>> only notified prior to ExitBootServices() invocation."
> >>>>>
> >>>>> The EDK2 code in the else block above (to call
> >>>>> EfiSignalEventReadyToBoot() ) need to move before the code that is
> >>>>> processing BootOption->FilePath. In fact, why is this signaling
> >>>>> even a BootManager task? It should be a higher level BDS task
> >>>>> (after processing SysPrp and before processing Boot options, per the
> spec).
> >>>>> This would be somewhere around
> >>>>>
> https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea02
> >>>>> 1
> >>>>> 4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
> >>>>> where SysPrep is processed.
> >>>>>
> >>>>> This should also take care of the issue Pete reported in this
> >>>>> thread, without the need for explicitly signaling ReadyToBoot from
> >>>>> PlatformRecovery (or changing the UEFI spec).
> >>>>>
> >>>>> Thanks,
> >>>>> --Samer
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> >>>>> Samer El-Haj-Mahmoud via groups.io
> >>>>> Sent: Wednesday, June 17, 2020 12:42 PM
> >>>>> To: devel@edk2.groups.io; Andrei Warkentin
> (awarkentin@vmware.com)
> >>>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW)
> <sunnywang@hpe.com>;
> >>>>> pete@akeo.ie
> >>>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
> >>>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-
> Mahmoud
> >>>>> <Samer.El-Haj-Mahmoud@arm.com>
> >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>> recovery
> >>>>>
> >>>>> The UEFI spec (3.1.7) says:
> >>>>>
> >>>>> "After all SysPrep#### variables have been launched and exited,
> >>>>> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
> >>>>> group and begin to evaluate Boot#### variables with Attributes set
> >>>>> to LOAD_OPTION_CATEGORY_BOOT according to the order defined
> by
> >>>>> BootOrder. The FilePathList of variables marked
> >>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
> >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing."
> >>>>>
> >>>>> The way I read this, I expect ReadyToBoot to be signaled after
> >>>>> SysPrep#### (if any) are processed, but before Boot#### are
> >>>>> processed. Is my understanding correct that this language implies
> >>>>> ReadyToBoot need to be signaled even if BootOrder does not contain
> >>>>> any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT?
> And if
> >>>>> so, is EDK2 not doing this, which leads us to this patch
> >>>>> (signaling it in PlatformRecovery?)
> >>>>>
> >>>>>
> >>>>>
> >>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> On
> >>>>> Behalf Of Andrei Warkentin via groups.io
> >>>>> Sent: Wednesday, June 17, 2020 12:37 PM
> >>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
> >>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
> >>>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>;
> >>>>> mailto:leif@nuviainc.com
> >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>> recovery
> >>>>>
> >>>>> Thanks Pete.
> >>>>>
> >>>>> I think the question I have, that I hope Tiano veterans can chime
> >>>>> in, is whether we are doing the right thing, or if we should be
> >>>>> overriding the boot mode? I.e. is it normal that we boot up in
> >>>>> recovery until options are saved?
> >>>>>
> >>>>>
> >>>>> A
> >>>>>
> >>>>>
> >>>>> ________________________________________
> >>>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> on
> >>>>> behalf of Pete Batard via groups.io
> >>>>> <mailto:pete=akeo.ie@groups.io>
> >>>>> Sent: Wednesday, June 17, 2020 11:34 AM
> >>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
> >>>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
> >>>>> mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>;
> >>>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
> >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>> recovery
> >>>>>
> >>>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> >>>>>> Thanks for checking my comments, Pete.
> >>>>>>
> >>>>>>> Or is the "one more" the issue, meaning that it would get
> >>>>>>> signaled more than once?
> >>>>>> [Sunny] Yeah, it would get signaled more than once if the
> >>>>>> PlatformRecovery option (a UEFI application) calls
> >>>>>> EfiBootManagerBoot() to launch the recovered boot option inside
> >>>>>> of the application.
> >>>>>
> >>>>> Okay.
> >>>>>
> >>>>> One element that I'm going to point out is that, with the current
> >>>>> EDK2 code (i.e. without this proposal applied), and after a user
> >>>>> goes into the setup to save their boot options in order for
> >>>>> regular boot options to get executed instead of PlaformRecovery,
> >>>>> the OnReadyToBoot event is actually called twice.
> >>>>>
> >>>>> So my understanding is that, while we of course want to avoid this
> >>>>> and any patch proposal should actively try to prevent it, it seems
> >>>>> we already have behaviour in EDK2 that can lead to OnReadyToBoot
> >>>>> being signalled more than once.
> >>>>>
> >>>>> At least the current Pi 4 platform does demonstrate this behaviour.
> >>>>> For instance, if you run DEBUG, you will see two instances of:
> >>>>>
> >>>>>       RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> >>>>>
> >>>>> which is a one-instance message generated from the
> >>>>> ConsolePrefDxe's
> >>>>> OnReadyToBoot() call. I've also confirmed more specifically that
> >>>>> OnReadyToBoot() is indeed called twice.
> >>>>>
> >>>>> I don't recall us doing much of any special with regards to boot
> >>>>> options for the Pi platform, so my guess is that it's probably not
> >>>>> the only platform where OnReadyToBoot might be signalled more
> than
> >>>>> once, and that this might be tied to a default EDK2 behaviour.
> >>>>> Therefore I don't see having a repeated event as a major deal
> >>>>> breaker (though, again, if we can avoid that, we of course will
> >>>>> want to).
> >>>>>
> >>>>>>> I don't mind trying an alternative approach, but I don't
> >>>>>>> understand how what you describe would help. Can you please be
> >>>>>>> more specific about what you have in mind?
> >>>>>> [Sunny] Sure. I added more information below. If it is still not
> >>>>>> clear enough, feel free to let me know.
> >>>>>>          1. Create a UEFI application with the code to signal
> >>>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB
> >>>>>> and run it.
> >>>>>
> >>>>> So that would basically be adding code that duplicates, in part,
> >>>>> what Platform Recovery already does.
> >>>>>
> >>>>> I have to be honest: Even outside of the extra work this would
> >>>>> require, I don't really like the idea of having to write our own
> >>>>> application, as it will introduce new possible points of failures
> >>>>> and require extra maintenance (especially as we will want to be
> >>>>> able to handle network boot and other options, and before long, I
> >>>>> fear that we're going to have to write our own Pi specific boot
> >>>>> manager). Doing so simply because the current Platform Recovery,
> >>>>> which does suit our needs otherwise, is not designed to call
> >>>>> ReadyToBoot does not seem like the best course of action in my
> >>>>> book.
> >>>>>
> >>>>> Instead, I still logically believe that any option that calls a
> >>>>> boot loader should signal ReadyToBoot, regardless of whether it
> >>>>> was launched from Boot Manager or Platform Recovery, and that it
> >>>>> shouldn't be left to each platform to work around that.
> >>>>>
> >>>>> Of course, I understand that this would require a specs change,
> >>>>> and that it also may have ramifications for existing platforms
> >>>>> that interpret the current specs pedantically. But to me,
> >>>>> regardless of what the specs appear to be limiting it to right
> >>>>> now, the logic of a "ReadyToBoot"
> >>>>> event is that it should be signalled whenever a bootloader is
> >>>>> about to be executed, rather than only when a bootloader happened
> >>>>> to be launched through a formal Boot Manager option.
> >>>>>
> >>>>> I would therefore appreciate if other people could weigh in on
> >>>>> this matter, to see if I'm the only one who believes that we could
> >>>>> ultimately have more to gain from signalling ReadyToBoot with
> >>>>> PlatformRecovery options than leaving things as they stand right
> >>>>> now...
> >>>>>
> >>>>>>          2. Then, call EfiBootManagerInitializeLoadOption like
> >>>>>> the following in a DXE driver or other places before "Default
> >>>>>> PlatformRecovery" registration:
> >>>>>>       Status = EfiBootManagerInitializeLoadOption (
> >>>>>>                  &LoadOption,
> >>>>>>
> >>>>>> 0,
> >>>>>> -> 0 is the OptionNumber to let application be load before "
> >>>>>> Default PlatformRecovery" option
> >>>>>>                  LoadOptionTypePlatformRecovery,
> >>>>>>                  LOAD_OPTION_ACTIVE,
> >>>>>>                  L"Application for recovering boot options",
> >>>>>>
> >>>>>> FilePath,
> >>>>>> -> FilePath is the Application's device path,
> >>>>>>                  NULL,
> >>>>>>                  0
> >>>>>>                  );
> >>>>>>
> >>>>>>
> >>>>>>> My reasoning is that, if PlatformRecovery#### can execute a
> >>>>>>> regular bootloader like /efi/boot/boot####.efi from installation
> >>>>>>> media, then it should go through the same kind of initialization
> >>>>>>> that happens for a regular boot option, and that should include
> >>>>>>> signaling the ReadyToBoot event.
> >>>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed
> >>>>>> your cover letter for this patch.  I was just thinking that we
> >>>>>> may not really need to make this behavior change in both EDK II
> >>>>>> code and UEFI specification for solving the problem specific to
> >>>>>> the case that OS is loaded by "Default PlatformRecovery" option,
> >>>>>
> >>>>> The way I see it is that the Pi platform is unlikely to be the
> >>>>> only one where PlatformRecovery is seen as a means to install an OS.
> >>>>> Granted, this may seem like abusing the option, but since UEFI
> >>>>> doesn't provide an "Initial OS Install" mode, I would assert that
> >>>>> it as good a use of this option as any.
> >>>>>
> >>>>> In other words, I don't think this improvement would only benefit
> >>>>> the Pi platform.
> >>>>>
> >>>>>> and I'm also not sure if it is worth making this change to affect
> >>>>>> some of the system or BIOS vendors who have implemented their
> >>>>>> PlatformRecovery option.
> >>>>>
> >>>>> That's a legitimate concern, and I would agree the one major
> >>>>> potential pitfall of this proposal, if there happens to exist a
> >>>>> system where an OnReadyToBoot even before running the recovery
> >>>>> option can have adverse effects.
> >>>>>
> >>>>> I don't really believe that such a system exists, because I expect
> >>>>> most recovery boot loaders to also work (or at least have been
> >>>>> designed to
> >>>>> work) as regular boot options. But I don't have enough experience
> >>>>> with platform recovery to know if that's a correct assertion to make...
> >>>>>
> >>>>>> If the alternative approach I mentioned works for you, I think
> >>>>>> that would be an easier solution.
> >>>>>
> >>>>> Right now, even as the patch proposal has multiple issues that
> >>>>> require it to be amended (Don't signal ReadyToBoot except for
> >>>>> PlatformRecovery
> >>>>> + Prevent situations where ReadyToBoot could be signalled multiple
> >>>>> times) I still see it as both an easier solution than the
> >>>>> alternative, as well as one that *should* benefit people who
> >>>>> design Platform Recovery UEFI applications in the long run. So
> >>>>> that is why I am still trying to advocate for it.
> >>>>>
> >>>>> But I very much hear your concerns, and I agree that specs changes
> >>>>> are better avoided when possible.
> >>>>>
> >>>>> Thus, at this stage, even as I don't want to drag this discussion
> >>>>> much further, I don't feel like I want to commit to one solution
> >>>>> or the other before we have had a chance to hear other people, who
> >>>>> may have their own opinion on the matter, express their views.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> /Pete
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Sunny Wang
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Pete Batard [mailto:pete@akeo.ie]
> >>>>>> Sent: Wednesday, June 17, 2020 6:59 PM
> >>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>>>> mailto:devel@edk2.groups.io
> >>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> >>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> >>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>>> recovery
> >>>>>>
> >>>>>> Hi Sunny, thanks for looking into this.
> >>>>>>
> >>>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> >>>>>>> Hi Pete.
> >>>>>>>
> >>>>>>> Since the EfiBootManagerProcessLoadOption is called by
> >>>>>>> ProcessLoadOptions as well, your change would also cause some
> >>>>>>> unexpected behavior like:
> >>>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option
> >>>>>>> which is an application that calls EfiBootManagerBoot() to
> >>>>>>> launch its recovered boot option.
> >>>>>>
> >>>>>> I'm not sure I understand how this part is unwanted.
> >>>>>>
> >>>>>> The point of this patch is to ensure that ReadyToBoot is
> >>>>>> signalled for the PlatformRecovery option, so isn't what you
> >>>>>> describe above exactly what we want?
> >>>>>>
> >>>>>> Or is the "one more" the issue, meaning that it would get
> >>>>>> signalled more than once?
> >>>>>>
> >>>>>>
> >>>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not
> >>>>>>> really a "boot" option.
> >>>>>>
> >>>>>> Yes, I've been wondering about that, because BdsEntry.c's
> >>>>>> ProcessLoadOptions(), which calls
> >>>>>> EfiBootManagerProcessLoadOption(),
> >>>>>> mentions that it will load will load and start every Driver####,
> >>>>>> SysPrep#### or PlatformRecovery####. But the comment about the
> >>>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions
> >>>>>> PlatformRecovery####.
> >>>>>>
> >>>>>> If needed, I guess we could amend the patch to detect the type of
> >>>>>> option and only signal ReadyToBoot for PlatformRecovery####.
> >>>>>>
> >>>>>>> To solve your problem, creating a PlatformRecovery option with
> >>>>>>> the smallest option number and using it instead of default one
> >>>>>>> (with short-form File Path Media Device Path) looks like a
> >>>>>>> simpler solution.
> >>>>>>
> >>>>>> I don't mind trying an alternative approach, but I don't
> >>>>>> understand how what you describe would help. Can you please be
> >>>>>> more specific about what you have in mind?
> >>>>>>
> >>>>>> Our main issue here is that we must have ReadyToBoot signalled so
> >>>>>> that the ReadyToBoot() function callback from
> >>>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for
> the
> >>>>>> boot loader invoked from PlatformRecovery####  to use a properly
> >>>>>> initialized graphical console. So I'm not sure I quite get how
> >>>>>> switching from one PlatformRecovery#### option to another would
> >>>>>> improve things.
> >>>>>>
> >>>>>> If it helps, here is what we currently default to, in terms of
> >>>>>> boot options, on a Raspberry Pi 4 platform with a newly build
> firmware:
> >>>>>>
> >>>>>> [Bds]=============Begin Load Options Dumping
> ...=============
> >>>>>>        Driver Options:
> >>>>>>        SysPrep Options:
> >>>>>>        Boot Options:
> >>>>>>          Boot0000: UiApp              0x0109
> >>>>>>          Boot0001: UEFI Shell                 0x0000
> >>>>>>        PlatformRecovery Options:
> >>>>>>          PlatformRecovery0000: Default PlatformRecovery
> >>>>>> 0x0001 [Bds]=============End Load Options
> Dumping=============
> >>>>>>
> >>>>>> With this, PlatformRecovery0000 gets executed by default, which
> >>>>>> is what we want, since it will pick /efi/boot/bootaa64.efi from
> >>>>>> either SD or USB and run it, the only issue being that, because
> >>>>>> ReadyToBoot has not been executed, the graphical console is not
> >>>>>> operative so users can't interact with the OS installer.
> >>>>>>
> >>>>>> So I'm really not sure how adding an extra PlatformRecovery####
> >>>>>> would help. And I'm also not too familiar with how one would go
> >>>>>> around to add such an entry...
> >>>>>>
> >>>>>>> By the way, I also checked the UEFI specification. It looks
> >>>>>>> making sense to only signal ReadyToBoot for boot option
> (Boot####).
> >>>>>>
> >>>>>> That's something I considered too, but I disagree with this
> >>>>>> conclusion.
> >>>>>>
> >>>>>> My reasoning is that, if PlatformRecovery#### can execute a
> >>>>>> regular bootloader like /efi/boot/boot####.efi from installation
> >>>>>> media, then it should go through the same kind of initialization
> >>>>>> that happens for a regular boot option, and that should include
> >>>>>> signalling the ReadyToBoot event.
> >>>>>>
> >>>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
> >>>>>> /efi/boot/recovery####.efi) then I would agree with only
> >>>>>> signalling ReadyToBoot for a formal Boot#### option. But that
> >>>>>> isn't the case, so I think it is reasonable to want to have
> >>>>>> ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader
> >>>>>> is executed from PlatformRecovery####., especially when we know
> >>>>>> it can be crucial to ensuring that the end user can actually use the
> graphical console.
> >>>>>>
> >>>>>>> Therefore, your change may also require specification change.
> >>>>>>
> >>>>>> Yes, I mentioned that in the cover letter for this patch
> >>>>>>
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%
> >>>>>> 2
> >>>>>>
> Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%
> 7C
> >>>>>> a
> >>>>>>
> warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb391
> 3
> >>>>>> 8
> >>>>>>
> ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdat
> a
> >>>>>> =
> >>>>>>
> 2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;res
> erved=0
> >>>>>> ), which also describes the issue we are trying to solve in
> >>>>>> greater details. This is what I wrote:
> >>>>>>
> >>>>>> -----------------------------------------------------------------
> >>>>>> -
> >>>>>> ------
> >>>>>>
> >>>>>> Note however that this may require a specs update, as the current
> >>>>>> UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
> >>>>>>
> >>>>>>      >  EFI_EVENT_GROUP_READY_TO_BOOT
> >>>>>>      >    This event group is notified by the system when the
> >>>>>> Boot Manager
> >>>>>>      >    is about to load and execute a boot option.
> >>>>>>
> >>>>>> and, once this patch has been applied, we may want to update this
> >>>>>> section to mention that it applies to both Boot Manager and
> >>>>>> Platform Recovery.
> >>>>>> -----------------------------------------------------------------
> >>>>>> -
> >>>>>> ------
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Again, I don't have an issue with trying to use an alternate
> >>>>>> approach to solve our problem (though I ultimately believe that,
> >>>>>> if PlatformRecovery#### can launch a /efi/boot/boot####.efi
> >>>>>> bootloader then we must update the specs and the code to have
> >>>>>> ReadyToBoot also signalled then, because that's the logical thing
> >>>>>> to do). But right now, I'm not seeing how to achieve that when
> >>>>>> PlatformRecovery#### is the option that is used to launch the OS
> >>>>>> installation the bootloader. So if you can provide mode details
> >>>>>> on how exactly you think creating an alternate PlatformRecovery
> >>>>>> option would help, I would appreciate it.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> /Pete
> >>>>>>
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Sunny Wang
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: mailto:devel@edk2.groups.io
> [mailto:devel@edk2.groups.io]
> >>>>>>> On Behalf Of Pete Batard
> >>>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
> >>>>>>> To: mailto:devel@edk2.groups.io
> >>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> >>>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> >>>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
> >>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>>>> recovery
> >>>>>>>
> >>>>>>> Currently, the ReadyToBoot event is only signaled when a formal
> >>>>>>> Boot Manager option is executed (in BmBoot.c ->
> >>>>>>> EfiBootManagerBoot ()).
> >>>>>>>
> >>>>>>> However, with the introduction of Platform Recovery in UEFI 2.5,
> >>>>>>> which may lead to the execution of a boot loader that has
> >>>>>>> similar requirements to a regular one, yet is not launched as a
> >>>>>>> Boot Manager option, it also becomes necessary to signal
> >>>>>>> ReadyToBoot when a Platform Recovery boot loader runs.
> >>>>>>>
> >>>>>>> Especially, this can be critical to ensuring that the graphical
> >>>>>>> console is actually usable during platform recovery, as some
> >>>>>>> platforms do rely on the ConsolePrefDxe driver, which only
> >>>>>>> performs console initialization after ReadyToBoot is triggered.
> >>>>>>>
> >>>>>>> This patch fixes that behaviour by calling
> >>>>>>> EfiSignalEventReadyToBoot () in
> EfiBootManagerProcessLoadOption
> >>>>>>> (), which is the function that sets up the platform recovery
> >>>>>>> boot process.
> >>>>>>>
> >>>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
> >>>>>>> ---
> >>>>>>>       MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> | 9
> >>>>>>> +++++++++
> >>>>>>>       1 file changed, 9 insertions(+)
> >>>>>>>
> >>>>>>> diff --git
> >>>>>>> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>>> index 89372b3b97b8..117f1f5b124c 100644
> >>>>>>> ---
> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>>> +++
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
> >>>>>>>           return EFI_SUCCESS;
> >>>>>>>         }
> >>>>>>>
> >>>>>>> +  //
> >>>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> >>>>>>> +about
> >>>>>>> to load and execute the boot option.
> >>>>>>> +  //
> >>>>>>> +  EfiSignalEventReadyToBoot ();
> >>>>>>> +  //
> >>>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled
> >>>>>>> +//  REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> >>>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> >>>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >>>>>>> +
> >>>>>>>         //
> >>>>>>>         // Load and start the load option.
> >>>>>>>         //
> >>>>>>> --
> >>>>>>> 2.21.0.windows.1
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
> >>>>> are confidential and may also be privileged. If you are not the
> >>>>> intended recipient, please notify the sender immediately and do
> >>>>> not disclose the contents to any other person, use it for any
> >>>>> purpose, or store or copy the information in any medium. Thank you.
> >>>>>
> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
> >>>>> are confidential and may also be privileged. If you are not the
> >>>>> intended recipient, please notify the sender immediately and do
> >>>>> not disclose the contents to any other person, use it for any
> >>>>> purpose, or store or copy the information in any medium. Thank you.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >
>
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

All,

Please take a moment to add any comments to this UEFI ECR BZ. This is needed to UEFI Forum can make a decision and close the ECR.
https://bugzilla.tianocore.org/show_bug.cgi?id=3336


Thanks,
--Samer



> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Tuesday, April 13, 2021 3:48 PM
> To: devel@edk2.groups.io; pete@akeo.ie; Laszlo Ersek
> <lersek@redhat.com>; Leif Lindholm <leif@nuviainc.com>; Ni, Ray
> <ray.ni@intel.com>; zhichao.gao@intel.com
> Cc: Andrei Warkentin (awarkentin@vmware.com)
> <awarkentin@vmware.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>;
> Andrew Fish <afish@apple.com>; Michael D Kinney
> <michael.d.kinney@intel.com>; Jian J Wang <jian.j.wang@intel.com>; Hao A
> Wu <hao.a.wu@intel.com>; Sunny.Hsuanwen.Wang@gmail.com; Samer El-
> Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Sunny Wang
> <Sunny.Wang@arm.com>
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> In order to make progress on this, I opened a code-first ECR  against the UEFI
> spec to clarify the language around the Boot#### options processing.
>
> Code First ECR: https://bugzilla.tianocore.org/show_bug.cgi?id=3336
>
> Feedback on the proposed language is appreciated. Please provide the
> feedback directly in the BZ above.
>
> I will update the thread/BZ with results from USWG.
>
> Thanks,
> --Samer
>
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Pete
> > Batard via groups.io
> > Sent: Thursday, February 25, 2021 5:55 AM
> > To: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; Laszlo Ersek
> > <lersek@redhat.com>; Leif Lindholm <leif@nuviainc.com>;
> > devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>;
> > zhichao.gao@intel.com
> > Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
> > Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Ard
> > Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish
> <afish@apple.com>;
> > Michael D Kinney <michael.d.kinney@intel.com>; Jian J Wang
> > <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>;
> > Sunny.Hsuanwen.Wang@gmail.com
> > Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> > recovery
> >
> > Hi Sunny,
> >
> > I appreciate the input, but seeing that it is clear that no consensus
> > has been reached with regards to how the specs should be interpreted,
> > and that at least 4 separate people have now indicated that their
> > interpretation is different from the one you are putting forward (i.e.
> > you assert that the current code implementation is specs compliant
> > whereas we assert that the current code implementation is not specs
> > compliant), I believe that any further work on this will have to be
> > conditioned, first, by a specs update, that removes any ambiguity as
> > to the scope in which ReadyToBoot should apply.
> >
> > Until that has happened, it seems very pointless to me to start
> > talking possible code workarounds, because we still can't appear to be
> > in agreement as to whether the current code implementation of
> > ReadyToBoot is specs compliant or not.
> >
> > Now, even as I am the one proposing it, I'm afraid that I am not
> > planning to be the one opening a formal specs update request, since
> > there really is only so much more time I am willing to devote to this
> > matter. But I am hoping somebody else will.
> >
> > Regards,
> >
> > /Pete
> >
> > On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
> > > Hi all,
> > >
> > > How about we signal ReadyToBoot ONLY for the default platform
> > > recovery
> > option?  The default platform recovery option here means the one
> > created by the code below in BdsEntry().
> > >    Status = EfiBootManagerInitializeLoadOption (
> > >               &PlatformDefaultBootOption,
> > >               LoadOptionNumberUnassigned,
> > >               LoadOptionTypePlatformRecovery,
> > >               LOAD_OPTION_ACTIVE,
> > >               L"Default PlatformRecovery",
> > >               FilePath,
> > >               NULL,
> > >               0
> > >               );
> > >
> > > In other words, we just need to slightly update Pete's patch as the
> > following (adding the code below to EfiBootManagerProcessLoadOption()):
> > >
> > > +   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery)
> > > + &&
> > >            StrCmp (LoadOption ->Description, L"Default
> > > PlatformRecovery")) {
> > > +    //
> > > +    // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> about
> > to load and execute the boot option.
> > > +    //
> > > +    EfiSignalEventReadyToBoot ();
> > >
> > > +    //
> > > +    // Report Status Code to indicate ReadyToBoot was signalled
> > > +    //
> > > +    REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> > > + (EFI_SOFTWARE_DXE_BS_DRIVER |
> > > + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > > +  }
> > >
> > > I think the existing platforms that have their platform-specific
> > PlatformRecovery option may also do either of the following things to
> > make the system have no chance to load the default platform recovery
> > option because they do have a better way to recover the boot options:
> > >      1. Make their PlatformRecovery option have higher priority than
> > > the
> > default platform recovery option (has a lower number (####) than the
> > default platform recovery option)
> > >      2. Remove the default platform recovery option.
> > > Therefore, if we only signal ReadyToBoot for the default platform
> > > recovery
> > option, this may not affect the existing platforms because the code
> > may never be run on these platforms.
> > >
> > >
> > >
> > >
> > >
> > > If the solution above doesn't work, I think the suggestion (Solution 2:
> > adding a new application as a PlatformRecovery####) I mentioned, in
> > the beginning, can be re-considered. The suggestion (solution 2) is
> > based on the thoughts below:
> > >       1.  I think that processing/evaluating the Boot#### can be
> > > interpreted as
> > the code after the comment " 6. Load EFI boot option to ImageHandle"
> > in
> > EfiBootManagerBoot() because these code are similar to the code in
> > EfiBootManagerProcessLoadOption(). Based on this, I think our current
> > implementation is compliant with the description below in the UEFI
> > spec. Of course, we can improve our implementation by moving the code
> > for processing/evaluating the Boot#### from EfiBootManagerBoot() to
> > EfiBootManagerProcessLoadOption() and make EfiBootManagerBoot() call
> > EfiBootManagerProcessLoadOption().
> > >                “After all SysPrep#### variables have been launched
> > > and exited,
> > the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
> group
> > and begin to evaluate Boot#### variables with Attributes set to
> > LOAD_OPTION_CATEGORY_BOOT according to the order defined by
> BootOrder.
> > The FilePathList of variables marked LOAD_OPTION_CATEGORY_BOOT shall
> > not be evaluated prior to the completion of
> > EFI_EVENT_GROUP_READY_TO_BOOT event group processing."
> > >       2. Moreover, it looks like we want to process
> > > PlatformRecovery####
> > option in the same way as Boot#### (do more things like setting
> > BootCurrent for PlatformRecovery####). If so, I would still prefer to
> > do what I suggest in the beginning to create a new application as a
> > new PlatformRecovery#### option for generating and launching a boot
> > option for the bootable image that is found by using a short-form File
> > Path Media Device Path so that we won't run into other difficulties.
> > At least, I already saw the difficulty of no connection between
> > BootCurrent variable and PlatformRecovery#### variable. Of course,
> > this application can be implemented without platform specific stuff,
> > so it can be commonly used by all platforms that need to load a boot image
> discovered by using short-form File Path Media Device Path.
> > >
> > >
> > >
> > >
> > > Regards,
> > > Sunny Wang
> > >
> > > -----Original Message-----
> > > From: Laszlo Ersek <lersek@redhat.com>
> > > Sent: Wednesday, February 17, 2021 10:26 PM
> > > To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>;
> > > devel@edk2.groups.io
> > > Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
> > > Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>;
> > Wang, Sunny
> > > (HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com;
> > ray.ni@intel.com;
> > > Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew Fish
> > > <afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>;
> > > Jian J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
> > > Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1]
> > > MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> > > recovery
> > >
> > > On 02/17/21 13:18, Pete Batard wrote:
> > >> Hi Leif,
> > >>
> > >> Thanks for trying to resurrect this issue.
> > >>
> > >> At this stage, and despite some initial pushback in the bugzilla
> > >> ticket, I believe we can all agree with the consensus that
> > >> UefiBootManagerLib is not in fact specs-compliant and therefore
> > >> needs to be fixed, one way or another, to make it specs-compliant.
> > >>
> > >> My take on this is that, rather than propose a new patch, I'd much
> > >> rather have the current maintainers agree on the course of action
> > >> to fix the library (which, as Leif suggests, might very well be to
> > >> split the library into a specs-compliant and non-specs-compliant
> > >> version), as it would of course be better if the fix came from
> > >> people who have better understanding of the ramifications we might
> > >> face with trying to correct the current behaviour, and especially,
> > >> who have knowledge of the platforms that might be impacted from
> > >> making the lib specs-
> > compliant.
> > >>
> > >> Especially, I don't think that the patch that I originally
> > >> submitted for this, or the additional proposals we made, are still
> > >> receivable, as they seem to fall short of fixing the issue in a
> > >> manner that all platforms can be happy with. And that is why I'd
> > >> like to hear from the maintainers on what their preferred approach
> would be.
> > >
> > > A new Feature PCD could satisfy both sets of platforms, could it not?
> > >
> > > (Sorry if the original patch already had such a PCD; I don't
> > > remember.)
> > >
> > > Of course then we'd have a debate around the DEC default for the new
> > > PCD
> > > -- I'd say the default value of the PCD should match the
> > > spec-mandated
> > behavior.
> > >
> > > I don't recall any specifics, but a bug-compat pattern that's
> > > sometimes used
> > is this:
> > >
> > >    if (BugCompatEnabled) {
> > >      //
> > >      // do the right thing in the wrong place, for legacy platforms' sake
> > >      //
> > >     Foo ();
> > >    }
> > >
> > >    //
> > >    // Do some stuff.
> > >    //
> > >    Bar ();
> > >
> > >    if (!BugCompatEnabled) {
> > >      //
> > >      // do the right thing in the right place, for conformant platforms
> > >      //
> > >     Foo ();
> > >    }
> > >
> > > Not sure if it applies here.
> > >
> > > Thanks
> > > Laszlo
> > >
> > >
> > >> On 2021.02.17 11:42, Leif Lindholm wrote:
> > >>> Hi Pete, +various
> > >>>
> > >>> Resurrecting this old thread since Ard pointed out an issue I ran
> > >>> into myself had already been encountered by Pete.
> > >>> And the bugzilla ticket (directly below this reply) has had no
> > >>> relevant progress since August.
> > >>>
> > >>> Executive summary:
> > >>> The current UefiBootManagerLib implementation of the
> > >>> PlatformRecovery path does not notify the
> > EFI_EVENT_GROUP_READY_TO_BOOT event.
> > >>>
> > >>> The argument has been made that since changing this would affect
> > >>> an unnamed number of non-public platforms, the behaviour cannot be
> > >>> changed even though it violates the UEFI specification.
> > >>>
> > >>> I disagree with that statement. If we want to fork
> > >>> UefiBootManagerLib into a BrokenLegacyUefiBootManagerLib and an
> > >>> actually correct one, and have those platforms move to the
> > >>> BrokenLegacy variant, I'm OK with that.
> > >>>
> > >>> But using the default version should give specification-compliant
> > >>> behaviour.
> > >>>
> > >>> /
> > >>>       Leif
> > >>>
> > >>> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
> > >>>> Please note that I have created a bug report
> > >>>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address
> > >>>> the non-compliance issue was raised during the course of the
> > >>>> discussion below.
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> /Pete
> > >>>>
> > >>>>
> > >>>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
> > >>>>> I worked with Pete offline on this..
> > >>>>>
> > >>>>> This code seems to be violating the UEFI Spec:
> > >>>>>
> > >>>>>
> > https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64d
> > >>>>> e
> > >>>>>
> >
> 7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L176
> > >>>>> 3
> > >>>>>
> > >>>>>
> > >>>>>      //
> > >>>>>      // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we
> are
> > >>>>> about to load and execute
> > >>>>>      //    the boot option.
> > >>>>>      //
> > >>>>>      if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
> > >>>>>        DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
> > >>>>>        BmStopHotkeyService (NULL, NULL);
> > >>>>>      } else {
> > >>>>>        EfiSignalEventReadyToBoot();
> > >>>>>        //
> > >>>>>        // Report Status Code to indicate ReadyToBoot was signalled
> > >>>>>        //
> > >>>>>        REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> > >>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> > >>>>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > >>>>>        //
> > >>>>>        // 4. Repair system through DriverHealth protocol
> > >>>>>        //
> > >>>>>        BmRepairAllControllers (0);
> > >>>>>      }
> > >>>>>
> > >>>>> The UEFI Spec section 3.1.7 clearly states that Boot Options
> > >>>>> (and their FilePathList) *shall not* be evaluated prior to the
> > >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> > processing:
> > >>>>>
> > >>>>> "After all SysPrep#### variables have been launched and exited,
> > >>>>> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT
> event
> > >>>>> group and begin to evaluate Boot#### variables with Attributes
> > >>>>> set to LOAD_OPTION_CATEGORY_BOOT according to the order
> defined
> > by
> > >>>>> BootOrder. The FilePathList of variables marked
> > >>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to
> the
> > >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> > processing."
> > >>>>>
> > >>>>> This is a prescriptive language that is stronger than the
> > >>>>> language in section 7.1 which defines the ReadyToBoot event
> > >>>>> group in a general way:
> > >>>>>
> > >>>>> "EFI_EVENT_GROUP_RESET_SYSTEM
> > >>>>> This event group is notified by the system when ResetSystem() is
> > >>>>> invoked and the system is about to be reset. The event group is
> > >>>>> only notified prior to ExitBootServices() invocation."
> > >>>>>
> > >>>>> The EDK2 code in the else block above (to call
> > >>>>> EfiSignalEventReadyToBoot() ) need to move before the code that
> > >>>>> is processing BootOption->FilePath. In fact, why is this
> > >>>>> signaling even a BootManager task? It should be a higher level
> > >>>>> BDS task (after processing SysPrp and before processing Boot
> > >>>>> options, per the
> > spec).
> > >>>>> This would be somewhere around
> > >>>>>
> > https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea02
> > >>>>> 1
> > >>>>> 4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
> > >>>>> where SysPrep is processed.
> > >>>>>
> > >>>>> This should also take care of the issue Pete reported in this
> > >>>>> thread, without the need for explicitly signaling ReadyToBoot
> > >>>>> from PlatformRecovery (or changing the UEFI spec).
> > >>>>>
> > >>>>> Thanks,
> > >>>>> --Samer
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > >>>>> Samer El-Haj-Mahmoud via groups.io
> > >>>>> Sent: Wednesday, June 17, 2020 12:42 PM
> > >>>>> To: devel@edk2.groups.io; Andrei Warkentin
> > (awarkentin@vmware.com)
> > >>>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW)
> > <sunnywang@hpe.com>;
> > >>>>> pete@akeo.ie
> > >>>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
> > >>>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-
> > Mahmoud
> > >>>>> <Samer.El-Haj-Mahmoud@arm.com>
> > >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> > platform
> > >>>>> recovery
> > >>>>>
> > >>>>> The UEFI spec (3.1.7) says:
> > >>>>>
> > >>>>> "After all SysPrep#### variables have been launched and exited,
> > >>>>> the platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT
> event
> > >>>>> group and begin to evaluate Boot#### variables with Attributes
> > >>>>> set to LOAD_OPTION_CATEGORY_BOOT according to the order
> defined
> > by
> > >>>>> BootOrder. The FilePathList of variables marked
> > >>>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to
> the
> > >>>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> > processing."
> > >>>>>
> > >>>>> The way I read this, I expect ReadyToBoot to be signaled after
> > >>>>> SysPrep#### (if any) are processed, but before Boot#### are
> > >>>>> processed. Is my understanding correct that this language
> > >>>>> implies ReadyToBoot need to be signaled even if BootOrder does
> > >>>>> not contain any Boot#### options marked as
> LOAD_OPTION_CATEGORY_BOOT?
> > And if
> > >>>>> so, is EDK2 not doing this, which leads us to this patch
> > >>>>> (signaling it in PlatformRecovery?)
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> From: mailto:devel@edk2.groups.io
> <mailto:devel@edk2.groups.io>
> > On
> > >>>>> Behalf Of Andrei Warkentin via groups.io
> > >>>>> Sent: Wednesday, June 17, 2020 12:37 PM
> > >>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> > >>>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
> > >>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
> > >>>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>;
> > >>>>> mailto:leif@nuviainc.com
> > >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> > platform
> > >>>>> recovery
> > >>>>>
> > >>>>> Thanks Pete.
> > >>>>>
> > >>>>> I think the question I have, that I hope Tiano veterans can
> > >>>>> chime in, is whether we are doing the right thing, or if we
> > >>>>> should be overriding the boot mode? I.e. is it normal that we
> > >>>>> boot up in recovery until options are saved?
> > >>>>>
> > >>>>>
> > >>>>> A
> > >>>>>
> > >>>>>
> > >>>>> ________________________________________
> > >>>>> From: mailto:devel@edk2.groups.io
> <mailto:devel@edk2.groups.io>
> > on
> > >>>>> behalf of Pete Batard via groups.io
> > >>>>> <mailto:pete=akeo.ie@groups.io>
> > >>>>> Sent: Wednesday, June 17, 2020 11:34 AM
> > >>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> > >>>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> > >>>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
> > >>>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
> > >>>>> mailto:ard.biesheuvel@arm.com
> <mailto:ard.biesheuvel@arm.com>;
> > >>>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
> > >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> > platform
> > >>>>> recovery
> > >>>>>
> > >>>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> > >>>>>> Thanks for checking my comments, Pete.
> > >>>>>>
> > >>>>>>> Or is the "one more" the issue, meaning that it would get
> > >>>>>>> signaled more than once?
> > >>>>>> [Sunny] Yeah, it would get signaled more than once if the
> > >>>>>> PlatformRecovery option (a UEFI application) calls
> > >>>>>> EfiBootManagerBoot() to launch the recovered boot option inside
> > >>>>>> of the application.
> > >>>>>
> > >>>>> Okay.
> > >>>>>
> > >>>>> One element that I'm going to point out is that, with the
> > >>>>> current
> > >>>>> EDK2 code (i.e. without this proposal applied), and after a user
> > >>>>> goes into the setup to save their boot options in order for
> > >>>>> regular boot options to get executed instead of PlaformRecovery,
> > >>>>> the OnReadyToBoot event is actually called twice.
> > >>>>>
> > >>>>> So my understanding is that, while we of course want to avoid
> > >>>>> this and any patch proposal should actively try to prevent it,
> > >>>>> it seems we already have behaviour in EDK2 that can lead to
> > >>>>> OnReadyToBoot being signalled more than once.
> > >>>>>
> > >>>>> At least the current Pi 4 platform does demonstrate this behaviour.
> > >>>>> For instance, if you run DEBUG, you will see two instances of:
> > >>>>>
> > >>>>>       RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> > >>>>>
> > >>>>> which is a one-instance message generated from the
> > >>>>> ConsolePrefDxe's
> > >>>>> OnReadyToBoot() call. I've also confirmed more specifically that
> > >>>>> OnReadyToBoot() is indeed called twice.
> > >>>>>
> > >>>>> I don't recall us doing much of any special with regards to boot
> > >>>>> options for the Pi platform, so my guess is that it's probably
> > >>>>> not the only platform where OnReadyToBoot might be signalled
> > >>>>> more
> > than
> > >>>>> once, and that this might be tied to a default EDK2 behaviour.
> > >>>>> Therefore I don't see having a repeated event as a major deal
> > >>>>> breaker (though, again, if we can avoid that, we of course will
> > >>>>> want to).
> > >>>>>
> > >>>>>>> I don't mind trying an alternative approach, but I don't
> > >>>>>>> understand how what you describe would help. Can you please
> be
> > >>>>>>> more specific about what you have in mind?
> > >>>>>> [Sunny] Sure. I added more information below. If it is still
> > >>>>>> not clear enough, feel free to let me know.
> > >>>>>>          1. Create a UEFI application with the code to signal
> > >>>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or
> > >>>>>> USB and run it.
> > >>>>>
> > >>>>> So that would basically be adding code that duplicates, in part,
> > >>>>> what Platform Recovery already does.
> > >>>>>
> > >>>>> I have to be honest: Even outside of the extra work this would
> > >>>>> require, I don't really like the idea of having to write our own
> > >>>>> application, as it will introduce new possible points of
> > >>>>> failures and require extra maintenance (especially as we will
> > >>>>> want to be able to handle network boot and other options, and
> > >>>>> before long, I fear that we're going to have to write our own Pi
> > >>>>> specific boot manager). Doing so simply because the current
> > >>>>> Platform Recovery, which does suit our needs otherwise, is not
> > >>>>> designed to call ReadyToBoot does not seem like the best course
> > >>>>> of action in my book.
> > >>>>>
> > >>>>> Instead, I still logically believe that any option that calls a
> > >>>>> boot loader should signal ReadyToBoot, regardless of whether it
> > >>>>> was launched from Boot Manager or Platform Recovery, and that it
> > >>>>> shouldn't be left to each platform to work around that.
> > >>>>>
> > >>>>> Of course, I understand that this would require a specs change,
> > >>>>> and that it also may have ramifications for existing platforms
> > >>>>> that interpret the current specs pedantically. But to me,
> > >>>>> regardless of what the specs appear to be limiting it to right
> > >>>>> now, the logic of a "ReadyToBoot"
> > >>>>> event is that it should be signalled whenever a bootloader is
> > >>>>> about to be executed, rather than only when a bootloader
> > >>>>> happened to be launched through a formal Boot Manager option.
> > >>>>>
> > >>>>> I would therefore appreciate if other people could weigh in on
> > >>>>> this matter, to see if I'm the only one who believes that we
> > >>>>> could ultimately have more to gain from signalling ReadyToBoot
> > >>>>> with PlatformRecovery options than leaving things as they stand
> > >>>>> right now...
> > >>>>>
> > >>>>>>          2. Then, call EfiBootManagerInitializeLoadOption like
> > >>>>>> the following in a DXE driver or other places before "Default
> > >>>>>> PlatformRecovery" registration:
> > >>>>>>       Status = EfiBootManagerInitializeLoadOption (
> > >>>>>>                  &LoadOption,
> > >>>>>>
> > >>>>>> 0,
> > >>>>>> -> 0 is the OptionNumber to let application be load before "
> > >>>>>> Default PlatformRecovery" option
> > >>>>>>                  LoadOptionTypePlatformRecovery,
> > >>>>>>                  LOAD_OPTION_ACTIVE,
> > >>>>>>                  L"Application for recovering boot options",
> > >>>>>>
> > >>>>>> FilePath,
> > >>>>>> -> FilePath is the Application's device path,
> > >>>>>>                  NULL,
> > >>>>>>                  0
> > >>>>>>                  );
> > >>>>>>
> > >>>>>>
> > >>>>>>> My reasoning is that, if PlatformRecovery#### can execute a
> > >>>>>>> regular bootloader like /efi/boot/boot####.efi from
> > >>>>>>> installation media, then it should go through the same kind of
> > >>>>>>> initialization that happens for a regular boot option, and
> > >>>>>>> that should include signaling the ReadyToBoot event.
> > >>>>>> [Sunny] Thanks for clarifying this, and Sorry about that I
> > >>>>>> missed your cover letter for this patch.  I was just thinking
> > >>>>>> that we may not really need to make this behavior change in
> > >>>>>> both EDK II code and UEFI specification for solving the problem
> > >>>>>> specific to the case that OS is loaded by "Default
> > >>>>>> PlatformRecovery" option,
> > >>>>>
> > >>>>> The way I see it is that the Pi platform is unlikely to be the
> > >>>>> only one where PlatformRecovery is seen as a means to install an
> OS.
> > >>>>> Granted, this may seem like abusing the option, but since UEFI
> > >>>>> doesn't provide an "Initial OS Install" mode, I would assert
> > >>>>> that it as good a use of this option as any.
> > >>>>>
> > >>>>> In other words, I don't think this improvement would only
> > >>>>> benefit the Pi platform.
> > >>>>>
> > >>>>>> and I'm also not sure if it is worth making this change to
> > >>>>>> affect some of the system or BIOS vendors who have
> implemented
> > >>>>>> their PlatformRecovery option.
> > >>>>>
> > >>>>> That's a legitimate concern, and I would agree the one major
> > >>>>> potential pitfall of this proposal, if there happens to exist a
> > >>>>> system where an OnReadyToBoot even before running the
> recovery
> > >>>>> option can have adverse effects.
> > >>>>>
> > >>>>> I don't really believe that such a system exists, because I
> > >>>>> expect most recovery boot loaders to also work (or at least have
> > >>>>> been designed to
> > >>>>> work) as regular boot options. But I don't have enough
> > >>>>> experience with platform recovery to know if that's a correct
> assertion to make...
> > >>>>>
> > >>>>>> If the alternative approach I mentioned works for you, I think
> > >>>>>> that would be an easier solution.
> > >>>>>
> > >>>>> Right now, even as the patch proposal has multiple issues that
> > >>>>> require it to be amended (Don't signal ReadyToBoot except for
> > >>>>> PlatformRecovery
> > >>>>> + Prevent situations where ReadyToBoot could be signalled
> > >>>>> + multiple
> > >>>>> times) I still see it as both an easier solution than the
> > >>>>> alternative, as well as one that *should* benefit people who
> > >>>>> design Platform Recovery UEFI applications in the long run. So
> > >>>>> that is why I am still trying to advocate for it.
> > >>>>>
> > >>>>> But I very much hear your concerns, and I agree that specs
> > >>>>> changes are better avoided when possible.
> > >>>>>
> > >>>>> Thus, at this stage, even as I don't want to drag this
> > >>>>> discussion much further, I don't feel like I want to commit to
> > >>>>> one solution or the other before we have had a chance to hear
> > >>>>> other people, who may have their own opinion on the matter,
> express their views.
> > >>>>>
> > >>>>> Regards,
> > >>>>>
> > >>>>> /Pete
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>> Sunny Wang
> > >>>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: Pete Batard [mailto:pete@akeo.ie]
> > >>>>>> Sent: Wednesday, June 17, 2020 6:59 PM
> > >>>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> > >>>>>> mailto:devel@edk2.groups.io
> > >>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> > >>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> > >>>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > >>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> > platform
> > >>>>>> recovery
> > >>>>>>
> > >>>>>> Hi Sunny, thanks for looking into this.
> > >>>>>>
> > >>>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> > >>>>>>> Hi Pete.
> > >>>>>>>
> > >>>>>>> Since the EfiBootManagerProcessLoadOption is called by
> > >>>>>>> ProcessLoadOptions as well, your change would also cause some
> > >>>>>>> unexpected behavior like:
> > >>>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option
> > >>>>>>> which is an application that calls EfiBootManagerBoot() to
> > >>>>>>> launch its recovered boot option.
> > >>>>>>
> > >>>>>> I'm not sure I understand how this part is unwanted.
> > >>>>>>
> > >>>>>> The point of this patch is to ensure that ReadyToBoot is
> > >>>>>> signalled for the PlatformRecovery option, so isn't what you
> > >>>>>> describe above exactly what we want?
> > >>>>>>
> > >>>>>> Or is the "one more" the issue, meaning that it would get
> > >>>>>> signalled more than once?
> > >>>>>>
> > >>>>>>
> > >>>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is
> > >>>>>>> not really a "boot" option.
> > >>>>>>
> > >>>>>> Yes, I've been wondering about that, because BdsEntry.c's
> > >>>>>> ProcessLoadOptions(), which calls
> > >>>>>> EfiBootManagerProcessLoadOption(),
> > >>>>>> mentions that it will load will load and start every
> > >>>>>> Driver####, SysPrep#### or PlatformRecovery####. But the
> > >>>>>> comment about the
> > >>>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions
> > >>>>>> PlatformRecovery####.
> > >>>>>>
> > >>>>>> If needed, I guess we could amend the patch to detect the type
> > >>>>>> of option and only signal ReadyToBoot for PlatformRecovery####.
> > >>>>>>
> > >>>>>>> To solve your problem, creating a PlatformRecovery option with
> > >>>>>>> the smallest option number and using it instead of default one
> > >>>>>>> (with short-form File Path Media Device Path) looks like a
> > >>>>>>> simpler solution.
> > >>>>>>
> > >>>>>> I don't mind trying an alternative approach, but I don't
> > >>>>>> understand how what you describe would help. Can you please be
> > >>>>>> more specific about what you have in mind?
> > >>>>>>
> > >>>>>> Our main issue here is that we must have ReadyToBoot signalled
> > >>>>>> so that the ReadyToBoot() function callback from
> > >>>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for
> > the
> > >>>>>> boot loader invoked from PlatformRecovery####  to use a
> > >>>>>> properly initialized graphical console. So I'm not sure I quite
> > >>>>>> get how switching from one PlatformRecovery#### option to
> > >>>>>> another would improve things.
> > >>>>>>
> > >>>>>> If it helps, here is what we currently default to, in terms of
> > >>>>>> boot options, on a Raspberry Pi 4 platform with a newly build
> > firmware:
> > >>>>>>
> > >>>>>> [Bds]=============Begin Load Options Dumping
> > ...=============
> > >>>>>>        Driver Options:
> > >>>>>>        SysPrep Options:
> > >>>>>>        Boot Options:
> > >>>>>>          Boot0000: UiApp              0x0109
> > >>>>>>          Boot0001: UEFI Shell                 0x0000
> > >>>>>>        PlatformRecovery Options:
> > >>>>>>          PlatformRecovery0000: Default PlatformRecovery
> > >>>>>> 0x0001 [Bds]=============End Load Options
> > Dumping=============
> > >>>>>>
> > >>>>>> With this, PlatformRecovery0000 gets executed by default, which
> > >>>>>> is what we want, since it will pick /efi/boot/bootaa64.efi from
> > >>>>>> either SD or USB and run it, the only issue being that, because
> > >>>>>> ReadyToBoot has not been executed, the graphical console is not
> > >>>>>> operative so users can't interact with the OS installer.
> > >>>>>>
> > >>>>>> So I'm really not sure how adding an extra PlatformRecovery####
> > >>>>>> would help. And I'm also not too familiar with how one would go
> > >>>>>> around to add such an entry...
> > >>>>>>
> > >>>>>>> By the way, I also checked the UEFI specification. It looks
> > >>>>>>> making sense to only signal ReadyToBoot for boot option
> > (Boot####).
> > >>>>>>
> > >>>>>> That's something I considered too, but I disagree with this
> > >>>>>> conclusion.
> > >>>>>>
> > >>>>>> My reasoning is that, if PlatformRecovery#### can execute a
> > >>>>>> regular bootloader like /efi/boot/boot####.efi from
> > >>>>>> installation media, then it should go through the same kind of
> > >>>>>> initialization that happens for a regular boot option, and that
> > >>>>>> should include signalling the ReadyToBoot event.
> > >>>>>>
> > >>>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
> > >>>>>> /efi/boot/recovery####.efi) then I would agree with only
> > >>>>>> signalling ReadyToBoot for a formal Boot#### option. But that
> > >>>>>> isn't the case, so I think it is reasonable to want to have
> > >>>>>> ReadyToBoot also occur when a /efi/boot/boot####.efi
> bootloader
> > >>>>>> is executed from PlatformRecovery####., especially when we
> know
> > >>>>>> it can be crucial to ensuring that the end user can actually
> > >>>>>> use the
> > graphical console.
> > >>>>>>
> > >>>>>>> Therefore, your change may also require specification change.
> > >>>>>>
> > >>>>>> Yes, I mentioned that in the cover letter for this patch
> > >>>>>>
> > (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%
> > >>>>>> 2
> > >>>>>>
> >
> Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%
> > 7C
> > >>>>>> a
> > >>>>>>
> >
> warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb391
> > 3
> > >>>>>> 8
> > >>>>>>
> >
> ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdat
> > a
> > >>>>>> =
> > >>>>>>
> >
> 2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;res
> > erved=0
> > >>>>>> ), which also describes the issue we are trying to solve in
> > >>>>>> greater details. This is what I wrote:
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------
> > >>>>>> --
> > >>>>>> -
> > >>>>>> ------
> > >>>>>>
> > >>>>>> Note however that this may require a specs update, as the
> > >>>>>> current UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
> > >>>>>>
> > >>>>>>      >  EFI_EVENT_GROUP_READY_TO_BOOT
> > >>>>>>      >    This event group is notified by the system when the
> > >>>>>> Boot Manager
> > >>>>>>      >    is about to load and execute a boot option.
> > >>>>>>
> > >>>>>> and, once this patch has been applied, we may want to update
> > >>>>>> this section to mention that it applies to both Boot Manager
> > >>>>>> and Platform Recovery.
> > >>>>>> ---------------------------------------------------------------
> > >>>>>> --
> > >>>>>> -
> > >>>>>> ------
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Again, I don't have an issue with trying to use an alternate
> > >>>>>> approach to solve our problem (though I ultimately believe
> > >>>>>> that, if PlatformRecovery#### can launch a
> > >>>>>> /efi/boot/boot####.efi bootloader then we must update the
> specs
> > >>>>>> and the code to have ReadyToBoot also signalled then, because
> > >>>>>> that's the logical thing to do). But right now, I'm not seeing
> > >>>>>> how to achieve that when PlatformRecovery#### is the option
> > >>>>>> that is used to launch the OS installation the bootloader. So
> > >>>>>> if you can provide mode details on how exactly you think
> > >>>>>> creating an alternate PlatformRecovery option would help, I would
> appreciate it.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>>
> > >>>>>> /Pete
> > >>>>>>
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Sunny Wang
> > >>>>>>>
> > >>>>>>> -----Original Message-----
> > >>>>>>> From: mailto:devel@edk2.groups.io
> > [mailto:devel@edk2.groups.io]
> > >>>>>>> On Behalf Of Pete Batard
> > >>>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
> > >>>>>>> To: mailto:devel@edk2.groups.io
> > >>>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> > >>>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> > >>>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
> > >>>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> > platform
> > >>>>>>> recovery
> > >>>>>>>
> > >>>>>>> Currently, the ReadyToBoot event is only signaled when a
> > >>>>>>> formal Boot Manager option is executed (in BmBoot.c ->
> > >>>>>>> EfiBootManagerBoot ()).
> > >>>>>>>
> > >>>>>>> However, with the introduction of Platform Recovery in UEFI
> > >>>>>>> 2.5, which may lead to the execution of a boot loader that has
> > >>>>>>> similar requirements to a regular one, yet is not launched as
> > >>>>>>> a Boot Manager option, it also becomes necessary to signal
> > >>>>>>> ReadyToBoot when a Platform Recovery boot loader runs.
> > >>>>>>>
> > >>>>>>> Especially, this can be critical to ensuring that the
> > >>>>>>> graphical console is actually usable during platform recovery,
> > >>>>>>> as some platforms do rely on the ConsolePrefDxe driver, which
> > >>>>>>> only performs console initialization after ReadyToBoot is
> triggered.
> > >>>>>>>
> > >>>>>>> This patch fixes that behaviour by calling
> > >>>>>>> EfiSignalEventReadyToBoot () in
> > EfiBootManagerProcessLoadOption
> > >>>>>>> (), which is the function that sets up the platform recovery
> > >>>>>>> boot process.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
> > >>>>>>> ---
> > >>>>>>>
> MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > | 9
> > >>>>>>> +++++++++
> > >>>>>>>       1 file changed, 9 insertions(+)
> > >>>>>>>
> > >>>>>>> diff --git
> > >>>>>>> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > >>>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > >>>>>>> index 89372b3b97b8..117f1f5b124c 100644
> > >>>>>>> ---
> > a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > >>>>>>> +++
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> > >>>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
> > >>>>>>>           return EFI_SUCCESS;
> > >>>>>>>         }
> > >>>>>>>
> > >>>>>>> +  //
> > >>>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we
> are
> > >>>>>>> +about
> > >>>>>>> to load and execute the boot option.
> > >>>>>>> +  //
> > >>>>>>> +  EfiSignalEventReadyToBoot ();
> > >>>>>>> +  //
> > >>>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled
> > >>>>>>> +//  REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> > >>>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> > >>>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > >>>>>>> +
> > >>>>>>>         //
> > >>>>>>>         // Load and start the load option.
> > >>>>>>>         //
> > >>>>>>> --
> > >>>>>>> 2.21.0.windows.1
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> IMPORTANT NOTICE: The contents of this email and any
> attachments
> > >>>>> are confidential and may also be privileged. If you are not the
> > >>>>> intended recipient, please notify the sender immediately and do
> > >>>>> not disclose the contents to any other person, use it for any
> > >>>>> purpose, or store or copy the information in any medium. Thank
> you.
> > >>>>>
> > >>>>> IMPORTANT NOTICE: The contents of this email and any
> attachments
> > >>>>> are confidential and may also be privileged. If you are not the
> > >>>>> intended recipient, please notify the sender immediately and do
> > >>>>> not disclose the contents to any other person, use it for any
> > >>>>> purpose, or store or copy the information in any medium. Thank
> you.
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >
> >
> >
> >
> >
> >
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

Resurrecting..

This continues to be a pain point.
At this point, it seems to me that we have multiple people and platforms in this community that are complaining about code not following the spec, but the maintainers are not agreeing because of "legacy implementation of some unidentified platforms". This is very unfortunate, but if the path forward is to fork the library, so be it.

I also recently opened an ECR against the UEFI spec to clarify the language in order to avoid any confusion: https://bugzilla.tianocore.org/show_bug.cgi?id=3336


Thanks,
--Samer






> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Wednesday, February 17, 2021 9:26 AM
> To: Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>;
> devel@edk2.groups.io
> Cc: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei
> Warkentin (awarkentin@vmware.com) <awarkentin@vmware.com>; Wang,
> Sunny (HPS SW) <sunnywang@hpe.com>; zhichao.gao@intel.com;
> ray.ni@intel.com; Ard Biesheuvel <ardb+tianocore@kernel.org>; Andrew
> Fish <afish@apple.com>; Michael D Kinney <michael.d.kinney@intel.com>;
> Jian J Wang <jian.j.wang@intel.com>; Hao A Wu <hao.a.wu@intel.com>
> Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> On 02/17/21 13:18, Pete Batard wrote:
> > Hi Leif,
> >
> > Thanks for trying to resurrect this issue.
> >
> > At this stage, and despite some initial pushback in the bugzilla
> > ticket, I believe we can all agree with the consensus that
> > UefiBootManagerLib is not in fact specs-compliant and therefore needs
> > to be fixed, one way or another, to make it specs-compliant.
> >
> > My take on this is that, rather than propose a new patch, I'd much
> > rather have the current maintainers agree on the course of action to
> > fix the library (which, as Leif suggests, might very well be to split
> > the library into a specs-compliant and non-specs-compliant version),
> > as it would of course be better if the fix came from people who have
> > better understanding of the ramifications we might face with trying to
> > correct the current behaviour, and especially, who have knowledge of
> > the platforms that might be impacted from making the lib specs-compliant.
> >
> > Especially, I don't think that the patch that I originally submitted
> > for this, or the additional proposals we made, are still receivable,
> > as they seem to fall short of fixing the issue in a manner that all
> > platforms can be happy with. And that is why I'd like to hear from the
> > maintainers on what their preferred approach would be.
>
> A new Feature PCD could satisfy both sets of platforms, could it not?
>
> (Sorry if the original patch already had such a PCD; I don't remember.)
>
> Of course then we'd have a debate around the DEC default for the new PCD
> -- I'd say the default value of the PCD should match the spec-mandated
> behavior.
>
> I don't recall any specifics, but a bug-compat pattern that's sometimes used is
> this:
>
>   if (BugCompatEnabled) {
>     //
>     // do the right thing in the wrong place, for legacy platforms' sake
>     //
>    Foo ();
>   }
>
>   //
>   // Do some stuff.
>   //
>   Bar ();
>
>   if (!BugCompatEnabled) {
>     //
>     // do the right thing in the right place, for conformant platforms
>     //
>    Foo ();
>   }
>
> Not sure if it applies here.
>
> Thanks
> Laszlo
>
>
> > On 2021.02.17 11:42, Leif Lindholm wrote:
> >> Hi Pete, +various
> >>
> >> Resurrecting this old thread since Ard pointed out an issue I ran
> >> into myself had already been encountered by Pete.
> >> And the bugzilla ticket (directly below this reply) has had no
> >> relevant progress since August.
> >>
> >> Executive summary:
> >> The current UefiBootManagerLib implementation of the
> PlatformRecovery
> >> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
> >>
> >> The argument has been made that since changing this would affect an
> >> unnamed number of non-public platforms, the behaviour cannot be
> >> changed even though it violates the UEFI specification.
> >>
> >> I disagree with that statement. If we want to fork UefiBootManagerLib
> >> into a BrokenLegacyUefiBootManagerLib and an actually correct one,
> >> and have those platforms move to the BrokenLegacy variant, I'm OK
> >> with that.
> >>
> >> But using the default version should give specification-compliant
> >> behaviour.
> >>
> >> /
> >>      Leif
> >>
> >> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
> >>> Please note that I have created a bug report
> >>> (https://bugzilla.tianocore.org/show_bug.cgi?id=2831) to address the
> >>> non-compliance issue was raised during the course of the discussion
> >>> below.
> >>>
> >>> Regards,
> >>>
> >>> /Pete
> >>>
> >>>
> >>> On 2020.06.17 18:06, Samer El-Haj-Mahmoud wrote:
> >>>> I worked with Pete offline on this..
> >>>>
> >>>> This code seems to be violating the UEFI Spec:
> >>>>
> >>>>
> https://github.com/tianocore/edk2/blob/a56af23f066e2816c67b7c6e64de
> >>>>
> 7ddefcd70780/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c#L176
> 3
> >>>>
> >>>>
> >>>>     //
> >>>>     // 3. Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> >>>> about to load and execute
> >>>>     //    the boot option.
> >>>>     //
> >>>>     if (BmIsBootManagerMenuFilePath (BootOption->FilePath)) {
> >>>>       DEBUG ((EFI_D_INFO, "[Bds] Booting Boot Manager Menu.\n"));
> >>>>       BmStopHotkeyService (NULL, NULL);
> >>>>     } else {
> >>>>       EfiSignalEventReadyToBoot();
> >>>>       //
> >>>>       // Report Status Code to indicate ReadyToBoot was signalled
> >>>>       //
> >>>>       REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> >>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> >>>> EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >>>>       //
> >>>>       // 4. Repair system through DriverHealth protocol
> >>>>       //
> >>>>       BmRepairAllControllers (0);
> >>>>     }
> >>>>
> >>>> The UEFI Spec section 3.1.7 clearly states that Boot Options (and
> >>>> their FilePathList) *shall not* be evaluated prior to the
> >>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing:
> >>>>
> >>>> "After all SysPrep#### variables have been launched and exited, the
> >>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
> group and
> >>>> begin to evaluate Boot#### variables with Attributes set to
> >>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
> >>>> BootOrder. The FilePathList of variables marked
> >>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
> >>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing."
> >>>>
> >>>> This is a prescriptive language that is stronger than the language
> >>>> in section 7.1 which defines the ReadyToBoot event group in a
> >>>> general way:
> >>>>
> >>>> "EFI_EVENT_GROUP_RESET_SYSTEM
> >>>> This event group is notified by the system when ResetSystem() is
> >>>> invoked and the system is about to be reset. The event group is
> >>>> only notified prior to ExitBootServices() invocation."
> >>>>
> >>>> The EDK2 code in the else block above (to call
> >>>> EfiSignalEventReadyToBoot() ) need to move before the code that is
> >>>> processing BootOption->FilePath. In fact, why is this signaling
> >>>> even a BootManager task? It should be a higher level BDS task
> >>>> (after processing SysPrp and before processing Boot options, per the
> spec).
> >>>> This would be somewhere around
> >>>>
> https://github.com/tianocore/edk2/blob/b15646484eaffcf7cc464fdea021
> >>>> 4498f26addc2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c#L1007
> >>>> where SysPrep is processed.
> >>>>
> >>>> This should also take care of the issue Pete reported in this
> >>>> thread, without the need for explicitly signaling ReadyToBoot from
> >>>> PlatformRecovery (or changing the UEFI spec).
> >>>>
> >>>> Thanks,
> >>>> --Samer
> >>>>
> >>>>
> >>>>
> >>>> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> >>>> Samer El-Haj-Mahmoud via groups.io
> >>>> Sent: Wednesday, June 17, 2020 12:42 PM
> >>>> To: devel@edk2.groups.io; Andrei Warkentin
> (awarkentin@vmware.com)
> >>>> <awarkentin@vmware.com>; Wang, Sunny (HPS SW)
> <sunnywang@hpe.com>;
> >>>> pete@akeo.ie
> >>>> Cc: zhichao.gao@intel.com; ray.ni@intel.com; Ard Biesheuvel
> >>>> <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer El-Haj-
> Mahmoud
> >>>> <Samer.El-Haj-Mahmoud@arm.com>
> >>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> >>>> recovery
> >>>>
> >>>> The UEFI spec (3.1.7) says:
> >>>>
> >>>> "After all SysPrep#### variables have been launched and exited, the
> >>>> platform shall notify EFI_EVENT_GROUP_READY_TO_BOOT event
> group and
> >>>> begin to evaluate Boot#### variables with Attributes set to
> >>>> LOAD_OPTION_CATEGORY_BOOT according to the order defined by
> >>>> BootOrder. The FilePathList of variables marked
> >>>> LOAD_OPTION_CATEGORY_BOOT shall not be evaluated prior to the
> >>>> completion of EFI_EVENT_GROUP_READY_TO_BOOT event group
> processing."
> >>>>
> >>>> The way I read this, I expect ReadyToBoot to be signaled after
> >>>> SysPrep#### (if any) are processed, but before Boot#### are
> >>>> processed. Is my understanding correct that this language implies
> >>>> ReadyToBoot need to be signaled even if BootOrder does not contain
> >>>> any Boot#### options marked as LOAD_OPTION_CATEGORY_BOOT?
> And if
> >>>> so, is EDK2 not doing this, which leads us to this patch (signaling
> >>>> it in PlatformRecovery?)
> >>>>
> >>>>
> >>>>
> >>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> On
> >>>> Behalf Of Andrei Warkentin via groups.io
> >>>> Sent: Wednesday, June 17, 2020 12:37 PM
> >>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>> mailto:devel@edk2.groups.io; mailto:pete@akeo.ie
> >>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com; Ard
> >>>> Biesheuvel <mailto:Ard.Biesheuvel@arm.com>;
> >>>> mailto:leif@nuviainc.com
> >>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> >>>> recovery
> >>>>
> >>>> Thanks Pete.
> >>>>
> >>>> I think the question I have, that I hope Tiano veterans can chime
> >>>> in, is whether we are doing the right thing, or if we should be
> >>>> overriding the boot mode? I.e. is it normal that we boot up in
> >>>> recovery until options are saved?
> >>>>
> >>>>
> >>>> A
> >>>>
> >>>>
> >>>> ________________________________________
> >>>> From: mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> on
> >>>> behalf of Pete Batard via groups.io <mailto:pete=akeo.ie@groups.io>
> >>>> Sent: Wednesday, June 17, 2020 11:34 AM
> >>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>> mailto:devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> >>>> Cc: mailto:zhichao.gao@intel.com <mailto:zhichao.gao@intel.com>;
> >>>> mailto:ray.ni@intel.com <mailto:ray.ni@intel.com>;
> >>>> mailto:ard.biesheuvel@arm.com <mailto:ard.biesheuvel@arm.com>;
> >>>> mailto:leif@nuviainc.com <mailto:leif@nuviainc.com>
> >>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> >>>> recovery
> >>>>
> >>>> On 2020.06.17 14:04, Wang, Sunny (HPS SW) wrote:
> >>>>> Thanks for checking my comments, Pete.
> >>>>>
> >>>>>> Or is the "one more" the issue, meaning that it would get
> >>>>>> signaled more than once?
> >>>>> [Sunny] Yeah, it would get signaled more than once if the
> >>>>> PlatformRecovery option (a UEFI application) calls
> >>>>> EfiBootManagerBoot() to launch the recovered boot option inside of
> >>>>> the application.
> >>>>
> >>>> Okay.
> >>>>
> >>>> One element that I'm going to point out is that, with the current
> >>>> EDK2 code (i.e. without this proposal applied), and after a user
> >>>> goes into the setup to save their boot options in order for regular
> >>>> boot options to get executed instead of PlaformRecovery, the
> >>>> OnReadyToBoot event is actually called twice.
> >>>>
> >>>> So my understanding is that, while we of course want to avoid this
> >>>> and any patch proposal should actively try to prevent it, it seems
> >>>> we already have behaviour in EDK2 that can lead to OnReadyToBoot
> >>>> being signalled more than once.
> >>>>
> >>>> At least the current Pi 4 platform does demonstrate this behaviour.
> >>>> For instance, if you run DEBUG, you will see two instances of:
> >>>>
> >>>>      RemoveDtStdoutPath: could not retrieve DT blob - Not Found
> >>>>
> >>>> which is a one-instance message generated from the ConsolePrefDxe's
> >>>> OnReadyToBoot() call. I've also confirmed more specifically that
> >>>> OnReadyToBoot() is indeed called twice.
> >>>>
> >>>> I don't recall us doing much of any special with regards to boot
> >>>> options for the Pi platform, so my guess is that it's probably not
> >>>> the only platform where OnReadyToBoot might be signalled more than
> >>>> once, and that this might be tied to a default EDK2 behaviour.
> >>>> Therefore I don't see having a repeated event as a major deal
> >>>> breaker (though, again, if we can avoid that, we of course will
> >>>> want to).
> >>>>
> >>>>>> I don't mind trying an alternative approach, but I don't
> >>>>>> understand how what you describe would help. Can you please be
> >>>>>> more specific about what you have in mind?
> >>>>> [Sunny] Sure. I added more information below. If it is still not
> >>>>> clear enough, feel free to let me know.
> >>>>>         1. Create a UEFI application with the code to signal
> >>>>> ReadyToBoot and pick /efi/boot/bootaa64.efi from either SD or USB
> >>>>> and run it.
> >>>>
> >>>> So that would basically be adding code that duplicates, in part,
> >>>> what Platform Recovery already does.
> >>>>
> >>>> I have to be honest: Even outside of the extra work this would
> >>>> require, I don't really like the idea of having to write our own
> >>>> application, as it will introduce new possible points of failures
> >>>> and require extra maintenance (especially as we will want to be
> >>>> able to handle network boot and other options, and before long, I
> >>>> fear that we're going to have to write our own Pi specific boot
> >>>> manager). Doing so simply because the current Platform Recovery,
> >>>> which does suit our needs otherwise, is not designed to call
> >>>> ReadyToBoot does not seem like the best course of action in my
> >>>> book.
> >>>>
> >>>> Instead, I still logically believe that any option that calls a
> >>>> boot loader should signal ReadyToBoot, regardless of whether it was
> >>>> launched from Boot Manager or Platform Recovery, and that it
> >>>> shouldn't be left to each platform to work around that.
> >>>>
> >>>> Of course, I understand that this would require a specs change, and
> >>>> that it also may have ramifications for existing platforms that
> >>>> interpret the current specs pedantically. But to me, regardless of
> >>>> what the specs appear to be limiting it to right now, the logic of
> >>>> a "ReadyToBoot"
> >>>> event is that it should be signalled whenever a bootloader is about
> >>>> to be executed, rather than only when a bootloader happened to be
> >>>> launched through a formal Boot Manager option.
> >>>>
> >>>> I would therefore appreciate if other people could weigh in on this
> >>>> matter, to see if I'm the only one who believes that we could
> >>>> ultimately have more to gain from signalling ReadyToBoot with
> >>>> PlatformRecovery options than leaving things as they stand right
> >>>> now...
> >>>>
> >>>>>         2. Then, call EfiBootManagerInitializeLoadOption like the
> >>>>> following in a DXE driver or other places before "Default
> >>>>> PlatformRecovery" registration:
> >>>>>      Status = EfiBootManagerInitializeLoadOption (
> >>>>>                 &LoadOption,
> >>>>>
> >>>>> 0,
> >>>>> -> 0 is the OptionNumber to let application be load before "
> >>>>> Default PlatformRecovery" option
> >>>>>                 LoadOptionTypePlatformRecovery,
> >>>>>                 LOAD_OPTION_ACTIVE,
> >>>>>                 L"Application for recovering boot options",
> >>>>>
> >>>>> FilePath,
> >>>>> -> FilePath is the Application's device path,
> >>>>>                 NULL,
> >>>>>                 0
> >>>>>                 );
> >>>>>
> >>>>>
> >>>>>> My reasoning is that, if PlatformRecovery#### can execute a
> >>>>>> regular bootloader like /efi/boot/boot####.efi from installation
> >>>>>> media, then it should go through the same kind of initialization
> >>>>>> that happens for a regular boot option, and that should include
> >>>>>> signaling the ReadyToBoot event.
> >>>>> [Sunny] Thanks for clarifying this, and Sorry about that I missed
> >>>>> your cover letter for this patch.  I was just thinking that we may
> >>>>> not really need to make this behavior change in both EDK II code
> >>>>> and UEFI specification for solving the problem specific to the
> >>>>> case that OS is loaded by "Default PlatformRecovery" option,
> >>>>
> >>>> The way I see it is that the Pi platform is unlikely to be the only
> >>>> one where PlatformRecovery is seen as a means to install an OS.
> >>>> Granted, this may seem like abusing the option, but since UEFI
> >>>> doesn't provide an "Initial OS Install" mode, I would assert that
> >>>> it as good a use of this option as any.
> >>>>
> >>>> In other words, I don't think this improvement would only benefit
> >>>> the Pi platform.
> >>>>
> >>>>> and I'm also not sure if it is worth making this change to affect
> >>>>> some of the system or BIOS vendors who have implemented their
> >>>>> PlatformRecovery option.
> >>>>
> >>>> That's a legitimate concern, and I would agree the one major
> >>>> potential pitfall of this proposal, if there happens to exist a
> >>>> system where an OnReadyToBoot even before running the recovery
> >>>> option can have adverse effects.
> >>>>
> >>>> I don't really believe that such a system exists, because I expect
> >>>> most recovery boot loaders to also work (or at least have been
> >>>> designed to
> >>>> work) as regular boot options. But I don't have enough experience
> >>>> with platform recovery to know if that's a correct assertion to make...
> >>>>
> >>>>> If the alternative approach I mentioned works for you, I think
> >>>>> that would be an easier solution.
> >>>>
> >>>> Right now, even as the patch proposal has multiple issues that
> >>>> require it to be amended (Don't signal ReadyToBoot except for
> >>>> PlatformRecovery
> >>>> + Prevent situations where ReadyToBoot could be signalled multiple
> >>>> times) I still see it as both an easier solution than the
> >>>> alternative, as well as one that *should* benefit people who design
> >>>> Platform Recovery UEFI applications in the long run. So that is why
> >>>> I am still trying to advocate for it.
> >>>>
> >>>> But I very much hear your concerns, and I agree that specs changes
> >>>> are better avoided when possible.
> >>>>
> >>>> Thus, at this stage, even as I don't want to drag this discussion
> >>>> much further, I don't feel like I want to commit to one solution or
> >>>> the other before we have had a chance to hear other people, who may
> >>>> have their own opinion on the matter, express their views.
> >>>>
> >>>> Regards,
> >>>>
> >>>> /Pete
> >>>>
> >>>>
> >>>>>
> >>>>> Regards,
> >>>>> Sunny Wang
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Pete Batard [mailto:pete@akeo.ie]
> >>>>> Sent: Wednesday, June 17, 2020 6:59 PM
> >>>>> To: Wang, Sunny (HPS SW) <mailto:sunnywang@hpe.com>;
> >>>>> mailto:devel@edk2.groups.io
> >>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> >>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> >>>>> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> >>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>> recovery
> >>>>>
> >>>>> Hi Sunny, thanks for looking into this.
> >>>>>
> >>>>> On 2020.06.17 09:16, Wang, Sunny (HPS SW) wrote:
> >>>>>> Hi Pete.
> >>>>>>
> >>>>>> Since the EfiBootManagerProcessLoadOption is called by
> >>>>>> ProcessLoadOptions as well, your change would also cause some
> >>>>>> unexpected behavior like:
> >>>>>> 1. Signal one more ReadyToBoot for the PlatformRecovery option
> >>>>>> which is an application that calls EfiBootManagerBoot() to launch
> >>>>>> its recovered boot option.
> >>>>>
> >>>>> I'm not sure I understand how this part is unwanted.
> >>>>>
> >>>>> The point of this patch is to ensure that ReadyToBoot is signalled
> >>>>> for the PlatformRecovery option, so isn't what you describe above
> >>>>> exactly what we want?
> >>>>>
> >>>>> Or is the "one more" the issue, meaning that it would get
> >>>>> signalled more than once?
> >>>>>
> >>>>>
> >>>>>> 2. Signal ReadyToBoot for SysPrep#### or Driver#### that is not
> >>>>>> really a "boot" option.
> >>>>>
> >>>>> Yes, I've been wondering about that, because BdsEntry.c's
> >>>>> ProcessLoadOptions(), which calls
> >>>>> EfiBootManagerProcessLoadOption(),
> >>>>> mentions that it will load will load and start every Driver####,
> >>>>> SysPrep#### or PlatformRecovery####. But the comment about the
> >>>>> while() loop in EfiBootManagerProcessLoadOption() only mentions
> >>>>> PlatformRecovery####.
> >>>>>
> >>>>> If needed, I guess we could amend the patch to detect the type of
> >>>>> option and only signal ReadyToBoot for PlatformRecovery####.
> >>>>>
> >>>>>> To solve your problem, creating a PlatformRecovery option with
> >>>>>> the smallest option number and using it instead of default one
> >>>>>> (with short-form File Path Media Device Path) looks like a
> >>>>>> simpler solution.
> >>>>>
> >>>>> I don't mind trying an alternative approach, but I don't
> >>>>> understand how what you describe would help. Can you please be
> >>>>> more specific about what you have in mind?
> >>>>>
> >>>>> Our main issue here is that we must have ReadyToBoot signalled so
> >>>>> that the ReadyToBoot() function callback from
> >>>>> EmbeddedPkg/Drivers/ConsolePrefDxe gets executed in order for
> the
> >>>>> boot loader invoked from PlatformRecovery####  to use a properly
> >>>>> initialized graphical console. So I'm not sure I quite get how
> >>>>> switching from one PlatformRecovery#### option to another would
> >>>>> improve things.
> >>>>>
> >>>>> If it helps, here is what we currently default to, in terms of
> >>>>> boot options, on a Raspberry Pi 4 platform with a newly build
> firmware:
> >>>>>
> >>>>> [Bds]=============Begin Load Options Dumping
> ...=============
> >>>>>       Driver Options:
> >>>>>       SysPrep Options:
> >>>>>       Boot Options:
> >>>>>         Boot0000: UiApp              0x0109
> >>>>>         Boot0001: UEFI Shell                 0x0000
> >>>>>       PlatformRecovery Options:
> >>>>>         PlatformRecovery0000: Default PlatformRecovery
> >>>>> 0x0001 [Bds]=============End Load Options
> Dumping=============
> >>>>>
> >>>>> With this, PlatformRecovery0000 gets executed by default, which is
> >>>>> what we want, since it will pick /efi/boot/bootaa64.efi from
> >>>>> either SD or USB and run it, the only issue being that, because
> >>>>> ReadyToBoot has not been executed, the graphical console is not
> >>>>> operative so users can't interact with the OS installer.
> >>>>>
> >>>>> So I'm really not sure how adding an extra PlatformRecovery####
> >>>>> would help. And I'm also not too familiar with how one would go
> >>>>> around to add such an entry...
> >>>>>
> >>>>>> By the way, I also checked the UEFI specification. It looks
> >>>>>> making sense to only signal ReadyToBoot for boot option
> (Boot####).
> >>>>>
> >>>>> That's something I considered too, but I disagree with this
> >>>>> conclusion.
> >>>>>
> >>>>> My reasoning is that, if PlatformRecovery#### can execute a
> >>>>> regular bootloader like /efi/boot/boot####.efi from installation
> >>>>> media, then it should go through the same kind of initialization
> >>>>> that happens for a regular boot option, and that should include
> >>>>> signalling the ReadyToBoot event.
> >>>>>
> >>>>> If there was a special bootloader for PlatformRecovery#### (e.g.
> >>>>> /efi/boot/recovery####.efi) then I would agree with only
> >>>>> signalling ReadyToBoot for a formal Boot#### option. But that
> >>>>> isn't the case, so I think it is reasonable to want to have
> >>>>> ReadyToBoot also occur when a /efi/boot/boot####.efi bootloader is
> >>>>> executed from PlatformRecovery####., especially when we know it
> >>>>> can be crucial to ensuring that the end user can actually use the
> graphical console.
> >>>>>
> >>>>>> Therefore, your change may also require specification change.
> >>>>>
> >>>>> Yes, I mentioned that in the cover letter for this patch
> >>>>>
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2
> >>>>>
> Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F61327&amp;data=02%7C01%
> 7Ca
> >>>>>
> warkentin%40vmware.com%7C5f90d077bc7949c1122f08d812dc48d3%7Cb391
> 38
> >>>>>
> ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637280084611749324&amp;sdat
> a=
> >>>>>
> 2%2B%2FcvMkrmZGTRRLDGSuMsKbiyDOGtwYwZ7qSqMyMicc%3D&amp;res
> erved=0
> >>>>> ), which also describes the issue we are trying to solve in
> >>>>> greater details. This is what I wrote:
> >>>>>
> >>>>> ------------------------------------------------------------------
> >>>>> ------
> >>>>>
> >>>>> Note however that this may require a specs update, as the current
> >>>>> UEFI specs for EFI_BOOT_SERVICES.CreateEventEx() have:
> >>>>>
> >>>>>     >  EFI_EVENT_GROUP_READY_TO_BOOT
> >>>>>     >    This event group is notified by the system when the Boot
> >>>>> Manager
> >>>>>     >    is about to load and execute a boot option.
> >>>>>
> >>>>> and, once this patch has been applied, we may want to update this
> >>>>> section to mention that it applies to both Boot Manager and
> >>>>> Platform Recovery.
> >>>>> ------------------------------------------------------------------
> >>>>> ------
> >>>>>
> >>>>>
> >>>>>
> >>>>> Again, I don't have an issue with trying to use an alternate
> >>>>> approach to solve our problem (though I ultimately believe that,
> >>>>> if PlatformRecovery#### can launch a /efi/boot/boot####.efi
> >>>>> bootloader then we must update the specs and the code to have
> >>>>> ReadyToBoot also signalled then, because that's the logical thing
> >>>>> to do). But right now, I'm not seeing how to achieve that when
> >>>>> PlatformRecovery#### is the option that is used to launch the OS
> >>>>> installation the bootloader. So if you can provide mode details on
> >>>>> how exactly you think creating an alternate PlatformRecovery
> >>>>> option would help, I would appreciate it.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> /Pete
> >>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Sunny Wang
> >>>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: mailto:devel@edk2.groups.io [mailto:devel@edk2.groups.io]
> >>>>>> On Behalf Of Pete Batard
> >>>>>> Sent: Tuesday, June 16, 2020 5:56 PM
> >>>>>> To: mailto:devel@edk2.groups.io
> >>>>>> Cc: mailto:zhichao.gao@intel.com; mailto:ray.ni@intel.com;
> >>>>>> mailto:ard.biesheuvel@arm.com; mailto:leif@nuviainc.com
> >>>>>> Subject: [edk2-devel] [edk2][PATCH 1/1]
> >>>>>> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on
> platform
> >>>>>> recovery
> >>>>>>
> >>>>>> Currently, the ReadyToBoot event is only signaled when a formal
> >>>>>> Boot Manager option is executed (in BmBoot.c ->
> >>>>>> EfiBootManagerBoot ()).
> >>>>>>
> >>>>>> However, with the introduction of Platform Recovery in UEFI 2.5,
> >>>>>> which may lead to the execution of a boot loader that has similar
> >>>>>> requirements to a regular one, yet is not launched as a Boot
> >>>>>> Manager option, it also becomes necessary to signal ReadyToBoot
> >>>>>> when a Platform Recovery boot loader runs.
> >>>>>>
> >>>>>> Especially, this can be critical to ensuring that the graphical
> >>>>>> console is actually usable during platform recovery, as some
> >>>>>> platforms do rely on the ConsolePrefDxe driver, which only
> >>>>>> performs console initialization after ReadyToBoot is triggered.
> >>>>>>
> >>>>>> This patch fixes that behaviour by calling
> >>>>>> EfiSignalEventReadyToBoot () in EfiBootManagerProcessLoadOption
> >>>>>> (), which is the function that sets up the platform recovery boot
> >>>>>> process.
> >>>>>>
> >>>>>> Signed-off-by: Pete Batard <mailto:pete@akeo.ie>
> >>>>>> ---
> >>>>>>      MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c |
> 9
> >>>>>> +++++++++
> >>>>>>      1 file changed, 9 insertions(+)
> >>>>>>
> >>>>>> diff --git
> >>>>>> a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>> index 89372b3b97b8..117f1f5b124c 100644
> >>>>>> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>> +++
> b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
> >>>>>> @@ -1376,6 +1376,15 @@ EfiBootManagerProcessLoadOption (
> >>>>>>          return EFI_SUCCESS;
> >>>>>>        }
> >>>>>>
> >>>>>> +  //
> >>>>>> +  // Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> about
> >>>>>> to load and execute the boot option.
> >>>>>> +  //
> >>>>>> +  EfiSignalEventReadyToBoot ();
> >>>>>> +  //
> >>>>>> +  // Report Status Code to indicate ReadyToBoot was signalled
> >>>>>> +//  REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> >>>>>> (EFI_SOFTWARE_DXE_BS_DRIVER |
> >>>>>> + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> >>>>>> +
> >>>>>>        //
> >>>>>>        // Load and start the load option.
> >>>>>>        //
> >>>>>> --
> >>>>>> 2.21.0.windows.1
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>> IMPORTANT NOTICE: The contents of this email and any attachments
> >>>> are confidential and may also be privileged. If you are not the
> >>>> intended recipient, please notify the sender immediately and do not
> >>>> disclose the contents to any other person, use it for any purpose,
> >>>> or store or copy the information in any medium. Thank you.
> >>>>
> >>>> IMPORTANT NOTICE: The contents of this email and any attachments
> >>>> are confidential and may also be privileged. If you are not the
> >>>> intended recipient, please notify the sender immediately and do not
> >>>> disclose the contents to any other person, use it for any purpose,
> >>>> or store or copy the information in any medium. Thank you.
> >>>>
> >>>
> >>>
> >>> 
> >>>
> >

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.