I’m currently working on a bootloader update using Capsule Update on a Jetson Xavier NX with eMMC storage and Secure Boot enabled. However, I am experiencing some strange behavior during the process.
To generate the payload (bl_only_payload), I use the -u and -v options with our respective keys, and then create the TEGRA_BL.cap file. Up to this point, everything appears to be working correctly.
During boot, the system detects the capsule and completes the update successfully. Here’s an example of the boot output:
Jetson UEFI firmware (version v35.4.1 built on 2023-08-04T23:11:08+00:00)
ESC to enter Setup.
F11 to enter Boot Manager Menu.
Enter to continue boot.
Update Progress - 100% **************************************************����
Also, when I run nvbootctrl dump-slots-info, I get:
Current version: 35.4.1
Capsule update status: 1
Current bootloader slot: B
Active bootloader slot: B
num_slots: 2
slot: 0, status: normal
slot: 1, status: normal
Everything indicates that the update is applied successfully, but when I test by changing the UEFI menu timeout value (expecting it to reflect after the update), the value remains unchanged before and after the update.
So here are my questions:
Is it possible that some UEFI configuration values, such as the menu timeout, cannot be updated via Capsule Update?
Are there any parts of the firmware that are not affected by this type of update?
Has anyone experienced a similar issue where configuration changes are not reflected after a Capsule Update?
Yes, I’m trying to stay on the same version (R35.4.1). What I’m attempting to do is apply some optimizations to reduce boot time, following the guide available here: Boot Time Optimization
As I mentioned in my previous message, the UEFI menu timeout value did not change, even though the update process completed successfully.
Our goal is to avoid performing the flash process, because when we do flash the device, the changes are applied correctly, which suggests that the modifications we’re making are valid.
However, in our current workflow, doing the flash process each time is not a feasible option.
Any insights into why certain UEFI config values like the timeout aren’t being updated via Capsule, or if there’s a specific method needed to include those changes, would be greatly appreciated.
I’ve verified it locally and the current behavior is expected.
Capsule update will not reset/erase UEFI variables. (i.e. uefi_variables partition), but flashing process does.
You can find all variables in /sys/firmware/efi/efivars/
If you want to update the autoboot timeout to 1s, please simply run the following commands on your board.
Thank you very much for your response. By any chance, is there any documentation or could you let me know which parts of the bootloader can be updated with a Capsule? I’d really appreciate it!
I’ve tested to update rce-fw remotely.
I’ve replaced $OUT/Linux_for_Tegra/bootloader/camera-rtcpu-t234-rce.img with the latest firmware binary. and.. execute below to generate an OTA payload package to only update Bootloader. $ sudo -E ./tools/ota_tools/version_upgrade/l4t_generate_ota_package.sh --external-device nvme0n1 -b jetson-orin-nano-devkit R35-4
you may check partition layouts for those bootloader partitions.
basically, they should be able to update remotely.