Sending bct_br, Sending mb1, ERROR: might be timeout in USB write

Hi,
I’m trying to flash Orin NX 16GB (BOARDID=3767 BOARDSKU=0003 FAB=300) p3768-0000-p3767-0000-a0.
I’m trying to do that with secure boot and encrypted storage so that I will have a full secure chain.
I followed the guides and generated all related keys.

Also:
cat > "$UEFI_DIR/uefi_keys.conf" <<EOF
UEFI_DB_1_KEY_FILE="db_1.key"
UEFI_DB_1_CERT_FILE="db_1.crt"
UEFI_DEFAULT_PK_ESL="pk.esl"
UEFI_DEFAULT_KEK_ESL_0="kek.esl"
UEFI_DEFAULT_DB_ESL_0="db_1.esl"
UEFI_DEFAULT_DB_ESL_1="db_2.esl"
EOF

"${LINUX_FOR_TEGRA_DIR}/tools/gen_uefi_keys_dts.sh" "$UEFI_DIR/uefi_keys.conf"

Then:
cat > "$FUSE_XML" <<EOF
<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="ArmJtagDisable" size="4" value="0x1"/>
<fuse name="PublicKeyHash" size="64" value="${PKCS_KEY_XML_HASH}"/>
<fuse name="SecureBootKey" size="32" value="${SBK_KEY_XML}"/>
<fuse name="OemK1" size="32" value="${KEK_2_KEY_XML}"/>
<fuse name="BootSecurityInfo" size="4" value="0x1E9"/>
</genericfuse>
EOF

I know that currently this is without “Bit 9 = 1 → ODM Key Valid , Bit 23 (BootDeviceInfo) = 1 → Disable RCM” and without “SecurityMode”.

Then:

EKB_TOOL="${LINUX_FOR_TEGRA_DIR}/source/optee/samples/hwkey-agent/host/tool/gen_ekb/gen_ekb.py"

sudo python3 "$EKB_TOOL" \
-chip t234 \
-oem_k1_key "$WORK_DIR/kek_optee.key" \
-in_sym_key "$WORK_DIR/sym_t234.key" \
-in_sym_key2 "$WORK_DIR/sym2_t234.key" \
-in_auth_key "$WORK_DIR/auth_t234.key" \
-out "${TEGRA_BOOTLOADER_DIR}/eks_t234.img"

After that I managed to burn the fuses with:
sudo "${LINUX_FOR_TEGRA_DIR}/odmfuse.sh" \
-i 0x23 \
-k "$WORK_DIR/rsa.pem" \
-S "$WORK_DIR/sbk.key" \
-X "$FUSE_XML" \
--disable-jtag \
p3768-0000-p3767-0000-a0

and I burned:
I> Burning fuses
I> 1. Start ArmJtagDisable burn
I> 1. ArmJtagDisable burnt successfully
W> No handling of CRC-32 for ArmJtagDisable
I>
I> 2. Start PublicKeyHash burn
I> 2. PublicKeyHash burnt successfully
W> No handling of CRC-32 for PublicKeyHash
I>
I> 3. Start SecureBootKey burn
I> 3. SecureBootKey burnt successfully
W> No handling of CRC-32 for SecureBootKey
I>
I> 4. Start OemK1 burn
I> 4. OemK1 burnt successfully
W> No handling of CRC-32 for OemK1

I> Burning fuses
I> 5. Start BootSecurityInfo burn
I> 5. BootSecurityInfo burnt successfully
W> No handling of CRC-32 for BootSecurityInf

Here, I tried to flash with 3 steps:
STEP 1:
sudo BOARDID=3767 BOARDSKU=0000 FAB=300 ./tools/kernel_flash/l4t_initrd_flash.sh \
--showlogs \
--no-flash \
--network usb0 \
-u "$WORK_DIR/rsa.pem" \
-v "$WORK_DIR/sbk.key" \
--uefi-keys "$WORK_DIR/uefi_keys/uefi_keys.conf" \
--uefi-enc "$WORK_DIR/sym_t234.key" \
-p "-c ./bootloader/generic/cfg/flash_t234_qspi.xml" \
p3768-0000-p3767-0000-a0 internal

STEP2:
sudo BOARDID=3767 BOARDSKU=0000 FAB=300 EXT_NUM_SECTORS=240000000 ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh \
--showlogs \
--no-flash \
--network usb0 \
-u "$WORK_DIR/rsa.pem" \
-v "$WORK_DIR/sbk.key" \
--external-device nvme0n1p1 \
-i "$WORK_DIR/sym2_t234.key" \
--uefi-keys "$WORK_DIR/uefi_keys/uefi_keys.conf" \
--uefi-enc "$WORK_DIR/sym_t234.key" \
-c ./tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml \
-S 100GiB \
--external-only \
--append \
p3768-0000-p3767-0000-a0 external

STEP 3:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh \
--showlogs \
--network usb0 \
-u "$WORK_DIR/rsa.pem" \
-v "$WORK_DIR/sbk.key" \
--uefi-keys "$WORK_DIR/uefi_keys/uefi_keys.conf" \
--uefi-enc "$WORK_DIR/sym_t234.key" \
--flash-only

I managed to do STEPS 1 and 2 but failed on STEP 3 with:

Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

Entering RCM boot

[   0.0169 ] mb1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --mb1_bin
[   0.0169 ] psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --psc_bl1_bin
[   0.0169 ] rcm boot with presigned binaries
[   0.0176 ] tegrarcm_v2 --instance 3-1 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct.signed
[   0.0182 ] BR_CID: 0x89012344705E01C05000000017010080
[   0.0249 ] Sending bct_br
[   0.0302 ] Sending mb1
[   0.0308 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --instance 3-1 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct.signed
Cleaning up…

On the failure point the device restarting with regular loading logs (over uart), but nothing flashed.

Note:
I managed to flash with similar (adapted where needed) flow “jetson-orin-nano-devkit” - Orin nano 8GB.
I also managed to flash the Orin NX 16 GB without secure boot and without encryption.

I have read the FQA and changed the “autosuspend” param, reconnect the USB cable and re plug the power to the Nvidia, but it is still not working.

I can attach more logs\info as needed.

Would love if you can assist me with this.

Thanks in advance.

Yair.

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

Based on the provided information, it appears that you are trying to flash a Jetson Orin NX device with secure boot and encrypted storage. You have generated the necessary keys and burned the fuses, but are experiencing issues with the flashing process.

The error message you provided suggests that the device is restarting with regular loading logs over UART, but nothing is being flashed. This could be due to a variety of reasons, including issues with the flashing command, the device’s configuration, or the environment.

To troubleshoot the issue, I would recommend the following steps:

  1. Verify that the flashing command is correct and that all necessary options are included. Specifically, ensure that the -u and -v options are used to specify the PKC key file and SBK key file, respectively.
  2. Check the device’s configuration to ensure that it is set to boot from the correct device (e.g., the NVMe drive). You can use the efibootmgr command to modify the UEFI boot order if necessary.
  3. Verify that the USB cable and power are properly connected to the device.
  4. Try adding the --autosuspend=0 option to the flashing command to disable autosuspend.
  5. If you are using a NVMe drive, try adding the --external-device option to specify the NVMe drive as the external device.

Here is an example of a flashing command that you can try:

sudo BOARDID=3767 BOARDSKU=0003 FAB=300 ./tools/kernel_flash/l4t_initrd_flash.sh \
  --mass-storage-only \
  --showlogs \
  --network usb0 \
  --no-flash \
  --external-device nvme0n1p1 \
  --external-only \
  -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml \
  --uefi-keys ~/oem_keys/uefi_keys/uefi_keys.conf \
  --uefi-enc ~/oem_keys/uefi_keys/uefi_enc.key \
  --autosuspend=0 \
  jetson-orin-nx-devkit nvme0n1p1

This command includes the necessary options for secure boot and encrypted storage, and also disables autosuspend.

If you are still experiencing issues, please provide more logs and information about your environment, and I will do my best to assist you further.

In comparison to the Orin Nano 8GB, which you were able to flash successfully, the main difference is the device type and the memory size. The Orin NX has a different device ID and memory configuration, which may require different flashing parameters. However, the basic flashing command and options should be similar.

It’s also worth noting that the Orin NX 16GB device was flashed successfully without secure boot and encryption, which suggests that the device itself is not the issue. The problem is likely related to the secure boot and encryption configuration, which requires specific keys and options to be set correctly.

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

Hi, thanks for the fast response, but clearly that you didn’t read all the information that I provided while calculating your response and your answer is nor relevant and just wasting my time.

I would love to get an answer from a human being.

Thanks.

Yair

Is the UART side giving any log there?

Hey,
Found the issue.

The problem related to some changes that made by Nvidia since January 2025 (there is some relase doc about that)
This changes require to change:
<fuse name="BootSecurityInfo" size="4" value="0x1E9"/>
To:
<fuse name="BootSecurityInfo" size="4" value="0x3E9"/>

Then the burning of the fuses finished successfully and I managed to flash.

Thanks.

1 Like

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