[RFC] Testing EFI_CAPSULE_ON_DISK

[RFC] Testing EFI_CAPSULE_ON_DISK

[Heinrich Schuchardt]

Hello Takahiro

when I select EFI_CAPSULE_ON_DISK_EARLY this implies EFI_SETUP_EARLY.

With EFI_SETUP_EARLY I cannot use PREBOOT to add a disk via the host
command. So I do not see how the feature could be tested on the sandbox.

I think we will have to enable dynamic binding of block devices to
overcome this mutual blocking of features.

What are your ideas?

Best regards

Heinrich

[RFC] Testing EFI_CAPSULE_ON_DISK

[AKASHI Takahiro]

Heinrich,

On Tue, Dec 08, 2020 at 10:46:15PM +0100, Heinrich Schuchardt wrote:
> Hello Takahiro
> 
> when I select EFI_CAPSULE_ON_DISK_EARLY this implies EFI_SETUP_EARLY.
> 
> With EFI_SETUP_EARLY I cannot use PREBOOT to add a disk via the host
> command. So I do not see how the feature could be tested on the sandbox.

I have noticed this issue.
In sandbox test case, a disk will be attached via "host bind" command,
and so EFI_SETUP_EARLY is simply unusable. Instead, the trick is
that the current python script performs 

> if not capsule_early:
>     # need to run uefi command to initiate capsule handling
>     output = u_boot_console.run_command(
>     'env print -e -all Capsule0000')

after rebooting U-Boot.
So at least temporarily you have to turn off EFI_CAPSULE_ON_DISK_EARLY,
and do the similar thing in PREBOOT.

> I think we will have to enable dynamic binding of block devices to
> overcome this mutual blocking of features.

I'm not sure yet how the scenario looks like here, but as far as
"dynamic binding" is concerned, I have submitted the patch of this exact
feature to support plug-in/removable devices (like usb stick and cd-rom)
more than two years ago.
https://lists.denx.de/pipermail/u-boot/2018-November/346740.html

> 
> What are your ideas?

Or simply, we'd better move efi_obj_list_init() backward just before
efi_launch_capsules() in main_loop() if it is feasible.

Thanks,
-Takahiro Akashi

> Best regards
> 
> Heinrich