[i.MX8M Mini EVK] [ARM SystemReady IR] Building EFI Capsule update support

[rohitdubey]

We're trying to build support for EFI Capsule update into a Yocto build for i.MX8M Mini EVK board, however we noticed several required config items missing from the .config file.

From matching the versions, it seems like the bootloader with System Ready IR support (published on the downloads page)  came from the below manifest: 

https://source.codeaurora.org/external/imx/imx-manifest/tree/imx-5.10.52-2.1.0.xml?h=imx-linux-hardk...

However, when trying to build using the above manifest, it seems to be missing several config items required for supporting EFI Capsule update, as detailed here:

https://u-boot.readthedocs.io/en/stable/board/emulation/qemu_capsule_update.html

Are there any modifications required to build the bootloader with support for ARM SystemReady IR (and Capsule update)?

[AldoG]

Hello,

You may refer to the following to build a generic SystemReady IR Yocto image:
https://developer.arm.com/documentation/DUI1102/0100/Example--deployment-on-an-NXP-board

Also, the following may be of help:
https://developer.arm.com/documentation/DUI1101/a/Appendix--Test-SystemReady-IR---IoT-for-QEMU?lang=...

Best regards,
Aldo.

[rohitdubey]

Thanks Aldo,

The link above refers to a config option, CONFIG_EFI_CAPSULE_FMP_HEADER. However the option doesn't seem to be referenced anywhere except a documentation file.

We built a u-boot image with debugging enabled (CONFIG_LOG_MAX_LEVEL) for our board based on the i.MX8MM EVK with the debug messages enabled. When attempting the capsule update, it prints out the below messages indicating that the support for the Firmware Management Protocol GUID is missing:

lib/efi_loader/efi_capsule.c:470-efi_update_capsule() Capsule[0] (guid:6dcbd5ed-e82d-4c44-bda1-7194199ad92a)

lib/efi_loader/efi_capsule.c:360-efi_capsule_update_firmware()     EFI: Call: efi_locate_handle_buffer( BY_PROTOCOL, &efi_guid_firmware_management_protocol, NULL, &no_handles, (efi_handle_t **)&handles)

lib/efi_loader/efi_boottime.c:2476-efi_locate_handle_buffer()       EFI: Entry efi_locate_handle_buffer(2, 86c77a67-0b97-4633-a187-49104d0685c7, 0000000000000000, 00000000bded19c0, 00000000bded19b8)

lib/efi_loader/efi_boottime.c:2498-efi_locate_handle_buffer()       EFI: Exit: efi_locate_handle_buffer: 14

lib/efi_loader/efi_capsule.c:360-efi_capsule_update_firmware()     EFI: 14 returned by efi_locate_handle_buffer( BY_PROTOCOL, &efi_guid_firmware_management_protocol, NULL, &no_handles, (efi_handle_t **)&handles)

lib/efi_loader/efi_capsule.c:485-efi_update_capsule()   EFI: Exit: efi_update_capsule: 3

cmd/efidebug.c:75-do_efi_capsule_update() EFI: 3 returned by RT->update_capsule(&capsule, 1, 0)

Cannot handle a capsule at 0000000040480000common/command.c:582-cmd_call() Command failed, result=1

The line "EFI: Exit: efi_locate_handle_buffer: 14" indicates a return code of EFI_NOT_FOUND when attempting to locate handle buffer for the protocol.

I'd appreciate any suggestions about this error, and if it's related to the above config option.

[rohitdubey · Accepted solution]

Hi,

I've noticed that the above failure doesn't happen if I reset the board after the failure and try again. My best guess is that this may be related to the EFI variables being initialized on the EFI System Partition.

On second attempt, the capsule update using the "efidebug capsule update -v ${loadaddr}" command seems to succeed (after correctly setting up dfu_alt_info and other variables mentioned in the procedure).

The Config option CONFIG_EFI_CAPSULE_FMP_HEADER seems to be only mentioned once in a documentation file (doc/board/emulation/qemu_capsule_update.rst) and isn't referred to anywhere else in the source for U-Boot 2021.04 so I suspect it is not required here.