[PATCH] efi_loader: Allow also empty capsule to be process

[PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

Empty capsule are also allowed to be process. Without it updated images
can't change their Image Acceptance state from no to yes.

Signed-off-by: Michal Simek <michal.simek@amd.com>
---

 lib/efi_loader/efi_capsule.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 7a6f195cbc02..93e83e5f04c3 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -752,7 +752,8 @@ efi_status_t EFIAPI efi_update_capsule(
 		log_debug("Capsule[%d] (guid:%pUs)\n",
 			  i, &capsule->capsule_guid);
 		if (!guidcmp(&capsule->capsule_guid,
-			     &efi_guid_firmware_management_capsule_id)) {
+			     &efi_guid_firmware_management_capsule_id) ||
+		    fwu_empty_capsule(capsule)) {
 			ret  = efi_capsule_update_firmware(capsule);
 		} else {
 			log_err("Unsupported capsule type: %pUs\n",
-- 
2.36.1

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Heinrich Schuchardt]

On 13.07.23 16:35, Michal Simek wrote:
> Empty capsule are also allowed to be process. Without it updated images
> can't change their Image Acceptance state from no to yes.

Is there any documentation describing the usage of empty capsule to set
the image acceptance state?

Best regards

Heinrich

>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
>
>   lib/efi_loader/efi_capsule.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 7a6f195cbc02..93e83e5f04c3 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -752,7 +752,8 @@ efi_status_t EFIAPI efi_update_capsule(
>   		log_debug("Capsule[%d] (guid:%pUs)\n",
>   			  i, &capsule->capsule_guid);
>   		if (!guidcmp(&capsule->capsule_guid,
> -			     &efi_guid_firmware_management_capsule_id)) {
> +			     &efi_guid_firmware_management_capsule_id) ||
> +		    fwu_empty_capsule(capsule)) {
>   			ret  = efi_capsule_update_firmware(capsule);
>   		} else {
>   			log_err("Unsupported capsule type: %pUs\n",

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

On 7/18/23 17:41, Heinrich Schuchardt wrote:
> On 13.07.23 16:35, Michal Simek wrote:
>> Empty capsule are also allowed to be process. Without it updated images
>> can't change their Image Acceptance state from no to yes.
> 
> Is there any documentation describing the usage of empty capsule to set
> the image acceptance state?

I actually don't know about documentation. I was talking to Ilias to make sure 
that documentation is up2date because there are missing couple of things there.

I am testing A/B update and if you setup oemflags to 0x8000 then capsules are 
not automatically accepted and waiting for acceptance capsule to be passed.
When I tested it I found out that they are not process that's why I created this 
patch. But definitely someone should check that logic that the patch is right 
based on intention how these empty capsules should be used.
I am actually not quite sure how revert capsules should be used and how to 
revert only certain image if you use multiple images in the same bank.

Thanks,
Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[AKASHI Takahiro]

Hi,

On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
> 
> 
> On 7/18/23 17:41, Heinrich Schuchardt wrote:
> > On 13.07.23 16:35, Michal Simek wrote:
> > > Empty capsule are also allowed to be process. Without it updated images
> > > can't change their Image Acceptance state from no to yes.
> > 
> > Is there any documentation describing the usage of empty capsule to set
> > the image acceptance state?
> 
> I actually don't know about documentation. I was talking to Ilias to make
> sure that documentation is up2date because there are missing couple of
> things there.

Sughosh should have more to say here about A/B update.

> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
> are not automatically accepted and waiting for acceptance capsule to be
> passed.
> When I tested it I found out that they are not process that's why I created
> this patch.

The path you tried to modify is only executed by "efidebug capsule update"
or more specifically via the runtime service, UPDATE_CAPSULE.

But this API is NOT officially supported in the current capsule implementation
(at least, in my initial intention).
The only way to invoke capsule updates is to reboot the system.
If you want to test A/B update, please do the reboot.

-Takahiro Akashi


> But definitely someone should check that logic that the patch is
> right based on intention how these empty capsules should be used.
> I am actually not quite sure how revert capsules should be used and how to
> revert only certain image if you use multiple images in the same bank.
> 
> Thanks,
> Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

Hi,

On 7/20/23 07:49, AKASHI Takahiro wrote:
> Hi,
> 
> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
>>
>>
>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
>>> On 13.07.23 16:35, Michal Simek wrote:
>>>> Empty capsule are also allowed to be process. Without it updated images
>>>> can't change their Image Acceptance state from no to yes.
>>>
>>> Is there any documentation describing the usage of empty capsule to set
>>> the image acceptance state?
>>
>> I actually don't know about documentation. I was talking to Ilias to make
>> sure that documentation is up2date because there are missing couple of
>> things there.
> 
> Sughosh should have more to say here about A/B update.
> 
>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
>> are not automatically accepted and waiting for acceptance capsule to be
>> passed.
>> When I tested it I found out that they are not process that's why I created
>> this patch.
> 
> The path you tried to modify is only executed by "efidebug capsule update"
> or more specifically via the runtime service, UPDATE_CAPSULE.
> 
> But this API is NOT officially supported in the current capsule implementation
> (at least, in my initial intention).
> The only way to invoke capsule updates is to reboot the system.
> If you want to test A/B update, please do the reboot.

I realized that to get full flow you need to use capsule update on disk to get 
all functionalities. But it is very impractical. Actually I would expect via 
efidebug you should be able to perform all steps as capsule update performs when 
you do reboot.
I would also understand that via efidebug you are not able to apply any capsule 
but I don't think it is right that you can apply just update capsules but not 
empty capsules. I would understand none or all but not something in the middle.

Thanks,
Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Sughosh Ganu]

On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
>
> Hi,
>
> On 7/20/23 07:49, AKASHI Takahiro wrote:
> > Hi,
> >
> > On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
> >>
> >>
> >> On 7/18/23 17:41, Heinrich Schuchardt wrote:
> >>> On 13.07.23 16:35, Michal Simek wrote:
> >>>> Empty capsule are also allowed to be process. Without it updated images
> >>>> can't change their Image Acceptance state from no to yes.
> >>>
> >>> Is there any documentation describing the usage of empty capsule to set
> >>> the image acceptance state?
> >>
> >> I actually don't know about documentation. I was talking to Ilias to make
> >> sure that documentation is up2date because there are missing couple of
> >> things there.
> >
> > Sughosh should have more to say here about A/B update.
> >
> >> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
> >> are not automatically accepted and waiting for acceptance capsule to be
> >> passed.
> >> When I tested it I found out that they are not process that's why I created
> >> this patch.
> >
> > The path you tried to modify is only executed by "efidebug capsule update"
> > or more specifically via the runtime service, UPDATE_CAPSULE.
> >
> > But this API is NOT officially supported in the current capsule implementation
> > (at least, in my initial intention).
> > The only way to invoke capsule updates is to reboot the system.
> > If you want to test A/B update, please do the reboot.
>
> I realized that to get full flow you need to use capsule update on disk to get
> all functionalities. But it is very impractical. Actually I would expect via
> efidebug you should be able to perform all steps as capsule update performs when
> you do reboot.
> I would also understand that via efidebug you are not able to apply any capsule
> but I don't think it is right that you can apply just update capsules but not
> empty capsules. I would understand none or all but not something in the middle.

The A/B update functionality requires using the capsule-on-disk
functionality for performing the updates. This is also mentioned in
the fwu_updates.rst document. You should be able to apply empty
capsules even with the 'efidebug disk-update' command. I have never
used the 'efidebug capsule update' command, so I'm not sure if that is
supported. Like Takahiro mentioned, if you place the capsules(genuine
or empty) under the /EFI/UpdateCapsule/ directory, the update should
happen automatically, since the fwu update feature also enables the
EFI_CAPSULE_ON_DISK_EARLY config.

-sughosh

>
> Thanks,
> Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

On 7/20/23 08:36, Sughosh Ganu wrote:
> On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
>>
>> Hi,
>>
>> On 7/20/23 07:49, AKASHI Takahiro wrote:
>>> Hi,
>>>
>>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
>>>>
>>>>
>>>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
>>>>> On 13.07.23 16:35, Michal Simek wrote:
>>>>>> Empty capsule are also allowed to be process. Without it updated images
>>>>>> can't change their Image Acceptance state from no to yes.
>>>>>
>>>>> Is there any documentation describing the usage of empty capsule to set
>>>>> the image acceptance state?
>>>>
>>>> I actually don't know about documentation. I was talking to Ilias to make
>>>> sure that documentation is up2date because there are missing couple of
>>>> things there.
>>>
>>> Sughosh should have more to say here about A/B update.
>>>
>>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
>>>> are not automatically accepted and waiting for acceptance capsule to be
>>>> passed.
>>>> When I tested it I found out that they are not process that's why I created
>>>> this patch.
>>>
>>> The path you tried to modify is only executed by "efidebug capsule update"
>>> or more specifically via the runtime service, UPDATE_CAPSULE.
>>>
>>> But this API is NOT officially supported in the current capsule implementation
>>> (at least, in my initial intention).
>>> The only way to invoke capsule updates is to reboot the system.
>>> If you want to test A/B update, please do the reboot.
>>
>> I realized that to get full flow you need to use capsule update on disk to get
>> all functionalities. But it is very impractical. Actually I would expect via
>> efidebug you should be able to perform all steps as capsule update performs when
>> you do reboot.
>> I would also understand that via efidebug you are not able to apply any capsule
>> but I don't think it is right that you can apply just update capsules but not
>> empty capsules. I would understand none or all but not something in the middle.
> 
> The A/B update functionality requires using the capsule-on-disk
> functionality for performing the updates. This is also mentioned in
> the fwu_updates.rst document. You should be able to apply empty
> capsules even with the 'efidebug disk-update' command.

Yes this is working fine.

ZynqMP> efidebug capsule disk-update
#####
Applying capsule capsule1.bin succeeded.
#########################
Applying capsule capsule2.bin succeeded.
Reboot after firmware update.

I tested it also with empty capsules which are also process properly.

> I have never
> used the 'efidebug capsule update' command, so I'm not sure if that is
> supported. Like Takahiro mentioned, if you place the capsules(genuine
> or empty) under the /EFI/UpdateCapsule/ directory, the update should
> happen automatically, since the fwu update feature also enables the
> EFI_CAPSULE_ON_DISK_EARLY config.

Yes that's work fine on production systems.
But from my point of view there shouldn't be really a problem to also apply 
empty capsule via efidebug capsule update to be able to see that steps and 
changes in mdata structure without performing reset.

Again I have no issue with code which is using capsule-on-disk feature but I 
think that pretty much all these steps which are done automatically should be 
possible to do through steps to see them. That's what you can do with bootm 
start and simply stepping through it.

I am testing 2 images per bank and I can simply load other partition by simple 
commands
tftpboot 0x100000 192.168.0.105:capsule1.bin && efidebug capsule update -v 0x100000
tftpboot 0x100000 192.168.0.105:capsule2.bin && efidebug capsule update -v 0x100000

And then perform reset to them. I would expect that the same should work also 
for empty capsules. I am not able to get in this to trial state but I expect 
this is simply because I am not creating TrialStateCtr variable by hand.

Take a look at log below.

Thanks,
Michal


U-Boot 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)

CPU:   ZynqMP
Silicon: v3
Chip:  xck26
Detected name: zynqmp-sm-k26-xcl2gc-ed-revB-sck-kv-g-revB
Model: ZynqMP KV260 revB
Board: Xilinx ZynqMP
DRAM:  2 GiB (effective 4 GiB)
PMUFW:	v1.1
Xilinx I2C FRU format at nvmem0:
  Manufacturer Name: XILINX
  Product Name: SM-K26-XCL2GC-ED
  Serial No: 50572B111F2H
  Part Number: 5057-02ED
  File ID: 0x0
  Revision Number: B
Xilinx I2C FRU format at nvmem1:
  Manufacturer Name: XILINX
  Product Name: SCK-KV-G
  Serial No: 50582B112M07
  Part Number: 5058-02
  File ID: 0x0
  Revision Number: B
EL Level:	EL2
Secure Boot:	not authenticated, not encrypted
Core:  90 devices, 33 uclasses, devicetree: fit
NAND:  0 MiB
MMC:   mmc@ff160000: 0, mmc@ff170000: 1
Loading Environment from SPIFlash... SF: Detected mt25qu512a with page size 256 
Bytes, erase size 64 KiB, total 64 MiB
OK
In:    serial
Out:   serial
Err:   serial
Net:   PHY reset timed out

ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
eth0: ethernet@ff0e0000
fwu_plat_get_bootidx: boot_idx: 1, active_idx: 1
tpm_tis_spi_probe: missing reset GPIO
System booting in Trial State
Trial State count: attempt 1 out of 3
gpio: pin gpio@ff0a000038 (gpio 38) value is 0
gpio: pin gpio@ff0a000038 (gpio 38) value is 1
starting USB...
No working controllers found

Reset SCSI
scanning bus for devices...
Hit any key to stop autoboot:  0
ZynqMP>
ZynqMP> fwu
	FWU Metadata
crc32: 0xe1ea1858
version: 0x1
active_index: 0x1
previous_active_index: 0x0
	Image Info

Image Type Guid: DE6066E8-0256-4FAD-8238-E406E274C4CF
Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
Image Guid:  F64A0548-2CCE-ED11-8F66-7BC4531CFE6B
Image Acceptance: yes
Image Guid:  3E9C814B-2CCE-ED11-BEC8-23DE4C6D2CF2
Image Acceptance: no

Image Type Guid: CF9ECFD4-938B-41C5-8551-1F883AB7DC18
Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
Image Guid:  52DA04FB-9D0E-EE11-A57F-637805837C3F
Image Acceptance: yes
Image Guid:  46926007-9E0E-EE11-A23A-A38980B779A1
Image Acceptance: no
ZynqMP> dhcp
BOOTP broadcast 1
DHCP client bound to address 192.168.0.155 (10 ms)
ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1-accept.bin && efidebug capsule 
update -v 0x100000
Using ethernet@ff0e0000 device
TFTP from server 192.168.0.105; our IP address is 192.168.0.155
Filename 'capsule1-accept.bin'.
Load address: 0x100000
Loading: #
	 6.8 KiB/s
done
Bytes transferred = 44 (2c hex)
Capsule guid: 0c996046-bcc0-4d04-85ec-e1fcedf1c6f8
Capsule flags: 0x0
Capsule header size: 0x1c
Capsule image size: 0x2c
Unsupported capsule type: 0c996046-bcc0-4d04-85ec-e1fcedf1c6f8
Cannot handle a capsule at 0000000000100000
ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1-accept.bin && save mmc 1 
0x100000 /EFI/UpdateCapsule/capsule2.bin ${filesize}
Using ethernet@ff0e0000 device
TFTP from server 192.168.0.105; our IP address is 192.168.0.155
Filename 'capsule1-accept.bin'.
Load address: 0x100000
Loading: #
	 43 KiB/s
done
Bytes transferred = 44 (2c hex)
44 bytes written in 726 ms (0 Bytes/s)
ZynqMP> efidebug capsule disk-update
Applying capsule capsule2.bin succeeded.
Reboot after firmware update.
Rebooting to index 1
<debug_uart>
PMUFW:	v1.1
U-Boot SPL 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)
Loading new PMUFW cfg obj (2032 bytes)
Silicon version:	3
EL Level:	EL3
Secure Boot:	not authenticated, not encrypted
Multiboot:	496
Trying to boot from SPI
spl_spi_get_uboot_offs: Offset of u-boot.itb should be at 0x1000000
NOTICE:  BL31: Non secure code at 0x8000000
NOTICE:  BL31: v2.9(debug):v2.9.0-337-g37561ae1e640
NOTICE:  BL31: Built : 13:08:28, Jul 13 2023
INFO:    ARM GICv2 driver initialized
INFO:    BL31: Initializing runtime services
INFO:    BL31: PM Service Init Complete: API v1.1
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: cortex_a53: CPU workaround for 1530924 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x8000000
INFO:    SPSR = 0x3c9

U-Boot 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)

CPU:   ZynqMP
Silicon: v3
Chip:  xck26
Detected name: zynqmp-sm-k26-xcl2gc-ed-revB-sck-kv-g-revB
Model: ZynqMP KV260 revB
Board: Xilinx ZynqMP
DRAM:  2 GiB (effective 4 GiB)
PMUFW:	v1.1
Xilinx I2C FRU format at nvmem0:
  Manufacturer Name: XILINX
  Product Name: SM-K26-XCL2GC-ED
  Serial No: 50572B111F2H
  Part Number: 5057-02ED
  File ID: 0x0
  Revision Number: B
Xilinx I2C FRU format at nvmem1:
  Manufacturer Name: XILINX
  Product Name: SCK-KV-G
  Serial No: 50582B112M07
  Part Number: 5058-02
  File ID: 0x0
  Revision Number: B
EL Level:	EL2
Secure Boot:	not authenticated, not encrypted
Core:  90 devices, 33 uclasses, devicetree: fit
NAND:  0 MiB
MMC:   mmc@ff160000: 0, mmc@ff170000: 1
Loading Environment from SPIFlash... SF: Detected mt25qu512a with page size 256 
Bytes, erase size 64 KiB, total 64 MiB
OK
In:    serial
Out:   serial
Err:   serial
Net:   PHY reset timed out

ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
eth0: ethernet@ff0e0000
fwu_plat_get_bootidx: boot_idx: 1, active_idx: 1
tpm_tis_spi_probe: missing reset GPIO
System booting in Trial State
Trial State count: attempt 2 out of 3
gpio: pin gpio@ff0a000038 (gpio 38) value is 0
gpio: pin gpio@ff0a000038 (gpio 38) value is 1
starting USB...
No working controllers found

Reset SCSI
scanning bus for devices...
Hit any key to stop autoboot:  0
ZynqMP>
ZynqMP>
ZynqMP>
ZynqMP> fwu
	FWU Metadata
crc32: 0xb62f5041
version: 0x1
active_index: 0x1
previous_active_index: 0x0
	Image Info

Image Type Guid: DE6066E8-0256-4FAD-8238-E406E274C4CF
Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
Image Guid:  F64A0548-2CCE-ED11-8F66-7BC4531CFE6B
Image Acceptance: yes
Image Guid:  3E9C814B-2CCE-ED11-BEC8-23DE4C6D2CF2
Image Acceptance: yes

Image Type Guid: CF9ECFD4-938B-41C5-8551-1F883AB7DC18
Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
Image Guid:  52DA04FB-9D0E-EE11-A57F-637805837C3F
Image Acceptance: yes
Image Guid:  46926007-9E0E-EE11-A23A-A38980B779A1
Image Acceptance: no
ZynqMP>

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Sughosh Ganu]

On Thu, 20 Jul 2023 at 13:26, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/20/23 08:36, Sughosh Ganu wrote:
> > On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
> >>
> >> Hi,
> >>
> >> On 7/20/23 07:49, AKASHI Takahiro wrote:
> >>> Hi,
> >>>
> >>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
> >>>>
> >>>>
> >>>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
> >>>>> On 13.07.23 16:35, Michal Simek wrote:
> >>>>>> Empty capsule are also allowed to be process. Without it updated images
> >>>>>> can't change their Image Acceptance state from no to yes.
> >>>>>
> >>>>> Is there any documentation describing the usage of empty capsule to set
> >>>>> the image acceptance state?
> >>>>
> >>>> I actually don't know about documentation. I was talking to Ilias to make
> >>>> sure that documentation is up2date because there are missing couple of
> >>>> things there.
> >>>
> >>> Sughosh should have more to say here about A/B update.
> >>>
> >>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
> >>>> are not automatically accepted and waiting for acceptance capsule to be
> >>>> passed.
> >>>> When I tested it I found out that they are not process that's why I created
> >>>> this patch.
> >>>
> >>> The path you tried to modify is only executed by "efidebug capsule update"
> >>> or more specifically via the runtime service, UPDATE_CAPSULE.
> >>>
> >>> But this API is NOT officially supported in the current capsule implementation
> >>> (at least, in my initial intention).
> >>> The only way to invoke capsule updates is to reboot the system.
> >>> If you want to test A/B update, please do the reboot.
> >>
> >> I realized that to get full flow you need to use capsule update on disk to get
> >> all functionalities. But it is very impractical. Actually I would expect via
> >> efidebug you should be able to perform all steps as capsule update performs when
> >> you do reboot.
> >> I would also understand that via efidebug you are not able to apply any capsule
> >> but I don't think it is right that you can apply just update capsules but not
> >> empty capsules. I would understand none or all but not something in the middle.
> >
> > The A/B update functionality requires using the capsule-on-disk
> > functionality for performing the updates. This is also mentioned in
> > the fwu_updates.rst document. You should be able to apply empty
> > capsules even with the 'efidebug disk-update' command.
>
> Yes this is working fine.
>
> ZynqMP> efidebug capsule disk-update
> #####
> Applying capsule capsule1.bin succeeded.
> #########################
> Applying capsule capsule2.bin succeeded.
> Reboot after firmware update.
>
> I tested it also with empty capsules which are also process properly.
>
> > I have never
> > used the 'efidebug capsule update' command, so I'm not sure if that is
> > supported. Like Takahiro mentioned, if you place the capsules(genuine
> > or empty) under the /EFI/UpdateCapsule/ directory, the update should
> > happen automatically, since the fwu update feature also enables the
> > EFI_CAPSULE_ON_DISK_EARLY config.
>
> Yes that's work fine on production systems.
> But from my point of view there shouldn't be really a problem to also apply
> empty capsule via efidebug capsule update to be able to see that steps and
> changes in mdata structure without performing reset.

The 'efidebug capsule update' command calls the efi_update_capsule
function, which implements the UpdateCapsule runtime service call. The
initial versions of my fwu patches were indeed adding support for this
path, but one of the review comments was to restrict support only for
the capsule-on-disk path when performing the update in u-boot, since
we are not using the runtime call in u-boot.

-sughosh

>
> Again I have no issue with code which is using capsule-on-disk feature but I
> think that pretty much all these steps which are done automatically should be
> possible to do through steps to see them. That's what you can do with bootm
> start and simply stepping through it.
>
> I am testing 2 images per bank and I can simply load other partition by simple
> commands
> tftpboot 0x100000 192.168.0.105:capsule1.bin && efidebug capsule update -v 0x100000
> tftpboot 0x100000 192.168.0.105:capsule2.bin && efidebug capsule update -v 0x100000
>
> And then perform reset to them. I would expect that the same should work also
> for empty capsules. I am not able to get in this to trial state but I expect
> this is simply because I am not creating TrialStateCtr variable by hand.
>
> Take a look at log below.
>
> Thanks,
> Michal
>
>
> U-Boot 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)
>
> CPU:   ZynqMP
> Silicon: v3
> Chip:  xck26
> Detected name: zynqmp-sm-k26-xcl2gc-ed-revB-sck-kv-g-revB
> Model: ZynqMP KV260 revB
> Board: Xilinx ZynqMP
> DRAM:  2 GiB (effective 4 GiB)
> PMUFW:  v1.1
> Xilinx I2C FRU format at nvmem0:
>   Manufacturer Name: XILINX
>   Product Name: SM-K26-XCL2GC-ED
>   Serial No: 50572B111F2H
>   Part Number: 5057-02ED
>   File ID: 0x0
>   Revision Number: B
> Xilinx I2C FRU format at nvmem1:
>   Manufacturer Name: XILINX
>   Product Name: SCK-KV-G
>   Serial No: 50582B112M07
>   Part Number: 5058-02
>   File ID: 0x0
>   Revision Number: B
> EL Level:       EL2
> Secure Boot:    not authenticated, not encrypted
> Core:  90 devices, 33 uclasses, devicetree: fit
> NAND:  0 MiB
> MMC:   mmc@ff160000: 0, mmc@ff170000: 1
> Loading Environment from SPIFlash... SF: Detected mt25qu512a with page size 256
> Bytes, erase size 64 KiB, total 64 MiB
> OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   PHY reset timed out
>
> ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
> eth0: ethernet@ff0e0000
> fwu_plat_get_bootidx: boot_idx: 1, active_idx: 1
> tpm_tis_spi_probe: missing reset GPIO
> System booting in Trial State
> Trial State count: attempt 1 out of 3
> gpio: pin gpio@ff0a000038 (gpio 38) value is 0
> gpio: pin gpio@ff0a000038 (gpio 38) value is 1
> starting USB...
> No working controllers found
>
> Reset SCSI
> scanning bus for devices...
> Hit any key to stop autoboot:  0
> ZynqMP>
> ZynqMP> fwu
>         FWU Metadata
> crc32: 0xe1ea1858
> version: 0x1
> active_index: 0x1
> previous_active_index: 0x0
>         Image Info
>
> Image Type Guid: DE6066E8-0256-4FAD-8238-E406E274C4CF
> Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
> Image Guid:  F64A0548-2CCE-ED11-8F66-7BC4531CFE6B
> Image Acceptance: yes
> Image Guid:  3E9C814B-2CCE-ED11-BEC8-23DE4C6D2CF2
> Image Acceptance: no
>
> Image Type Guid: CF9ECFD4-938B-41C5-8551-1F883AB7DC18
> Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
> Image Guid:  52DA04FB-9D0E-EE11-A57F-637805837C3F
> Image Acceptance: yes
> Image Guid:  46926007-9E0E-EE11-A23A-A38980B779A1
> Image Acceptance: no
> ZynqMP> dhcp
> BOOTP broadcast 1
> DHCP client bound to address 192.168.0.155 (10 ms)
> ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1-accept.bin && efidebug capsule
> update -v 0x100000
> Using ethernet@ff0e0000 device
> TFTP from server 192.168.0.105; our IP address is 192.168.0.155
> Filename 'capsule1-accept.bin'.
> Load address: 0x100000
> Loading: #
>          6.8 KiB/s
> done
> Bytes transferred = 44 (2c hex)
> Capsule guid: 0c996046-bcc0-4d04-85ec-e1fcedf1c6f8
> Capsule flags: 0x0
> Capsule header size: 0x1c
> Capsule image size: 0x2c
> Unsupported capsule type: 0c996046-bcc0-4d04-85ec-e1fcedf1c6f8
> Cannot handle a capsule at 0000000000100000
> ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1-accept.bin && save mmc 1
> 0x100000 /EFI/UpdateCapsule/capsule2.bin ${filesize}
> Using ethernet@ff0e0000 device
> TFTP from server 192.168.0.105; our IP address is 192.168.0.155
> Filename 'capsule1-accept.bin'.
> Load address: 0x100000
> Loading: #
>          43 KiB/s
> done
> Bytes transferred = 44 (2c hex)
> 44 bytes written in 726 ms (0 Bytes/s)
> ZynqMP> efidebug capsule disk-update
> Applying capsule capsule2.bin succeeded.
> Reboot after firmware update.
> Rebooting to index 1
> <debug_uart>
> PMUFW:  v1.1
> U-Boot SPL 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)
> Loading new PMUFW cfg obj (2032 bytes)
> Silicon version:        3
> EL Level:       EL3
> Secure Boot:    not authenticated, not encrypted
> Multiboot:      496
> Trying to boot from SPI
> spl_spi_get_uboot_offs: Offset of u-boot.itb should be at 0x1000000
> NOTICE:  BL31: Non secure code at 0x8000000
> NOTICE:  BL31: v2.9(debug):v2.9.0-337-g37561ae1e640
> NOTICE:  BL31: Built : 13:08:28, Jul 13 2023
> INFO:    ARM GICv2 driver initialized
> INFO:    BL31: Initializing runtime services
> INFO:    BL31: PM Service Init Complete: API v1.1
> INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
> INFO:    BL31: cortex_a53: CPU workaround for 1530924 was applied
> INFO:    BL31: Preparing for EL3 exit to normal world
> INFO:    Entry point address = 0x8000000
> INFO:    SPSR = 0x3c9
>
> U-Boot 2023.07-00693-g41137e2e3970 (Jul 20 2023 - 08:46:56 +0200)
>
> CPU:   ZynqMP
> Silicon: v3
> Chip:  xck26
> Detected name: zynqmp-sm-k26-xcl2gc-ed-revB-sck-kv-g-revB
> Model: ZynqMP KV260 revB
> Board: Xilinx ZynqMP
> DRAM:  2 GiB (effective 4 GiB)
> PMUFW:  v1.1
> Xilinx I2C FRU format at nvmem0:
>   Manufacturer Name: XILINX
>   Product Name: SM-K26-XCL2GC-ED
>   Serial No: 50572B111F2H
>   Part Number: 5057-02ED
>   File ID: 0x0
>   Revision Number: B
> Xilinx I2C FRU format at nvmem1:
>   Manufacturer Name: XILINX
>   Product Name: SCK-KV-G
>   Serial No: 50582B112M07
>   Part Number: 5058-02
>   File ID: 0x0
>   Revision Number: B
> EL Level:       EL2
> Secure Boot:    not authenticated, not encrypted
> Core:  90 devices, 33 uclasses, devicetree: fit
> NAND:  0 MiB
> MMC:   mmc@ff160000: 0, mmc@ff170000: 1
> Loading Environment from SPIFlash... SF: Detected mt25qu512a with page size 256
> Bytes, erase size 64 KiB, total 64 MiB
> OK
> In:    serial
> Out:   serial
> Err:   serial
> Net:   PHY reset timed out
>
> ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 1, interface rgmii-id
> eth0: ethernet@ff0e0000
> fwu_plat_get_bootidx: boot_idx: 1, active_idx: 1
> tpm_tis_spi_probe: missing reset GPIO
> System booting in Trial State
> Trial State count: attempt 2 out of 3
> gpio: pin gpio@ff0a000038 (gpio 38) value is 0
> gpio: pin gpio@ff0a000038 (gpio 38) value is 1
> starting USB...
> No working controllers found
>
> Reset SCSI
> scanning bus for devices...
> Hit any key to stop autoboot:  0
> ZynqMP>
> ZynqMP>
> ZynqMP>
> ZynqMP> fwu
>         FWU Metadata
> crc32: 0xb62f5041
> version: 0x1
> active_index: 0x1
> previous_active_index: 0x0
>         Image Info
>
> Image Type Guid: DE6066E8-0256-4FAD-8238-E406E274C4CF
> Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
> Image Guid:  F64A0548-2CCE-ED11-8F66-7BC4531CFE6B
> Image Acceptance: yes
> Image Guid:  3E9C814B-2CCE-ED11-BEC8-23DE4C6D2CF2
> Image Acceptance: yes
>
> Image Type Guid: CF9ECFD4-938B-41C5-8551-1F883AB7DC18
> Location Guid: D7CE8A58-CE2C-11ED-81CD-D324E93AC223
> Image Guid:  52DA04FB-9D0E-EE11-A57F-637805837C3F
> Image Acceptance: yes
> Image Guid:  46926007-9E0E-EE11-A23A-A38980B779A1
> Image Acceptance: no
> ZynqMP>
>
>
>
>

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

On 7/20/23 10:45, Sughosh Ganu wrote:
> On Thu, 20 Jul 2023 at 13:26, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 7/20/23 08:36, Sughosh Ganu wrote:
>>> On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 7/20/23 07:49, AKASHI Takahiro wrote:
>>>>> Hi,
>>>>>
>>>>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
>>>>>>
>>>>>>
>>>>>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
>>>>>>> On 13.07.23 16:35, Michal Simek wrote:
>>>>>>>> Empty capsule are also allowed to be process. Without it updated images
>>>>>>>> can't change their Image Acceptance state from no to yes.
>>>>>>>
>>>>>>> Is there any documentation describing the usage of empty capsule to set
>>>>>>> the image acceptance state?
>>>>>>
>>>>>> I actually don't know about documentation. I was talking to Ilias to make
>>>>>> sure that documentation is up2date because there are missing couple of
>>>>>> things there.
>>>>>
>>>>> Sughosh should have more to say here about A/B update.
>>>>>
>>>>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
>>>>>> are not automatically accepted and waiting for acceptance capsule to be
>>>>>> passed.
>>>>>> When I tested it I found out that they are not process that's why I created
>>>>>> this patch.
>>>>>
>>>>> The path you tried to modify is only executed by "efidebug capsule update"
>>>>> or more specifically via the runtime service, UPDATE_CAPSULE.
>>>>>
>>>>> But this API is NOT officially supported in the current capsule implementation
>>>>> (at least, in my initial intention).
>>>>> The only way to invoke capsule updates is to reboot the system.
>>>>> If you want to test A/B update, please do the reboot.
>>>>
>>>> I realized that to get full flow you need to use capsule update on disk to get
>>>> all functionalities. But it is very impractical. Actually I would expect via
>>>> efidebug you should be able to perform all steps as capsule update performs when
>>>> you do reboot.
>>>> I would also understand that via efidebug you are not able to apply any capsule
>>>> but I don't think it is right that you can apply just update capsules but not
>>>> empty capsules. I would understand none or all but not something in the middle.
>>>
>>> The A/B update functionality requires using the capsule-on-disk
>>> functionality for performing the updates. This is also mentioned in
>>> the fwu_updates.rst document. You should be able to apply empty
>>> capsules even with the 'efidebug disk-update' command.
>>
>> Yes this is working fine.
>>
>> ZynqMP> efidebug capsule disk-update
>> #####
>> Applying capsule capsule1.bin succeeded.
>> #########################
>> Applying capsule capsule2.bin succeeded.
>> Reboot after firmware update.
>>
>> I tested it also with empty capsules which are also process properly.
>>
>>> I have never
>>> used the 'efidebug capsule update' command, so I'm not sure if that is
>>> supported. Like Takahiro mentioned, if you place the capsules(genuine
>>> or empty) under the /EFI/UpdateCapsule/ directory, the update should
>>> happen automatically, since the fwu update feature also enables the
>>> EFI_CAPSULE_ON_DISK_EARLY config.
>>
>> Yes that's work fine on production systems.
>> But from my point of view there shouldn't be really a problem to also apply
>> empty capsule via efidebug capsule update to be able to see that steps and
>> changes in mdata structure without performing reset.
> 
> The 'efidebug capsule update' command calls the efi_update_capsule
> function, which implements the UpdateCapsule runtime service call. The
> initial versions of my fwu patches were indeed adding support for this
> path, but one of the review comments was to restrict support only for
> the capsule-on-disk path when performing the update in u-boot, since
> we are not using the runtime call in u-boot.

I don't think this is a valid argument. As I said I would understand if there is 
no interface for any capsule. It means having support for both or none is IMHO 
the way we should support.
Can you please point me to that discussion?

Thanks,
Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Sughosh Ganu]

On Thu, 20 Jul 2023 at 14:56, Michal Simek <michal.simek@amd.com> wrote:
>
>
>
> On 7/20/23 10:45, Sughosh Ganu wrote:
> > On Thu, 20 Jul 2023 at 13:26, Michal Simek <michal.simek@amd.com> wrote:
> >>
> >>
> >>
> >> On 7/20/23 08:36, Sughosh Ganu wrote:
> >>> On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> On 7/20/23 07:49, AKASHI Takahiro wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
> >>>>>>> On 13.07.23 16:35, Michal Simek wrote:
> >>>>>>>> Empty capsule are also allowed to be process. Without it updated images
> >>>>>>>> can't change their Image Acceptance state from no to yes.
> >>>>>>>
> >>>>>>> Is there any documentation describing the usage of empty capsule to set
> >>>>>>> the image acceptance state?
> >>>>>>
> >>>>>> I actually don't know about documentation. I was talking to Ilias to make
> >>>>>> sure that documentation is up2date because there are missing couple of
> >>>>>> things there.
> >>>>>
> >>>>> Sughosh should have more to say here about A/B update.
> >>>>>
> >>>>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
> >>>>>> are not automatically accepted and waiting for acceptance capsule to be
> >>>>>> passed.
> >>>>>> When I tested it I found out that they are not process that's why I created
> >>>>>> this patch.
> >>>>>
> >>>>> The path you tried to modify is only executed by "efidebug capsule update"
> >>>>> or more specifically via the runtime service, UPDATE_CAPSULE.
> >>>>>
> >>>>> But this API is NOT officially supported in the current capsule implementation
> >>>>> (at least, in my initial intention).
> >>>>> The only way to invoke capsule updates is to reboot the system.
> >>>>> If you want to test A/B update, please do the reboot.
> >>>>
> >>>> I realized that to get full flow you need to use capsule update on disk to get
> >>>> all functionalities. But it is very impractical. Actually I would expect via
> >>>> efidebug you should be able to perform all steps as capsule update performs when
> >>>> you do reboot.
> >>>> I would also understand that via efidebug you are not able to apply any capsule
> >>>> but I don't think it is right that you can apply just update capsules but not
> >>>> empty capsules. I would understand none or all but not something in the middle.
> >>>
> >>> The A/B update functionality requires using the capsule-on-disk
> >>> functionality for performing the updates. This is also mentioned in
> >>> the fwu_updates.rst document. You should be able to apply empty
> >>> capsules even with the 'efidebug disk-update' command.
> >>
> >> Yes this is working fine.
> >>
> >> ZynqMP> efidebug capsule disk-update
> >> #####
> >> Applying capsule capsule1.bin succeeded.
> >> #########################
> >> Applying capsule capsule2.bin succeeded.
> >> Reboot after firmware update.
> >>
> >> I tested it also with empty capsules which are also process properly.
> >>
> >>> I have never
> >>> used the 'efidebug capsule update' command, so I'm not sure if that is
> >>> supported. Like Takahiro mentioned, if you place the capsules(genuine
> >>> or empty) under the /EFI/UpdateCapsule/ directory, the update should
> >>> happen automatically, since the fwu update feature also enables the
> >>> EFI_CAPSULE_ON_DISK_EARLY config.
> >>
> >> Yes that's work fine on production systems.
> >> But from my point of view there shouldn't be really a problem to also apply
> >> empty capsule via efidebug capsule update to be able to see that steps and
> >> changes in mdata structure without performing reset.
> >
> > The 'efidebug capsule update' command calls the efi_update_capsule
> > function, which implements the UpdateCapsule runtime service call. The
> > initial versions of my fwu patches were indeed adding support for this
> > path, but one of the review comments was to restrict support only for
> > the capsule-on-disk path when performing the update in u-boot, since
> > we are not using the runtime call in u-boot.
>
> I don't think this is a valid argument. As I said I would understand if there is
> no interface for any capsule. It means having support for both or none is IMHO
> the way we should support.
> Can you please point me to that discussion?

There is mention of the point in this discussion [1]. Even this thread
has Takahiro mention the point he is making above, that maybe there
shouldn't be the efi_update_capsule function.

-sughosh

[1] - https://lists.denx.de/pipermail/u-boot/2022-February/473891.html

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Heinrich Schuchardt]

On 7/20/23 11:48, Sughosh Ganu wrote:
> On Thu, 20 Jul 2023 at 14:56, Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 7/20/23 10:45, Sughosh Ganu wrote:
>>> On Thu, 20 Jul 2023 at 13:26, Michal Simek <michal.simek@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/20/23 08:36, Sughosh Ganu wrote:
>>>>> On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 7/20/23 07:49, AKASHI Takahiro wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 7/18/23 17:41, Heinrich Schuchardt wrote:
>>>>>>>>> On 13.07.23 16:35, Michal Simek wrote:
>>>>>>>>>> Empty capsule are also allowed to be process. Without it updated images
>>>>>>>>>> can't change their Image Acceptance state from no to yes.
>>>>>>>>>
>>>>>>>>> Is there any documentation describing the usage of empty capsule to set
>>>>>>>>> the image acceptance state?
>>>>>>>>
>>>>>>>> I actually don't know about documentation. I was talking to Ilias to make
>>>>>>>> sure that documentation is up2date because there are missing couple of
>>>>>>>> things there.
>>>>>>>
>>>>>>> Sughosh should have more to say here about A/B update.
>>>>>>>
>>>>>>>> I am testing A/B update and if you setup oemflags to 0x8000 then capsules
>>>>>>>> are not automatically accepted and waiting for acceptance capsule to be
>>>>>>>> passed.
>>>>>>>> When I tested it I found out that they are not process that's why I created
>>>>>>>> this patch.
>>>>>>>
>>>>>>> The path you tried to modify is only executed by "efidebug capsule update"
>>>>>>> or more specifically via the runtime service, UPDATE_CAPSULE.
>>>>>>>
>>>>>>> But this API is NOT officially supported in the current capsule implementation
>>>>>>> (at least, in my initial intention).
>>>>>>> The only way to invoke capsule updates is to reboot the system.
>>>>>>> If you want to test A/B update, please do the reboot.
>>>>>>
>>>>>> I realized that to get full flow you need to use capsule update on disk to get
>>>>>> all functionalities. But it is very impractical. Actually I would expect via
>>>>>> efidebug you should be able to perform all steps as capsule update performs when
>>>>>> you do reboot.
>>>>>> I would also understand that via efidebug you are not able to apply any capsule
>>>>>> but I don't think it is right that you can apply just update capsules but not
>>>>>> empty capsules. I would understand none or all but not something in the middle.
>>>>>
>>>>> The A/B update functionality requires using the capsule-on-disk
>>>>> functionality for performing the updates. This is also mentioned in
>>>>> the fwu_updates.rst document. You should be able to apply empty
>>>>> capsules even with the 'efidebug disk-update' command.
>>>>
>>>> Yes this is working fine.
>>>>
>>>> ZynqMP> efidebug capsule disk-update
>>>> #####
>>>> Applying capsule capsule1.bin succeeded.
>>>> #########################
>>>> Applying capsule capsule2.bin succeeded.
>>>> Reboot after firmware update.
>>>>
>>>> I tested it also with empty capsules which are also process properly.
>>>>
>>>>> I have never
>>>>> used the 'efidebug capsule update' command, so I'm not sure if that is
>>>>> supported. Like Takahiro mentioned, if you place the capsules(genuine
>>>>> or empty) under the /EFI/UpdateCapsule/ directory, the update should
>>>>> happen automatically, since the fwu update feature also enables the
>>>>> EFI_CAPSULE_ON_DISK_EARLY config.
>>>>
>>>> Yes that's work fine on production systems.
>>>> But from my point of view there shouldn't be really a problem to also apply
>>>> empty capsule via efidebug capsule update to be able to see that steps and
>>>> changes in mdata structure without performing reset.
>>>
>>> The 'efidebug capsule update' command calls the efi_update_capsule
>>> function, which implements the UpdateCapsule runtime service call. The
>>> initial versions of my fwu patches were indeed adding support for this
>>> path, but one of the review comments was to restrict support only for
>>> the capsule-on-disk path when performing the update in u-boot, since
>>> we are not using the runtime call in u-boot.
>>
>> I don't think this is a valid argument. As I said I would understand if there is
>> no interface for any capsule. It means having support for both or none is IMHO
>> the way we should support.
>> Can you please point me to that discussion?
>
> There is mention of the point in this discussion [1]. Even this thread
> has Takahiro mention the point he is making above, that maybe there
> shouldn't be the efi_update_capsule function.
>
> -sughosh

Hello Sugosh,

fwu_empty_capsule() detects an empty capsule as one with a GUID
fwu_guid_os_request_fw_revert or fwu_guid_os_request_fw_accept.

I am not aware of a requirement in the UEFI specification to treat
capsules read from file in a different way than capsules passed via
UpdateCapsule(). Is there any reason why UpdateCapsule() should not
process an empty capsule when called from a boot-time EFI application?

Best regards

Heinrich

>
> [1] - https://lists.denx.de/pipermail/u-boot/2022-February/473891.html

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[AKASHI Takahiro]

On Thu, Jul 20, 2023 at 10:42:10PM +0200, Heinrich Schuchardt wrote:
> On 7/20/23 11:48, Sughosh Ganu wrote:
> > On Thu, 20 Jul 2023 at 14:56, Michal Simek <michal.simek@amd.com> wrote:
> > > 
> > > 
> > > 
> > > On 7/20/23 10:45, Sughosh Ganu wrote:
> > > > On Thu, 20 Jul 2023 at 13:26, Michal Simek <michal.simek@amd.com> wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > On 7/20/23 08:36, Sughosh Ganu wrote:
> > > > > > On Thu, 20 Jul 2023 at 11:37, Michal Simek <michal.simek@amd.com> wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On 7/20/23 07:49, AKASHI Takahiro wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On Wed, Jul 19, 2023 at 08:28:41AM +0200, Michal Simek wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > On 7/18/23 17:41, Heinrich Schuchardt wrote:
> > > > > > > > > > On 13.07.23 16:35, Michal Simek wrote:
> > > > > > > > > > > Empty capsule are also allowed to be process. Without it updated images
> > > > > > > > > > > can't change their Image Acceptance state from no to yes.
> > > > > > > > > > 
> > > > > > > > > > Is there any documentation describing the usage of empty capsule to set
> > > > > > > > > > the image acceptance state?
> > > > > > > > > 
> > > > > > > > > I actually don't know about documentation. I was talking to Ilias to make
> > > > > > > > > sure that documentation is up2date because there are missing couple of
> > > > > > > > > things there.
> > > > > > > > 
> > > > > > > > Sughosh should have more to say here about A/B update.
> > > > > > > > 
> > > > > > > > > I am testing A/B update and if you setup oemflags to 0x8000 then capsules
> > > > > > > > > are not automatically accepted and waiting for acceptance capsule to be
> > > > > > > > > passed.
> > > > > > > > > When I tested it I found out that they are not process that's why I created
> > > > > > > > > this patch.
> > > > > > > > 
> > > > > > > > The path you tried to modify is only executed by "efidebug capsule update"
> > > > > > > > or more specifically via the runtime service, UPDATE_CAPSULE.
> > > > > > > > 
> > > > > > > > But this API is NOT officially supported in the current capsule implementation
> > > > > > > > (at least, in my initial intention).
> > > > > > > > The only way to invoke capsule updates is to reboot the system.
> > > > > > > > If you want to test A/B update, please do the reboot.
> > > > > > > 
> > > > > > > I realized that to get full flow you need to use capsule update on disk to get
> > > > > > > all functionalities. But it is very impractical. Actually I would expect via
> > > > > > > efidebug you should be able to perform all steps as capsule update performs when
> > > > > > > you do reboot.
> > > > > > > I would also understand that via efidebug you are not able to apply any capsule
> > > > > > > but I don't think it is right that you can apply just update capsules but not
> > > > > > > empty capsules. I would understand none or all but not something in the middle.
> > > > > > 
> > > > > > The A/B update functionality requires using the capsule-on-disk
> > > > > > functionality for performing the updates. This is also mentioned in
> > > > > > the fwu_updates.rst document. You should be able to apply empty
> > > > > > capsules even with the 'efidebug disk-update' command.
> > > > > 
> > > > > Yes this is working fine.
> > > > > 
> > > > > ZynqMP> efidebug capsule disk-update
> > > > > #####
> > > > > Applying capsule capsule1.bin succeeded.
> > > > > #########################
> > > > > Applying capsule capsule2.bin succeeded.
> > > > > Reboot after firmware update.
> > > > > 
> > > > > I tested it also with empty capsules which are also process properly.
> > > > > 
> > > > > > I have never
> > > > > > used the 'efidebug capsule update' command, so I'm not sure if that is
> > > > > > supported. Like Takahiro mentioned, if you place the capsules(genuine
> > > > > > or empty) under the /EFI/UpdateCapsule/ directory, the update should
> > > > > > happen automatically, since the fwu update feature also enables the
> > > > > > EFI_CAPSULE_ON_DISK_EARLY config.
> > > > > 
> > > > > Yes that's work fine on production systems.
> > > > > But from my point of view there shouldn't be really a problem to also apply
> > > > > empty capsule via efidebug capsule update to be able to see that steps and
> > > > > changes in mdata structure without performing reset.
> > > > 
> > > > The 'efidebug capsule update' command calls the efi_update_capsule
> > > > function, which implements the UpdateCapsule runtime service call. The
> > > > initial versions of my fwu patches were indeed adding support for this
> > > > path, but one of the review comments was to restrict support only for
> > > > the capsule-on-disk path when performing the update in u-boot, since
> > > > we are not using the runtime call in u-boot.
> > > 
> > > I don't think this is a valid argument. As I said I would understand if there is
> > > no interface for any capsule. It means having support for both or none is IMHO
> > > the way we should support.
> > > Can you please point me to that discussion?
> > 
> > There is mention of the point in this discussion [1]. Even this thread
> > has Takahiro mention the point he is making above, that maybe there
> > shouldn't be the efi_update_capsule function.
> > 
> > -sughosh
> 
> Hello Sugosh,
> 
> fwu_empty_capsule() detects an empty capsule as one with a GUID
> fwu_guid_os_request_fw_revert or fwu_guid_os_request_fw_accept.
> 
> I am not aware of a requirement in the UEFI specification to treat
> capsules read from file in a different way than capsules passed via
> UpdateCapsule(). Is there any reason why UpdateCapsule() should not
> process an empty capsule when called from a boot-time EFI application?

Here is a story behind efi_update_capsule():
===
commit a6aafce494ab
Author: Masami Hiramatsu <masami.hiramatsu@linaro.org>
Date:   Wed Feb 16 15:15:42 2022 +0900

    efi_loader: use efi_update_capsule_firmware() for capsule on disk
===

I still believe that this is a valid change, but we should have
moved 'capsule->capsule_guid' check into efi_update_capsule_firmware()
at the same time.

-Takahiro Akashi



> Best regards
> 
> Heinrich
> 
> > 
> > [1] - https://lists.denx.de/pipermail/u-boot/2022-February/473891.html
> 

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Ilias Apalodimas]

Hi all

[...]

> > >
> >
> > Hello Sugosh,
> >
> > fwu_empty_capsule() detects an empty capsule as one with a GUID
> > fwu_guid_os_request_fw_revert or fwu_guid_os_request_fw_accept.
> >
> > I am not aware of a requirement in the UEFI specification to treat
> > capsules read from file in a different way than capsules passed via
> > UpdateCapsule(). Is there any reason why UpdateCapsule() should not
> > process an empty capsule when called from a boot-time EFI application?
>
> Here is a story behind efi_update_capsule():
> ===
> commit a6aafce494ab
> Author: Masami Hiramatsu <masami.hiramatsu@linaro.org>
> Date:   Wed Feb 16 15:15:42 2022 +0900
>
>     efi_loader: use efi_update_capsule_firmware() for capsule on disk
> ===
>
> I still believe that this is a valid change, but we should have
> moved 'capsule->capsule_guid' check into efi_update_capsule_firmware()
> at the same time.

I agree with Akashi-san here.  I am also fine with this patchset since
running the A/B update from an EFI app should work. But can we do a v2
with 2 patches?
#1 move the capsule check along with the empty capsule checks in
efi_update_capsule_firmware()
#2 fix the a/b updates via the runtime calls and adjust the commit
message accordingly, explaining why this change is needed?

Thanks
/Ilias
>
> -Takahiro Akashi
>
>
>
> > Best regards
> >
> > Heinrich
> >
> > >
> > > [1] - https://lists.denx.de/pipermail/u-boot/2022-February/473891.html
> >

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Michal Simek]

On 7/26/23 15:07, Ilias Apalodimas wrote:
> Hi all
> 
> [...]
> 
>>>>
>>>
>>> Hello Sugosh,
>>>
>>> fwu_empty_capsule() detects an empty capsule as one with a GUID
>>> fwu_guid_os_request_fw_revert or fwu_guid_os_request_fw_accept.
>>>
>>> I am not aware of a requirement in the UEFI specification to treat
>>> capsules read from file in a different way than capsules passed via
>>> UpdateCapsule(). Is there any reason why UpdateCapsule() should not
>>> process an empty capsule when called from a boot-time EFI application?
>>
>> Here is a story behind efi_update_capsule():
>> ===
>> commit a6aafce494ab
>> Author: Masami Hiramatsu <masami.hiramatsu@linaro.org>
>> Date:   Wed Feb 16 15:15:42 2022 +0900
>>
>>      efi_loader: use efi_update_capsule_firmware() for capsule on disk
>> ===
>>
>> I still believe that this is a valid change, but we should have
>> moved 'capsule->capsule_guid' check into efi_update_capsule_firmware()
>> at the same time.
> 
> I agree with Akashi-san here.  I am also fine with this patchset since
> running the A/B update from an EFI app should work. But can we do a v2
> with 2 patches?
> #1 move the capsule check along with the empty capsule checks in
> efi_update_capsule_firmware()
> #2 fix the a/b updates via the runtime calls and adjust the commit
> message accordingly, explaining why this change is needed?

Can someone from Linaro create v2 on this?
I just wanted to pointed to it.

Thanks,
Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[AKASHI Takahiro]

Hi Michal, Sughosh,

On Wed, Jul 26, 2023 at 06:36:56PM +0200, Michal Simek wrote:
> 
> 
> On 7/26/23 15:07, Ilias Apalodimas wrote:
> > Hi all
> > 
> > [...]
> > 
> > > > > 
> > > > 
> > > > Hello Sugosh,
> > > > 
> > > > fwu_empty_capsule() detects an empty capsule as one with a GUID
> > > > fwu_guid_os_request_fw_revert or fwu_guid_os_request_fw_accept.
> > > > 
> > > > I am not aware of a requirement in the UEFI specification to treat
> > > > capsules read from file in a different way than capsules passed via
> > > > UpdateCapsule(). Is there any reason why UpdateCapsule() should not
> > > > process an empty capsule when called from a boot-time EFI application?
> > > 
> > > Here is a story behind efi_update_capsule():
> > > ===
> > > commit a6aafce494ab
> > > Author: Masami Hiramatsu <masami.hiramatsu@linaro.org>
> > > Date:   Wed Feb 16 15:15:42 2022 +0900
> > > 
> > >      efi_loader: use efi_update_capsule_firmware() for capsule on disk
> > > ===
> > > 
> > > I still believe that this is a valid change, but we should have
> > > moved 'capsule->capsule_guid' check into efi_update_capsule_firmware()
> > > at the same time.
> > 
> > I agree with Akashi-san here.  I am also fine with this patchset since
> > running the A/B update from an EFI app should work. But can we do a v2
> > with 2 patches?
> > #1 move the capsule check along with the empty capsule checks in
> > efi_update_capsule_firmware()
> > #2 fix the a/b updates via the runtime calls and adjust the commit
> > message accordingly, explaining why this change is needed?
> 
> Can someone from Linaro create v2 on this?
> I just wanted to pointed to it.

Yes, I posted "efi_loader: capsule: enforce guid check in api and
capsule_on_disk".
Since I didn't run any test against A/B update, can you please
confirm that this patch works in your environment?

Unlike Ilias suggested, I made a single patch because an empty
capsule will be handled any way at the beginning of
efi_capsule_update_firmware() and we process only normal capsules
after that.

-Takahiro Akashi

> Thanks,
> Michal

Re: [PATCH] efi_loader: Allow also empty capsule to be process

[Ilias Apalodimas]

Hi Heinirch,


On Tue, 18 Jul 2023 at 18:41, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 13.07.23 16:35, Michal Simek wrote:
> > Empty capsule are also allowed to be process. Without it updated images
> > can't change their Image Acceptance state from no to yes.
>
> Is there any documentation describing the usage of empty capsule to set
> the image acceptance state?

Yes, there is. It's described here along with the relevant uuids

[0] https://gitlab.com/Linaro/trustedsubstrate/mbfw/uploads/3d0d7d11ca9874dc9115616b418aa330/mbfw.pdf
"2.3.3 OS directed FW image acceptance"

Regards
/Ilias
>
> Best regards
>
> Heinrich
>
> >
> > Signed-off-by: Michal Simek <michal.simek@amd.com>
> > ---
> >
> >   lib/efi_loader/efi_capsule.c | 3 ++-
> >   1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index 7a6f195cbc02..93e83e5f04c3 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -752,7 +752,8 @@ efi_status_t EFIAPI efi_update_capsule(
> >               log_debug("Capsule[%d] (guid:%pUs)\n",
> >                         i, &capsule->capsule_guid);
> >               if (!guidcmp(&capsule->capsule_guid,
> > -                          &efi_guid_firmware_management_capsule_id)) {
> > +                          &efi_guid_firmware_management_capsule_id) ||
> > +                 fwu_empty_capsule(capsule)) {
> >                       ret  = efi_capsule_update_firmware(capsule);
> >               } else {
> >                       log_err("Unsupported capsule type: %pUs\n",
>