public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: u-boot@lists.denx.de
Subject: [RFC] Testing EFI_CAPSULE_ON_DISK
Date: Wed, 9 Dec 2020 10:42:46 +0900	[thread overview]
Message-ID: <20201209014246.GA27590@laputa> (raw)
In-Reply-To: <29f27773-73a7-14b1-217b-f4964b969a8b@gmx.de>

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

      reply	other threads:[~2020-12-09  1:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-08 21:46 [RFC] Testing EFI_CAPSULE_ON_DISK Heinrich Schuchardt
2020-12-09  1:42 ` AKASHI Takahiro [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201209014246.GA27590@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox