Fuse burn error

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

I am getting this error from UART while trying to burn the fuses on my AGX Orin.
FUSE: Failed burn fuses as per fuse info.

Logs from first run:
fuse-burn-attempt-1.log (1.2 KB)

Logs from second run:
fuse-burn-attempt-2.log (925 Bytes)

Here is my fuse config and the command I ran
sudo ./odmfuse.sh -X ~/fuse_config.xml -i 0x23 jetson-agx-orin-devkit

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="ArmJtagDisable" size="4" value="0x1" />
    <fuse name="OptInEnable" size="4" value="0x1" />
    <fuse name="PublicKeyHash" size="64" value="random" />
    <fuse name="PkcPubkeyHash1" size="64" value="random" />
    <fuse name="PkcPubkeyHash2" size="64" value="random" />
    <fuse name="SecureBootKey" size="32" value="random" />
    <fuse name="OemK1" size="32" value="random" />
    <fuse name="OemK2" size="32" value="random" />
    <fuse name="BootSecurityInfo" size="4" value="0x209" />
    <fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>

I think I am following the example in SecureBoot very closely. Is the fuse burning successful? What went wrong?

3

please double check Jetson Orin Fuse Specification to review the FUSE_BOOT_SECURITY_INFO_0 settings.

4 
Boot Security Info (also known as ODM Production Mode)
        Bits [2:0] mapped to Secure Boot Authentication Scheme,
            where:
            000b: SHA2-512 Hash (not recommended)
            001b: 3072-bit RSA
            010b: ECDSA P-256 Curve
            011b: ECDSA P-521-Curve
            100b: Ed25519
            101b:XMSS – no Pre Hashing
        Bit [3] secure boot encryption scheme (SBK) enable
        Bits [8:4] Not available and may not be logic 0 by default
        Bit [9] ODM Key Valid
        Bit [11] OEM DICE1 Feature enable
        Bit [13] FMC DICE Feature enable

        [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
  • We are using RSA-3K keys so bits[2:0] are 001b
  • SBK key is fused so setting bit[3] to 1
  • OEM K1 and K2 keys are fused so setting bit[9] to 1

Do you see anything missing here?

5

When I ran nv_fuse_read.sh, I see the following

odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000001
public_key_hash: <correct>
boot_security_info: 0x000001e0
odmid: 0x0000000000000000
pk_h1: <correct>
pk_h2: <correct>
security_mode: 0x00000000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
ecid: <redacted>

Looks like the boot_security_info fuse was somehow set incorrectly to 0x000001e0 ?

Does this mean my board is dead now? Can I still recover my board?

6

Found a similar post here (Writing fuses with reserved bits) from Orin Nano , where devices can have boot_security_info set to 0x1E0 by default on selected devices.

We are able to recover the device by doing an OR of the existing value 0x1E0 with the desired value 0x209, so the resulting fuse value is 0x3E9 , and then burning the final 0x3E9 value to the boot_security_info fuse.

  1. Can you confirm that boot_security_info fuse on AGX Orin also come preprogrammed with 0x1E0 ?
  2. If that is true, do you recommend that we continue to program the final OR’ed value 0x3E9 on all devices (regardless if boot_security_info value is 0 or 0x1E0 out from the factory)?
7

is it a new module? fuse value for boot_security_info was burned by manufacturing to 0x1E0. it’s around in the beginning of 2025.

8

Yes this is a new unit.

Do you see any harm in setting the bits to 0x1E0 as well on older units?

9

hello tanlu,

no concerns for setting 0x1E0 on older units.
please consider BOOT_SECURITY_INFO with 0x1E0 as its default value from now on.