All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.