Unable to get capsule updates to work with A/B updates

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
, ,
1

Hi,

I’m trying to get A/B OTA updates working on my OrinNX, and the UEFI capsule update is failing.

I have secureboot enabled, ROOTFS_AB=1, ROOTFS_ENC=1.

Building the OTA package;

ROOTFS_ENC=1 ROOTFS_AB=1 ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh \
  --external-device nvme0n1 --uefi-keys  bootloader/uefi_keys.conf \
  --rootfs-uuid 32d98045-11f9-42a6-96f5-8442574bff82 \
  --rootfs-b-uuid f028e661-08a4-42c2-85f1-592ca5e6bf46 \
  --uda-uuid 194e77c3-427a-4304-875e-835c637e761b  \
  -i bootloader/sym2_t234.key emt_gx1 R36-4

I apply the OTA package using nv_ota_start.sh, and this runs successfully. I’ve verified that the kernel image, initrd, extlinux.conf etc. are updated in the /boot partition, and that the ‘B’ rootfs has been updated. I can see that TEGRA_BL.Cap is present in /boot/efi/EFI/UpdateCapsule/, and have verified that the EFI variable OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c is correct.

So, I reboot the board at this point. When it comes back up, I check /sys/firmware/efi/esrt/entries/entry0/last_attempt_status and it has a value of 6151. I run nvbootctrl get-current-slot, and it tells me the current slot is 0 (unchanged).

I’ve poked around in the edk source, and it appears that the vale of last_attempt_status corresponds to LAS_ERROR_IMAGE_NOT_IN_PACKAGE.

I’m a bit stuck at this point. I would prefer not to build the EDK to enable debug logging (my current serial port logs don’t contain anything relevant after I reboot, so I presume the log level isn’t DEBUG).

It’s worth mentioning that I had to apply the following to l4t_generate_ota_package.sh so that it would run successfully for me, which makes me wonder if I’m doing something wrong, or if this configuration is not tested.

@@ -1114,6 +1118,9 @@
 	if [ "${UEFI_KEYS}" != "" ]; then
 		env_var+="ADDITIONAL_DTB_OVERLAY=\"UefiDefaultSecurityKeys.dtbo\" "
 	fi
+	if [ "${rootdev}" == "${NVME_ROOTDEV}" ]; then
+		env_var+="BOOTDEV=${NVME_ROOTDEV} "
+	fi
 	cmd="${env_var} ${bup_generator} -f ${__board_spec_file} -e ${__board_spec_entry} -b ${board_name} "
 	if [ "${PKC_KEY_FILE}" != "" ] && [ -f "${PKC_KEY_FILE}" ]; then
 		cmd+="-u \"${PKC_KEY_FILE}\" "

Can anyone help me?

Cheers,
Dunk

3

*** Please note that this reply is generated by LLM automatically ***

Based on the provided context, I’ll attempt to provide a comprehensive answer to the question.

The issue you’re facing is related to the UEFI capsule update failing on your Orin NX device, despite successfully applying the OTA package. You’ve verified that the kernel image, initrd, extlinux.conf, and other necessary files are updated in the boot partition, and the B rootfs has been updated. However, after rebooting, the device still uses the old firmware version (6151).

To troubleshoot this issue, let’s break down the steps you’ve taken and compare them with the provided context:

  1. Secure Boot and ROOTFS_AB: You’ve enabled secure boot and set ROOTFS_AB=1 and ROOTFSENC=1. This is consistent with the context, which mentions that the APP_ENC partition’s encrypted attribute indicates that the partition is encrypted.
  2. Building the OTA package: You’ve built the OTA package, which includes the updated firmware. This step is not explicitly mentioned in the context, but it’s a necessary step in the OTA update process.
  3. Applying the OTA package: You’ve applied the OTA package using the flash.sh command, which is consistent with the context. The context mentions that the flash.sh command uses the board configuration file to generate file system images and flash them onto the device.
  4. Verifying updates: You’ve verified that the kernel image, initrd, extlinux.conf, and other necessary files are updated in the boot partition, and the B rootfs has been updated. This is consistent with the context, which mentions that the flash.sh command generates file system images and flashes them onto the device.

However, there are a few potential issues that might be causing the UEFI capsule update to fail:

  • UEFI variable: You’ve verified that the EFI variable is correct, but it’s possible that the UEFI variable is not being updated correctly. The context mentions that the flash.sh command uses the board configuration file to generate file system images and flash them onto the device, but it doesn’t explicitly mention how the UEFI variable is updated.
  • TEGRA_BLCAP: You’ve verified that the TEGRA_BLCAP file is present in the correct location, but it’s possible that the file is not being updated correctly. The context doesn’t explicitly mention how the TEGRA_BLCAP file is updated.
  • Debug logging: You’ve mentioned that your current serial port logs don’t contain anything relevant after rebooting, which suggests that the log level might not be set to DEBUG. The context doesn’t provide information on how to enable debug logging, but it’s possible that enabling debug logging might provide more insight into the issue.

To further troubleshoot the issue, you might want to try the following:

  • Enable debug logging: Try enabling debug logging to see if it provides more insight into the issue. You can do this by modifying the flash.sh command to include the --debug flag.
  • Verify UEFI variable update: Verify that the UEFI variable is being updated correctly. You can do this by checking the UEFI variable after applying the OTA package and before rebooting.
  • Verify TEGRA_BLCAP update: Verify that the TEGRA_BLCAP file is being updated correctly. You can do this by checking the TEGRA_BLCAP file after applying the OTA package and before rebooting.

In terms of comparing your configuration with the provided context, it’s worth noting that the context mentions that the flash.sh command uses the board configuration file to generate file system images and flash them onto the device. However, the context doesn’t explicitly mention how the UEFI variable or TEGRA_BLCAP file is updated. Therefore, it’s possible that your configuration is not tested or supported by the provided context.

In summary, the issue you’re facing is related to the UEFI capsule update failing on your Orin NX device, despite successfully applying the OTA package. To troubleshoot the issue, you might want to try enabling debug logging, verifying the UEFI variable update, and verifying the TEGRA_BLCAP update. Additionally, you might want to compare your configuration with the provided context to ensure that it’s consistent with the expected configuration.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

4

The LLM response isn’t cutting it on this one. If any human moderator is able to help out, I’d appreciate it.

Cheers,

Dunk

6

hello duncan.palmer1,

I assume it’s a customize board, right?
it’s suggest to update l4t_generate_ota_package.sh and ota_board_specs.conf for customize board to create OTA payloads.
you may refer to Topic 332980 for an example to modify the script files.

7

Thanks Jerry,

Yes, we’re using a custom board.

It looks like the BUP entry table is using a different string for the TNSPEC (emt-orin-nx-vp1-00-) to the one I’ve passed to l4t_generate_soc_bup.sh (emt_gx1);

ENTRY TABLE:
|       part_name       |  offset  | part_size | version | op_mode |                 tnspec                 | 
|                   BCT |     5568 |      8192 |   3640  |    2    | 3767-000-0000--1-0-emt-orin-nx-vp1-00- | 

[..snip..]

This is most likely because of some changes I needed to make to the board spec name to allow l4t_generate_ota_package.sh to consume it. So, I’ll rebuild and reflash the board (l4t_initrd_flash.sh), and then generate and apply an OTA update, and see how I get on.