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
prev parent 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