Not able to find partition B_spe-fw when trying to boot from partition B (Potential QSPI issue?)

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

I am working on a Jetson AGX Orin Industrial Dev Kit that is using Secure Boot with partitioning and disk encryption. Currently, I am running everything from the Jetpack version 35.5.0. I am able to flash and configure software on it successfully, but I am only able to boot from partition A.

I run the command nvbootctrl set-active-boot-slot 1 and then reboot the device. On reboot, I get the following message from the UART log

I> Active chain: 1
I> Partition name: B_spe-fw
E> Cannot find partition B_spe-fw
E> Partition B_spe-fw not found
E> MB2_FW_LOAD: Failed to load FW.
C> Task 0x0 failed (err: 0x224d090d)
E> Top caller module: LOADER, error module: PARTITION_MANAGER, reason: 0x0d, aux_info: 0x09

What’s strange is that the B_spe-fw partition seems to successfully generate during flashing. I have checked the .xml file used when flashing and that does not seem to pose any issues. It also does not seem to be the RSA authentication issue. Below is the flashing log and the UART log on bootup:
initial_flashing.txt (177.6 KB)

UART_partitionB_log.txt (114.3 KB)

3

The only instance of this I can find is here: hostapp-update-hooks: Enable transitioning from Jetpack 5 to Jetpack 6 · balena-os/balena-jetson-orin@139a0ff · GitHub

image
image1925×1400 260 KB

This Orin was initially flashed with R35.4.1 but did not use secureboot. Since then, I have upgraded to R35.5.0.

5

hello grant.kellogg,

may I confirm how you upgrade from r35.4.1 to r35.5.0?
besides, did you updating partition-B’s spe-fw before using nvbootctrl to switch active slots?

6

I updated by downloading the driver package from here: Jetson Linux | NVIDIA Developer

I then re-flashed the Orin with r35.5.0. I am not sure if anything would have changed in regard to B_spe-fw between the two but I didn’t explicitly change anything about the B_spe-fw partition. Anytime I set the active bootloader slot to be B, it gives me the aforementioned error and switches back to A.

7

Would I have to do some sort of capsule update as mentioned here: Update and Redundancy — NVIDIA Jetson Linux Developer Guide 1 documentation

8

Update:

I have tried to run a capsule update to see if that would fix the bootloader issue on partition B. The steps I ran were:

cd ~/Linux_for_Tegra
sudo ./l4t_generate_soc_bup.sh -u rsa_priv.pem -v sbk.key -b jetson-agx-orin-devkit-industrial t23x
./generate_capsule/l4t_generate_soc_capsule.sh -i bootloader/payloads_t23x/bl_only_payload -o ./TEGRA_BL.Cap t234
scp TEGRA_BL.Cap orin@IP.ADDRESS:/home/orin/
ssh orin@IP.ADDRESS
sudo su
# ll /dev/disk/by-partlabel/esp
# sudo mount /dev/mmcblk0p13 /esp_mount/
# cd /esp_mount/EFI
# mkdir UpdateCapsule
# cd UpdateCapsule/
# cp home/orin/TEGRA_BL.Cap /esp_mount/EFI/UpdateCapsule
# printf "\x07\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00" > /tmp/var_tmp.bin
# cd /sys/firmware/efi/efivars/
# dd if=/tmp/var_tmp.bin of=OsIndications-8be4df61-93ca-11d2-aa0d-00e098032b8c bs=12
# reboot

However, once the Orin reboots and I check the slots by typing sudo nvbootctrl dump-slots-info, I still get the following:

Current version: 35.5.0
Capsule update status: 0
Current bootloader slot: A
Active bootloader slot: A
num_slots: 2
slot: 0,             status: normal
slot: 1,             status: unbootable

The capsule update did not seem to take effect and slot B is still unbootable.

Note that when I run sudo /usr/sbin/nv_bootloader_payload_updater --print-ver it outputs

Start running: /opt/nvidia/l4t-bootloader-config/nv-l4t-bootloader-config.sh -C
3701--0008--1--jetson-agx-orin-devkit-industrial-
Got update payload: /opt/ota_package/bl_update_payload
Tegra User Block Device: /dev/disk/by-partlabel 
Tegra Boot Block Device: /dev/mtdblock0
MTD block size sysfs path: /sys/block/mtdblock0/size
Get SPI boot device size failed
Publish Block Device Failed
/usr/sbin/nv_bootloader_payload_updater --print-ver failed
10

Update 2:

I have now flashed and configured a new Orin device with fused keys, secure boot, partitioning and disk encryption and I am still getting the same results. I initially though it could be due to flashing with R35.4.1 and then flashing with R35.5.0 but that does not seem to be the case.

Note that this Orin device had never been flashed before. I will list the steps I used to fuse the keys I had previously generated and flash the device. I will also provide the logs as well.

I randomly generated an RSA, SBK, OEMK2, sym_y234, sym2_t234 and auth key needed for secure boot and disk encryption respectively. With those made, I create a fuse configuration file called fuse.xml that looks like this:

<genericfuse MagicId="0x45535546" version="1.0.0">
   <fuse name="PublicKeyHash" size="64" value="omitted"/>
   <fuse name="SecureBootKey" size="32" value="omitted"/>
   <fuse name="OemK2" size="32" value="omitted"/>
   <fuse name="BootSecurityInfo" size="4" value="0x209"/>
   <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>

where the BootSecurityInfo value was found to be 0x209 based on the Orin Fuse Specification as

[BIT]  15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
[VAL]   0  0  0  0  0  0  1  0  0  0  0  0  1  0  0  1

I only have bits 0, 3 and 9 enabled for RSA 3k, SBK and ODM KEY VALID respectively. I then performed the command

sudo ./odmfuse.sh -X ./fuse.xml -i 0x23 jetson-agx-orin-devkit-industrial

fuse_log.txt (94.5 KB)

Reading the fuses back confirms they were burned properly. Since I changed the sym_y234, sym2_t234 and auth keys, I then get a new eks image by running

python3 gen_ekb.py -chip t234 -oem_k2_key oem_k2.key -fv fv_ekb_t234 -in_sym_key sym_t234.key -in_sym_key2 sym2_t234.key -in_auth_key auth.key -out eks_t234.img

and move eks_t234.img to the bootloader directory and sym2_t234.key to Linux_for_Tegra. From there, I flash the device with the command

sudo ROOTFS_ENC=1 ROOTFS_AB=1 ./flash.sh -u rsa_priv.pem -v sbk.key -i "./sym2_t234.key" jetson-agx-orin-devkit-industrial mmcblk0p1

Here is the flash log
flash_log_new_device.txt (177.5 KB)

I am then able to ssh into the Orin and change its active boot slot to 1 but still get the same error as seen in the UART log
UART_boot_log.txt (113 KB)

Could it be something with my process described above?

11

hello grant.kellogg,

am just wondering, is it related to secure boot?
had you verify nvbootctrl for switching active slots without Jetson security enabled?

12

I have not, but I can try that out. Would secure boot hinder me from switching partitions? I didn’t think it would. I would prefer to have secure boot enabled and be able to switch partitions.

13

Flashing another Orin without secure boot but still using unique keys for sym_y234, sym2_t234 and auth gave the same results. Upon reboot partition B is unbootable. Logs are attached
flash_log_no_secure_boot.txt (104.0 KB)
UART_log_no_secure_boot.txt.txt (113.3 KB)

15

could you please double check the logs.
it looks you attach the logs with Active chain: 0, and it’s actually booting up into linux.

16

PuTTY is not able to display the whole bootup process so the result of using Active chain: 1 was not shown but it gave the same error I have been seeing. I can upload another log today.

Also, is it not supposed to boot up into Linux? I think all my UART logs have shown that.

17

it shall keep gather the logs via J26 debug UART port.
please refer to Jetson AGX Orin Developer Kit User Guide | NVIDIA Developer, for the USB micro-B for Debug UART.

19

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.