Fuse and Flash Failure on AGX Orin (PKC+SBK)

kyoungh · December 22, 2025, 8:24pm

Hello,

I am attempting to fuse a Jetson AGX Orin (32GB) using PKC (ECDSA P-256) and SBK with JetPack 6.2
I have prepared the following keys:

PKC: ECDSA P-256
SBK: 32-byte key
OEM_K1: 32-byte key

Key Generation:

## PKC
openssl ecparam -name prime256v1 -genkey -noout -out ecp256.pem

./tegrasign_v3.py --pubkeyhash ecp256.pubkey ecp256.hash --key ecp256.pem

# SBK (Converted to 8-word format)
openssl rand -hex 32 | ./convert_8words.sh > sbk-32.key

# OEM_K1
openssl rand -hex 32 > oemk1.key

fuse_orin.xml

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="OemK1" size="32" value="0x34af...890a"/>
    <fuse name="PublicKeyHash" size="64" value="0x567a...9876"/>
    <fuse name="SecureBootKey" size="32" value="0xe3f4...1a2b"/>
    <fuse name="BootSecurityInfo" size="4" value="0x20a"/>
    <fuse name="SecurityMode" size="4" value="0x1"/>
    <fuse name="ArmJtagDisable" size="4" value="0x1"/>
</genericfuse>

Issue Description:

Fusing was successful on some Orin units, but failed on a new batch of devices. I noticed the new devices already had BootSecurityInfo set to 0x1e0 by default (checked via nv_fuse_read.sh), while my previous XML used 0x20a.

According to nv_fuse_read.sh, the current fuse values are:

boot_security_info: 0x000001e0
public_key_hash: 0x567a…9876
ecid: 0x9378…9875

All other fields (including security_mode, odm_lock, pk_h1, and reserved_odm0~7) remain at zero.

To account for the existing bits, I updated BootSecurityInfo to 0x3ea (0x1e0 | 0x20a).

Attempt 1: Fusing with OemK1, PKC, SBK, and BootSecurityInfo

New xml file:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="OemK1" size="32" value="0x34af...890a"/>
    <fuse name="PublicKeyHash" size="64" value="0x567a...9876"/>
    <fuse name="SecureBootKey" size="32" value="0xe3f4...1a2b"/>
    <fuse name="BootSecurityInfo" size="4" value="0x3ea"/>
</genericfuse>

When I ran the following commands:

./odmfuse.sh --noburn --auth NS -i 0x23 -k ecp256.pem -S sbk-32.key -X fuse_orin.xml jetson-agx-orin-devkit
tar xpf fuseblob.tbz2 && cd bootloader/
./fusecmd.sh

I encountered the following errors:

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation: 
I> Entry timestamp: 0x020536aa
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x82e000000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    OemK1    size: 32
I> Index : 2    PublicKeyHash    size: 64
I> Index : 3    SecureBootKey    size: 32
I> Index : 4    BootSecurityInfo    size: 4
I> Fuse Blob found
I> 
I> Burning fuses
I> 1. Start OemK1 burn
E> FUSE: Failed to burn fuse addr: 0x316.
E> FUSE: Could not write Fuse: 0x6a.
E> FUSE: Could not write Fuse: 0x6a.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62170302)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03
I> Busy Spin

nv_fuse_read.sh showed no change in the results.

Attempt 2: Fusing only BootSecurityInfo

I updated the XML to only include BootSecurityInfo (0x3ea).
fuse_orin.xml:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x3ea"/>
</genericfuse>

This time, the burn reported success

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation: 
I> Entry timestamp: 0x022481b6
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x82e000000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    BootSecurityInfo    size: 4
I> Fuse Blob found
I> 
I> Burning fuses
I> 1. Start BootSecurityInfo burn
I> 1. BootSecurityInfo burnt successfully
W> No handling of CRC-32 for BootSecurityInfo
I> 
I> Successfully burnt fuses as per fuse info
I> Index : 1    BootSecurityInfo    size: 4
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished

But when I tried to flash with the following commands

# sudo ROOTFS_ENC=1 ./flash.sh --generic-passphrase --no-flash -i sym2_t234.key -u ecp256.pem -v sbk-32.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key jetson-agx-orin-devkit mmcblk0p1
# bash ./flashcmd.txt

I encountered an error during flashing

...
[   0.0235 ] tegrarcm_v2 --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.0244 ] BR_CID: 0xAA012344705DF6513000000019020140
[   0.0476 ] Sending bct_br
[   0.0768 ] Sending mb1
[   0.0777 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --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

And when I try to read fuse info with keys

./odmfuseread.sh -i 0x23 -k ecp256.pem -S sbk-32.key jetson-agx-orin-devkit

I encountered the following error

. . . 
[   0.4373 ] tegrarcm_v2 --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
[   0.4382 ] BR_CID: 0xAA012344705DF6513000000019020140
[   0.4608 ] Sending bct_br
[   0.4902 ] Sending mb1
[   0.4909 ] ERROR: might be timeout in USB write.
Error: Return value 3
[   0.5091 ] File tmp.bct open failed
Error: Return value 19
Command tegrabct_v2 --brbct tmp.bct --chip 0x23 0 --custinfo /home/nvidia/nvidia/nvidia_sdk/JetPack_6.2_Linux_JETSON_AGX_ORIN_TARGETS/Linux_for_Tegra/bootloader/custinfo_out.bin
Reading board information failed.

Questions:

What is causing this failure? I did not encounter any issues during the fuse and flash process with the Orin models released last year (BootSecurityInfo=0x0)
Is there something wrong with my procedure?
How can I successfully flash this board while it is in this partially-fused state?

Any insights or guidance would be greatly appreciated!
Thank you

carolyuu · December 22, 2025, 8:45pm

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

Based on the provided context, I will attempt to address the issues and provide guidance on how to proceed.

Issue 1: Fusing failure on new batch of devices

The new devices have a default BootSecurityInfo value of 0x1e0, whereas the previous XML used 0x20a. This discrepancy might be causing the fusing failure.

Solution:

Update the BootSecurityInfo value in the XML to 0x3ea (0x1e0 | 0x20a) to account for the existing bits. This is what you have already done in Attempt 1.

Issue 2: Fusing with OemK1, PKC, SBK, and BootSecurityInfo (Attempt 1)

The fusing process failed, and nvfusereadsh showed no change in the results.

Possible cause:

The fusing process might be failing due to the existing BootSecurityInfo value (0x1e0) not being properly accounted for in the XML. Although you updated the BootSecurityInfo value to 0x3ea, it’s possible that the fusing process is still failing due to other reasons.

Issue 3: Fusing only BootSecurityInfo (Attempt 2)

The fusing process reported success, but flashing failed, and reading fuse info with keys resulted in an error.

Possible cause:

Fusing only the BootSecurityInfo value might not be sufficient. The other fuse values, such as OemK1, PKC, and SBK, might not be properly set, causing the flashing and fuse info reading issues.

Recommendations:

Verify the XML file: Double-check the XML file to ensure that all the necessary fuse values, including OemK1, PKC, SBK, and BootSecurityInfo, are properly set and accounted for.
Use the correct fusing command: Ensure that you are using the correct fusing command, including the -v option, to specify the XML file.
Check the fuse values: After fusing, use nvfusereadsh to verify that all the fuse values have been properly set.
Flash the device: Once the fuse values are verified, try flashing the device again using the correct flashing commands.

Additional insights:

Make sure that the PKC key pair is generated correctly and that the PublicKeyHash value is properly calculated.
Verify that the SBK key is generated correctly and that it matches the expected format (32-byte key).
Ensure that the OemK1 key is generated correctly and that it matches the expected format (32-byte key).
If you are using a secure boot mode, ensure that the security mode is properly set in the XML file.

By following these recommendations and verifying the XML file, fuse values, and flashing commands, you should be able to resolve the issues and successfully flash the device.

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

JerryChang · December 23, 2025, 2:35am

hello kyoungh,

it seems incorrect. you should have FUSE_BOOT_SECURITY_INFO_0’s bits-[2:0]=010b for your secureboot authentication scheme, ECDSA P-256 Curve.

however, it’s able to check secureboot authentication scheme via BR_CID.
according to above, you’ve 010b = ECDSA P-256 Curve for your boot security info.
besides.. it also have SBK and ODM key valid enabled for this target.

kyoungh · December 23, 2025, 4:16am

Thank you @carolyuu
Hi @JerryChang Yes, that is exactly what I am confused about. Even though I attempted to fuse BootSecurityInfo with the value 0x3ea, both nv_fuse_read.sh and odmfuseread.sh consistently show the value as 0x000001e0. Why is the value not being updated despite the fuse process reporting success?"

JerryChang · December 23, 2025, 5:35am

hello kyoungh,

let me have confirmation, you’ve burning fuse onto new batch of devices with BootSecurityInfo=0x20a, and it’s retuning errors.
were you able to boot-up those targets for entering linux? what’s the nv_fuse_read.sh reports now?

kyoungh · December 23, 2025, 9:26pm

Hello @JerryChang,
Thank you for the follow-up. I realized some details were omitted in my previous summary. Here is the step-by-step breakdown of the process

1. Initial Fusing Attempt I initially attempted to fuse the device with BootSecurityInfo=0x20a using the command:

sudo ./odmfuse.sh --noburn --auth NS -i 0x23 -p -X fuse_orin.xml jetson-agx-orin-devkit
tar xpf fuseblob.tbz2 && cd bootloader/
./fusecmd.sh

While the command execution did not return a terminal error, I did not check the UART logs at that time, so I cannot confirm if there were internal warnings.

2. Flash Failure (Secure Boot) I tried to flash the device with Disk Encryption and Secure Boot keys, but the process FAILED:
sudo ROOTFS_ENC=1 ./flash.sh --generic-passphrase --no-flash -i sym2_t234.key -u ecp256.pem -v sbk-32.key --uefi-keys uefi_keys/uefi_keys.conf --uefi-enc sym_t234.key jetson-agx-orin-devkit mmcblk0p1

[   0.5900 ] Saving public key in pub_key.key for ECC
[   0.5900 ] tegrahost_v2 --chip 0x23 0 --pubkeyhash pub_key.key --updatesigheader mb1_bct_MB1_aligned_sigheader_encrypt.bct.signed mb1_bct_MB1_aligned_sigheader_encrypt.bct.sig oem-ecc
[   0.5918 ] Error: Skip generating mem_bct because sdram_config is not defined
[   0.5919 ] Error: Skip generating mem_bct because sdram_config is not defined
[   0.5919 ] Copying signatures
[   0.5928 ] tegrahost_v2 --chip 0x23 0 --partitionlayout readinfo_t234_min_prod.xml.bin --updatesig images_list_signed.xml --pubkeyhash pub_key.key
[   0.5973 ] Boot Rom communication
[   0.5984 ] tegrarcm_v2 --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.5992 ] BR_CID: 0x80012344705DF6513000000019020140
[   0.6230 ] Sending bct_br
[   0.6527 ] Sending mb1
[   0.6541 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --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
Reading board information failed.

3. Fuse Verification via odmfuseread.sh I then checked the actual fuse state. Surprisingly, the values do not match the intended 0x20a. Here is the current output:
# ./odmfuseread.sh -i 0x23 jetson-agx-orin-devkit

PublicKeyHash:  xxxxxxxxxxxxxxxxxxxxxx
BootSecurityInfo: 000001e0
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000

4. Successful Non-secured Flash Because the device appears to still be in a non-secure state, I flashedwithout security keys:
./flash.sh jetson-agx-orin-devkit mmcblk0p1
This succeeded, and I could enter Linux.

After that, I followed the steps described in ATTEMPT 1 of my original post, but this time using BootSecurityInfo=0x3ea

Now the device is currently unable to boot. Furthermore, I can no longer verify the fuse status as the odmfuseread.sh command now returns an error.

JerryChang · December 24, 2025, 2:42am

hello kyoungh,

it seems some contradiction with your step-3 and step-4. it should not burning fuses due to the variable (i.e. BootSecurityInfo) has a mismatch, it shows PKC key hash of your step-3 although you did not given the key to the script, and you’re able to re-flash without given keys.

generally, once you’ve fused a target, you’ll need to provide the exactly same keys for running flash command-line. otherwise, it’ll abort the flashing process.
there’s Boot Rom communication in the early stage.
for instance, it’ll report the errors like below and abort the process if you did not given keys to the fused target.
Error: Either RSA key file is not provided or SBK key file is provided for PKC protected target board.

did you have any UART logs for reference?
since it’s only checking PKC/SBK for Boot Rom communication, let’s narrow down this by having only those two keys to re-flash your target.
for instance, $ sudo ./flash.sh -u ecp256.pem -v sbk-32.key jetson-agx-orin-devkit mmcblk0p1

BTW, please refer to similar forum topics, such as.. Topic 330828, Topic 335952 as see-also.

kyoungh · January 7, 2026, 12:24am

Hello @JerryChang

I discovered that the ECP256 key I was using did not match the initial fuse configuration. After updating it to the correct key, I checked with this command
./flash.sh --read-info -u ecp256.pem -v sbk-32.key jetson-agx-orin-devkit mmcblk0p1

# L4T BSP Information:
# R35 , REVISION: 6.1
# User release: 0.0
###############################################################################
ECID is 0x...
# Target Board Information:
# Name: jetson-agx-orin-devkit, Board Family: t186ref, SoC: Tegra 234, 
# OpMode: production, Boot Authentication: SBKPKC, 
# Disk encryption: disabled ,
...

I then retried the fuse process with an updated fuse_orin.xml. Note that I omitted “SecurityMode” and “ArmJtagDisable” this time:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="OemK1" size="32" value="..."/>
    <fuse name="PublicKeyHash" size="64" value="..."/>
    <fuse name="SecureBootKey" size="32" value="..."/>
    <fuse name="BootSecurityInfo" size="4" value="0x3ea"/>
</genericfuse>

I used --auth SBKPKC instead of --auth NS

./odmfuse.sh --test --noburn --auth SBKPKC -i 0x23 -k ecp256.pem -S sbk-32.key -X fuse_orin.xml jetson-agx-orin-devkit

With these changes, I was able to successfully complete the fuse and flash process for my AGX Orin. Thank you for the support.

JerryChang · January 7, 2026, 2:08am

thanks for status update, glad to know the root cause (ECP256 key did not match), and you’re able to burn fuse onto new batch of devices.

system · January 21, 2026, 3:27am

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

Topic		Replies	Views
Orin fuse writing error Jetson AGX Orin security	11	30	February 10, 2026
Fuse burn error Jetson AGX Orin security	8	170	May 16, 2025
Flashing failed after burning fuses Jetson AGX Orin security	6	230	May 21, 2025
Jetson AGX Orin Secure Boot Issue: Stuck in Recovery Mode after Flash Attempts Jetson AGX Orin boot , security	33	551	July 29, 2025
Fusing BootSecurityInfo & SecurityMode fails on Orin AGX Jetson AGX Orin security	6	227	July 29, 2025
Issue flashing / reading with L4T tools after fuse programming Jetson AGX Orin security	9	212	October 9, 2025
Fuse configuration for SB and FDE Jetson AGX Orin	5	188	August 5, 2025
Jetson AGX Orin BOM修改后无法正常烧写fuse Jetson AGX Orin security , chinese	24	414	June 18, 2025
Can't boot after enable secure boot (AGX Orin) Jetson AGX Orin security	19	336	February 12, 2025
Can't read fuses or boot after burning fuses Jetson AGX Orin security	2	169	March 21, 2025

Fuse and Flash Failure on AGX Orin (PKC+SBK)

Issue Description:

Attempt 1: Fusing with OemK1, PKC, SBK, and BootSecurityInfo

Attempt 2: Fusing only BootSecurityInfo

Related topics