[PATCH] efi_loader: capsule: enforce guid check in api and capsule_on_disk
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk") Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org --- lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; }
+ if (guidcmp(&capsule_data->capsule_guid, + &efi_guid_firmware_management_capsule_id)) { + log_err("Unsupported capsule type: %pUs\n", + &capsule_data->capsule_guid); + return EFI_UNSUPPORTED; + } + /* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size) @@ -751,15 +758,7 @@ 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)) { - ret = efi_capsule_update_firmware(capsule); - } else { - log_err("Unsupported capsule type: %pUs\n", - &capsule->capsule_guid); - ret = EFI_UNSUPPORTED; - } - + ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) goto out; }
On 7/27/23 02:38, AKASHI Takahiro wrote:
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
just fyi: b4 mess this. You should likely put it on the same line and ignore line limit.
This is how this ends up.
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
for capsule on disk")
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org Link: https://lore.kernel.org/r/20230727003800.25105-1-takahiro.akashi@linaro.org
Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; }
- if (guidcmp(&capsule_data->capsule_guid,
&efi_guid_firmware_management_capsule_id)) {log_err("Unsupported capsule type: %pUs\n",&capsule_data->capsule_guid);return EFI_UNSUPPORTED;- }
- /* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size)
@@ -751,15 +758,7 @@ 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)) {ret = efi_capsule_update_firmware(capsule);} else {log_err("Unsupported capsule type: %pUs\n",&capsule->capsule_guid);ret = EFI_UNSUPPORTED;}
ret = efi_capsule_update_firmware(capsule);
I have no problem with this patch because it works as the previous one. When commit message is fixed feel free to add Tested-by: Michal Simek michal.simek@amd.com
And regarding empty capsule functionality with A/B. I boot from A. Download capsules and run disk-update to get to Image B and trial state and I can download and apply acceptance capsule by hand via efidebug capsule update <addr>. That works fine for acceptance capsule is reflected via fwu in mdata. When I apply revert capsule there is nothing visible in mdata and I think it should. The only visibility is that it resets to A system. Is this the only intention of revert capsules? (keep in mind that I use two images per bank).
Empty capsules are just accepted only in trial state which is understandable.
And I also see that with latest master branch capsule on disk feature is not working properly. Capsule are not processed at all. Can you please double check it?
Thanks, Michal
Hi Michal,
On Thu, Jul 27, 2023 at 10:53:44AM +0200, Michal Simek wrote:
On 7/27/23 02:38, AKASHI Takahiro wrote:
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
just fyi: b4 mess this. You should likely put it on the same line and ignore line limit.
This is how this ends up.
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
for capsule on disk")Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org Link: https://lore.kernel.org/r/20230727003800.25105-1-takahiro.akashi@linaro.org
Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; }
- if (guidcmp(&capsule_data->capsule_guid,
&efi_guid_firmware_management_capsule_id)) {log_err("Unsupported capsule type: %pUs\n",&capsule_data->capsule_guid);return EFI_UNSUPPORTED;- }
- /* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size)
@@ -751,15 +758,7 @@ 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)) {ret = efi_capsule_update_firmware(capsule);} else {log_err("Unsupported capsule type: %pUs\n",&capsule->capsule_guid);ret = EFI_UNSUPPORTED;}
ret = efi_capsule_update_firmware(capsule);I have no problem with this patch because it works as the previous one. When commit message is fixed feel free to add Tested-by: Michal Simek michal.simek@amd.com
I hope that the maintainer would take care of it when he tries to merge the patch.
And regarding empty capsule functionality with A/B. I boot from A. Download capsules and run disk-update to get to Image B and trial state and I can download and apply acceptance capsule by hand via efidebug capsule update <addr>. That works fine for acceptance capsule is reflected via fwu in mdata. When I apply revert capsule there is nothing visible in mdata and I think it should. The only visibility is that it resets to A system. Is this the only intention of revert capsules? (keep in mind that I use two images per bank).
Empty capsules are just accepted only in trial state which is understandable.
And I also see that with latest master branch capsule on disk feature is not working properly. Capsule are not processed at all. Can you please double check it?
I locally ran the pytest with v2023.10-rc1, and - test_capsule_firmware_raw passed - test_capsule_firmware_signed_raw failed
but it seems to me that 'signed_raw' failure is not directly related to efi implementation (I didn't dig into details, though).
Can you describe more about your environment?
-Takahiro Akashi
Thanks, Michal
On 7/28/23 03:55, AKASHI Takahiro wrote:
Hi Michal,
On Thu, Jul 27, 2023 at 10:53:44AM +0200, Michal Simek wrote:
On 7/27/23 02:38, AKASHI Takahiro wrote:
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
just fyi: b4 mess this. You should likely put it on the same line and ignore line limit.
This is how this ends up.
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
for capsule on disk")Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org Link: https://lore.kernel.org/r/20230727003800.25105-1-takahiro.akashi@linaro.org
Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; }
- if (guidcmp(&capsule_data->capsule_guid,
&efi_guid_firmware_management_capsule_id)) {log_err("Unsupported capsule type: %pUs\n",&capsule_data->capsule_guid);return EFI_UNSUPPORTED;- }
- /* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size)
@@ -751,15 +758,7 @@ 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)) {ret = efi_capsule_update_firmware(capsule);} else {log_err("Unsupported capsule type: %pUs\n",&capsule->capsule_guid);ret = EFI_UNSUPPORTED;}
ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) goto out;I have no problem with this patch because it works as the previous one. When commit message is fixed feel free to add Tested-by: Michal Simek michal.simek@amd.com
I hope that the maintainer would take care of it when he tries to merge the patch.
And regarding empty capsule functionality with A/B. I boot from A. Download capsules and run disk-update to get to Image B and trial state and I can download and apply acceptance capsule by hand via efidebug capsule update <addr>. That works fine for acceptance capsule is reflected via fwu in mdata. When I apply revert capsule there is nothing visible in mdata and I think it should. The only visibility is that it resets to A system. Is this the only intention of revert capsules? (keep in mind that I use two images per bank).
Empty capsules are just accepted only in trial state which is understandable.
And I also see that with latest master branch capsule on disk feature is not working properly. Capsule are not processed at all. Can you please double check it?
I locally ran the pytest with v2023.10-rc1, and
- test_capsule_firmware_raw passed
- test_capsule_firmware_signed_raw failed
but it seems to me that 'signed_raw' failure is not directly related to efi implementation (I didn't dig into details, though).
Can you describe more about your environment?
Let me c&p log to see what I do. 2023.07-rc6 saving capsules on SD card and initiating capsule update on disk. Reset is called automatically. Checking status and downloading empty acceptance capsules and applying them by hand. Calling reset to get out of TrialState. Downloading the same capsules as before and placing them to SD card. Calling disk update by hand - nothing happens, checking location. Capsules are present. Resetting to B image to check if u-boot picks them up after reset and nothing happened.
Thanks, Michal
<debug_uart>
U-Boot SPL 2023.07-rc6-00347-g4b54c7a398e5 (Jul 14 2023 - 10:28:29 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 Silicon version: 3 EL Level: EL3 Secure Boot: not authenticated, not encrypted Multiboot: 64 Trying to boot from SPI spl_spi_get_uboot_offs: Offset of u-boot.itb should be at 0x280000 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
U-Boot 2023.07-rc6-00347-g4b54c7a398e5 (Jul 14 2023 - 10:28:29 +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 zynq_serial_setbrg: CLK 99999999 zynq_serial_setbrg: CLK 99999999 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: 0, active_idx: 1 Boot idx 0 is not matching active idx 1, changing active_idx tpm_tis_spi_probe: missing reset GPIO 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> dhcp ethernet@ff0e0000 Waiting for PHY auto negotiation to complete.... done BOOTP broadcast 1 DHCP client bound to address 192.168.0.155 (6 ms) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1.bin && save mmc 1 0x100000 /EFI/UpdateCapsule/capsule1.bin ${filesize} Using ethernet@ff0e0000 device TFTP from server 192.168.0.105; our IP address is 192.168.0.155 Filename 'capsule1.bin'. Load address: 0x100000 Loading: ######################################################## 2.9 MiB/s done Bytes transferred = 283160 (45218 hex) 283160 bytes written in 793 ms (348.6 KiB/s) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2.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 'capsule2.bin'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.3 MiB/s done Bytes transferred = 1952940 (1dccac hex) 1952940 bytes written in 996 ms (1.9 MiB/s) ZynqMP> efidebug capsule disk-update ##### Applying capsule capsule1.bin succeeded. ############################## Applying capsule capsule2.bin succeeded. Reboot after firmware update. Rebooting to index 1 <debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 j��"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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> 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 (6 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: # 7.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 ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2-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 'capsule2-accept.bin'. Load address: 0x100000 Loading: # 10.7 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 ZynqMP> reset resetting ... Rebooting to index 1 <debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 j��"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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 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> dhcp ethernet@ff0e0000 Waiting for PHY auto negotiation to complete... done BOOTP broadcast 1 DHCP client bound to address 192.168.0.155 (7 ms) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1.bin && save mmc 1 0x100000 /EFI/UpdateCapsule/capsule1.bin ${filesize} Using ethernet@ff0e0000 device TFTP from server 192.168.0.105; our IP address is 192.168.0.155 Filename 'capsule1.bin'. Load address: 0x100000 Loading: ######################################################## 2.8 MiB/s done Bytes transferred = 283160 (45218 hex) 283160 bytes written in 787 ms (350.6 KiB/s) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2.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 'capsule2.bin'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.5 MiB/s done Bytes transferred = 1952940 (1dccac hex) 1952940 bytes written in 997 ms (1.9 MiB/s) ZynqMP> efidebug capsule disk-update ZynqMP> ls mmc 1:1 EFI/UpdateCapsule ./ ../ 283160 capsule1.bin 1952940 capsule2.bin
2 file(s), 2 dir(s)
ZynqMP> reset resetting ... Rebooting to index 1 <debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 �H�"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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 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>
On 7/31/23 14:10, Michal Simek wrote:
On 7/28/23 03:55, AKASHI Takahiro wrote:
Hi Michal,
On Thu, Jul 27, 2023 at 10:53:44AM +0200, Michal Simek wrote:
On 7/27/23 02:38, AKASHI Takahiro wrote:
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
just fyi: b4 mess this. You should likely put it on the same line and ignore line limit.
This is how this ends up.
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
for capsule on disk")
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org Link: https://lore.kernel.org/r/20230727003800.25105-1-takahiro.akashi@linaro.org
Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; } + if (guidcmp(&capsule_data->capsule_guid, + &efi_guid_firmware_management_capsule_id)) { + log_err("Unsupported capsule type: %pUs\n", + &capsule_data->capsule_guid); + return EFI_UNSUPPORTED; + }
/* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size) @@ -751,15 +758,7 @@ 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)) { - ret = efi_capsule_update_firmware(capsule); - } else { - log_err("Unsupported capsule type: %pUs\n", - &capsule->capsule_guid); - ret = EFI_UNSUPPORTED; - }
+ ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) goto out; }
I have no problem with this patch because it works as the previous one. When commit message is fixed feel free to add Tested-by: Michal Simek michal.simek@amd.com
I hope that the maintainer would take care of it when he tries to merge the patch.
And regarding empty capsule functionality with A/B. I boot from A. Download capsules and run disk-update to get to Image B and trial state and I can download and apply acceptance capsule by hand via efidebug capsule update <addr>. That works fine for acceptance capsule is reflected via fwu in mdata. When I apply revert capsule there is nothing visible in mdata and I think it should. The only visibility is that it resets to A system. Is this the only intention of revert capsules? (keep in mind that I use two images per bank).
Empty capsules are just accepted only in trial state which is understandable.
And I also see that with latest master branch capsule on disk feature is not working properly. Capsule are not processed at all. Can you please double check it?
I locally ran the pytest with v2023.10-rc1, and
- test_capsule_firmware_raw passed
- test_capsule_firmware_signed_raw failed
but it seems to me that 'signed_raw' failure is not directly related to efi implementation (I didn't dig into details, though).
Can you describe more about your environment?
Let me c&p log to see what I do. 2023.07-rc6 saving capsules on SD card and initiating capsule update on disk. Reset is called automatically. Checking status and downloading empty acceptance capsules and applying them by hand. Calling reset to get out of TrialState. Downloading the same capsules as before and placing them to SD card. Calling disk update by hand - nothing happens, checking location. Capsules are present. Resetting to B image to check if u-boot picks them up after reset and nothing happened.
Thanks, Michal
<debug_uart>
U-Boot SPL 2023.07-rc6-00347-g4b54c7a398e5 (Jul 14 2023 - 10:28:29 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 Silicon version: 3 EL Level: EL3 Secure Boot: not authenticated, not encrypted Multiboot: 64 Trying to boot from SPI spl_spi_get_uboot_offs: Offset of u-boot.itb should be at 0x280000 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
U-Boot 2023.07-rc6-00347-g4b54c7a398e5 (Jul 14 2023 - 10:28:29 +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 zynq_serial_setbrg: CLK 99999999 zynq_serial_setbrg: CLK 99999999 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: 0, active_idx: 1 Boot idx 0 is not matching active idx 1, changing active_idx tpm_tis_spi_probe: missing reset GPIO 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> dhcp ethernet@ff0e0000 Waiting for PHY auto negotiation to complete.... done BOOTP broadcast 1 DHCP client bound to address 192.168.0.155 (6 ms) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1.bin && save mmc 1 0x100000 /EFI/UpdateCapsule/capsule1.bin ${filesize} Using ethernet@ff0e0000 device TFTP from server 192.168.0.105; our IP address is 192.168.0.155 Filename 'capsule1.bin'. Load address: 0x100000 Loading: ######################################################## 2.9 MiB/s done Bytes transferred = 283160 (45218 hex) 283160 bytes written in 793 ms (348.6 KiB/s) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2.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 'capsule2.bin'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.3 MiB/s done Bytes transferred = 1952940 (1dccac hex) 1952940 bytes written in 996 ms (1.9 MiB/s) ZynqMP> efidebug capsule disk-update ##### Applying capsule capsule1.bin succeeded. ############################## Applying capsule capsule2.bin succeeded. Reboot after firmware update. Rebooting to index 1
<debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 j��"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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> 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 (6 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: # 7.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 ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2-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 'capsule2-accept.bin'. Load address: 0x100000 Loading: # 10.7 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 ZynqMP> reset resetting ... Rebooting to index 1
<debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 j��"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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 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> dhcp ethernet@ff0e0000 Waiting for PHY auto negotiation to complete... done BOOTP broadcast 1 DHCP client bound to address 192.168.0.155 (7 ms) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1.bin && save mmc 1 0x100000 /EFI/UpdateCapsule/capsule1.bin ${filesize} Using ethernet@ff0e0000 device TFTP from server 192.168.0.105; our IP address is 192.168.0.155 Filename 'capsule1.bin'. Load address: 0x100000 Loading: ######################################################## 2.8 MiB/s done Bytes transferred = 283160 (45218 hex) 283160 bytes written in 787 ms (350.6 KiB/s) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2.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 'capsule2.bin'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.5 MiB/s done Bytes transferred = 1952940 (1dccac hex) 1952940 bytes written in 997 ms (1.9 MiB/s) ZynqMP> efidebug capsule disk-update ZynqMP> ls mmc 1:1 EFI/UpdateCapsule ./ ../ 283160 capsule1.bin 1952940 capsule2.bin
2 file(s), 2 dir(s)
ZynqMP> reset resetting ... Rebooting to index 1
<debug_uart>
U-Boot SPL 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +0200) Loading new PMUFW cfg obj (2032 bytes) PMUFW: v1.1 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-368-ge7045288cfdc NOTICE: BL31: Built : 12:37:06, Jul 27 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 �H�"��՝}Յ���jR� 0x3c9
U-Boot 2023.10-rc1-00119-g0ede489f8903 (Jul 31 2023 - 13:53:44 +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 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>
And one more thing I found. When you press CTRL+C in the middle of capsule update I get "Failure while erasing at offset 0xffffffffffffffff" message on the console but still applying capsules is successful but images are obviously not written properly (not able to boot when you go to B image).
Thanks, Michal
ZynqMP> tftpboot 0x100000 192.168.0.105:capsule1.bin && save mmc 1 0x100000 /EFI/UpdateCapsule/capsule1.bin ${filesize} Using ethernet@ff0e0000 device TFTP from server 192.168.0.105; our IP address is 192.168.0.155 Filename 'capsule1.bin'. Load address: 0x100000 Loading: ######################################################## 2.2 MiB/s done Bytes transferred = 283160 (45218 hex) 283160 bytes written in 788 ms (350.6 KiB/s) ZynqMP> tftpboot 0x100000 192.168.0.105:capsule2.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 'capsule2.bin'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.3 MiB/s done Bytes transferred = 1952940 (1dccac hex) 1952940 bytes written in 999 ms (1.9 MiB/s) ZynqMP> mtd list List of MTD devices: * nor0 - device: flash@0 - parent: spi@ff0f0000 - driver: jedec_spi_nor - path: /axi/spi@ff0f0000/flash@0 - type: NOR flash - block size: 0x10000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000004000000 : "nor0" - 0x000000000000-0x000000080000 : "Image Selector" - 0x000000080000-0x000000100000 : "Image Selector Golden" - 0x000000100000-0x000000120000 : "Persistent Register" - 0x000000120000-0x000000140000 : "Persistent Register Backup" - 0x000000140000-0x000000200000 : "Open_1" - 0x000000200000-0x000000f00000 : "Image A (FSBL, PMU, ATF, U-Boot)" - 0x000000f00000-0x000000f80000 : "ImgSel Image A Catch" - 0x000000f80000-0x000001c80000 : "Image B (FSBL, PMU, ATF, U-Boot)" - 0x000001c80000-0x000001d00000 : "ImgSel Image B Catch" - 0x000001d00000-0x000001e00000 : "Open_2" - 0x000001e00000-0x000002000000 : "Recovery Image" - 0x000002000000-0x000002200000 : "Recovery Image Backup" - 0x000002200000-0x000002220000 : "U-Boot storage variables" - 0x000002220000-0x000002240000 : "U-Boot storage variables backup" - 0x000002240000-0x000002280000 : "SHA256" - 0x000002280000-0x0000022a0000 : "Secure OS Storage" - 0x0000022a0000-0x0000028a0000 : "User1" - 0x000002300000-0x000002310000 : "MDATA-Pri" - 0x000002310000-0x000002320000 : "MDATA-Sec" - 0x000002320000-0x0000027a0000 : "ImageA" - 0x0000027a0000-0x000002c20000 : "ImageB" - 0x000002c20000-0x000004000000 : "User1" ZynqMP> mtd erase "Image B (FSBL, PMU, ATF, U-Boot)" Erasing 0x00000000 ... 0x00cfffff (208 eraseblock(s)) ZynqMP> efidebug capsule disk-update ##### Applying capsule capsule1.bin succeeded. Failure while erasing at offset 0xffffffffffffffff #########Failure while erasing at offset 0xffffffffffffffff ##################### Applying capsule capsule2.bin succeeded. Reboot after firmware update. Rebooting to index 1
Hi Akashi-san
On Thu, 27 Jul 2023 at 03:38, AKASHI Takahiro takahiro.akashi@linaro.org wrote:
While UPDATE_CAPSULE api is not fully implemented, this interface and capsule-on-disk feature should behave in the same way, especially in handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494ab ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
I think we can skip the fixes tag here, since noone was really using the feature
Other than that Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
Reported-by: Michal Simek michal.simek@amd.com Signed-off-by: AKASHI Takahiro takahiro.akashi@linaro.org
lib/efi_loader/efi_capsule.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c index 7a6f195cbc02..ddf8153e0982 100644 --- a/lib/efi_loader/efi_capsule.c +++ b/lib/efi_loader/efi_capsule.c @@ -581,6 +581,13 @@ static efi_status_t efi_capsule_update_firmware( fw_accept_os = capsule_data->flags & FW_ACCEPT_OS ? 0x1 : 0x0; }
if (guidcmp(&capsule_data->capsule_guid,&efi_guid_firmware_management_capsule_id)) {log_err("Unsupported capsule type: %pUs\n",&capsule_data->capsule_guid);return EFI_UNSUPPORTED;}/* sanity check */ if (capsule_data->header_size < sizeof(*capsule) || capsule_data->header_size >= capsule_data->capsule_image_size)@@ -751,15 +758,7 @@ 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)) {ret = efi_capsule_update_firmware(capsule);} else {log_err("Unsupported capsule type: %pUs\n",&capsule->capsule_guid);ret = EFI_UNSUPPORTED;}
ret = efi_capsule_update_firmware(capsule); if (ret != EFI_SUCCESS) goto out; }-- 2.41.0
participants (3)
-
AKASHI Takahiro -
Ilias Apalodimas -
Michal Simek