Unable to burn SecurityMode fuse on Jetson Orin NX after successful SBK+PKC fuse programming

Robotics & Edge Computing Jetson Systems Jetson Orin NX
,
1

Platform:

  • Module: Jetson Orin NX 16GB
    Carrier board: Seeed Studio J4012
    SoC: T234 (Orin)
    OS / BSP: NVIDIA JetPack / L4T (R36.x)

Summary:
I am unable to burn the SecurityMode fuse (production mode) on a Jetson Orin NX, even though SBK, PKC, OEM keys, and other security-related fuses were previously burned successfully using odmfuse.sh. The commands complete without burning SecurityMode, and the fuse remains unset when verified from Linux on the target.

Initial fuse programming (successful)

I initially burned the security fuses using the following XML configuration:

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PublicKeyHash" size="64" value="XXXXXXXXXXXX"/>
    <fuse name="SecureBootKey" size="32" value="XXXXXXXXXXXX"/>
    <fuse name="OemK1" size="32" value="XXXXXXXXXXXX"/>
    <fuse name="OemK2" size="32" value="XXXXXXXXXXXX"/>
    <fuse name="ArmJtagDisable" size="4" value="0x1"/>
    <fuse name="BootSecurityInfo" size="4" value="0x209"/>
</genericfuse>This step worked correctly. The fuses were burned and verified successfully.

Command used:

sudo ./odmfuse.sh -i 0x23 -X ../secureboot_fuse_config_t234.xml jetson-orin-nano-devkit

After this step:

  • Secure Boot is enabled

  • SBK + PKC are active

  • UEFI and boot chain work correctly

Attempt to burn SecurityMode (fails)

After the initial fuse programming, I attempted to burn the SecurityMode fuse (production mode) using both an XML-based approach and the -p flag.

Attempt 1: XML-based fuse

XML (secureboot_production_mode.xml):

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

Command:

sudo ./odmfuse.sh -i 0x23 \
  -k ../pkc/PKC.pem \
  -S ../sbk/SBK.hex \
  -X ../secureboot_production_mode.xml \
  jetson-orin-nano-devkit

Attempt 2: Using -p flag

sudo ./odmfuse.sh -i 0x23 \
  -k ../pkc/PKC.pem \
  -S ../sbk/SBK.hex \
  -p \
  jetson-orin-nano-devkit

In both cases:

  • odmfuse.sh runs without a fatal error

  • The process does not report that SecurityMode was burned

  • After reboot, SecurityMode is still unset

Verification method

To verify the fuse state, I boot Linux on the target and run:

sudo nv_fuse_read.sh

Result:

  • SecurityMode remains 0x0

  • Device is not in production mode

Additional notes / observations

  • SBK and PKC are already burned and functional

  • Secure boot works correctly

  • SecurityMode does not transition to production

  • I am using the same BSP/tools that successfully burned the original fuses

  • Host is a native Linux machine (not WSL / VM)

Question / Request for guidance

  1. Is there any known restriction or additional requirement for burning SecurityMode on Orin NX after SBK+PKC have already been fused?

  2. Is the XML-based method supported for SecurityMode, or must -p always be used?

  3. Is nv_fuse_read.sh the correct way to verify SecurityMode from Linux on Orin NX?

Any guidance or confirmation of the correct procedure would be appreciated.

Thank you.

2

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

Based on the provided context, it appears that you are trying to burn the fuse production mode on a Jetson Orin NX module, but the process is not working as expected. You have already successfully burned the SBK, PKC, and other security-related fuses using the fskp_fuseburn.py tool.

To address your issue, let’s break down the key points and provide guidance:

  1. XML-based approach vs. -b flag: Both methods are supported for burning fuses on the Jetson Orin NX. The XML-based approach uses a configuration file to specify the fuses to be burned, while the -b flag is used to burn the fuses directly. In your case, you have tried both methods, but neither has worked.
  2. Verification of fuse state: To verify the fuse state, you can use the tegra_fuse_read command on Linux, as you have done. This command reads the current state of the fuse and reports it.
  3. Restrictions or additional requirements: There are no known restrictions or additional requirements for burning the fuse production mode on the Jetson Orin NX. However, it’s essential to ensure that the SBK and PKC fuses are already burned and functional, which is the case in your scenario.
  4. Comparison with other Jetson modules: The process of burning fuses on the Jetson Orin NX is similar to other Jetson modules, such as the Jetson AGX Orin. However, there might be some differences in the specific fuse configurations and requirements.

To troubleshoot your issue, you can try the following:

  • Check the fuse configuration: Verify that the fuse configuration file (XML-based approach) or the command-line arguments (using the -b flag) are correct and match the expected values.
  • Verify the SBK and PKC fuse state: Ensure that the SBK and PKC fuses are indeed burned and functional by checking their state using the tegra_fuse_read command.
  • Check the UEFI configuration: Verify that the UEFI configuration is correct and matches the expected values. You can check the UEFI configuration using the uefi -cfg command.
  • Try burning the fuse again: Attempt to burn the fuse production mode again using both the XML-based approach and the -b flag. If the issue persists, try using a different BSP version or tools.

In summary, the XML-based method is supported for burning fuses on the Jetson Orin NX, and the -b flag can also be used. The correct way to verify the fuse state is by using the tegra_fuse_read command on Linux. If you continue to experience issues, try troubleshooting the fuse configuration, SBK and PKC fuse state, and UEFI configuration.

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

3

Thank you for the reply.

I would like to clarify a few points, as some of the referenced commands and options do not exist in the Jetson Orin BSP I am using:

  • There is no -b flag in odmfuse.sh (L4T R36.x). Production mode is set using -p or via an XML containing the SecurityMode fuse.

  • There is no tegra_fuse_read command available on Jetson Orin Linux. Fuse state is verified using nv_fuse_read.sh.

  • Tools such as fskp_fuseburn.py and commands like uefi -cfg are not present in the Orin BSP or in the target Linux environment.

For clarity, all fuse operations (including SBK, PKC, OEM keys, and attempted SecurityMode) were performed exclusively using odmfuse.sh, which worked correctly for all fuses except SecurityMode.

I would appreciate guidance based on the actual tools and workflow supported for Jetson Orin NX.

Thank you.

5

hello uvealonso,

it should able to have additional fuses Burn Fuses with the Fuse Configuration file.
according to Jetson Orin Fuse Specification.
you may try again to set the value to 0x1 since the length of FUSE_SECURITY_MODE_0 is only 1-bit.
for instance,

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

besides.. please setup a serial console to gather the UART logs for more details.

6

Hi JerryChang,

Thanks for your reply.

I have configured the serial console as requested and captured the UART logs during the attempt to burn SecurityMode using the XML value 0x1.

Below is the relevant (latest) output from the serial:

[0022.471] I> Binary MB2 loaded successfully at 0x80000000 (0x5e540)
[0022.478] I> Task: Map CCPLEX SHARED carveout
[0022.482] I> Task: Prepare MB2 params
[0022.486] I> Task: Dram ecc test
[0022.489] I> Task: Misc NV security settings
[0022.493] I> NVDEC sticky bits programming done
[0022.497] I> Successfully powergated NVDEC
[0022.501] I> Task: Disable/Reload WDT
[0022.505] I> Task: Program misc carveouts
[0022.509] I> Program IPC carveouts
[0022.512] I> Task: Disable SCPM/POD reset
[0022.516] I> SLCG Global override status := 0x0
[0022.520] I> MB1: MSS reconfig completed
I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation: 
I> Entry timestamp: 0x01584052
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x473800000, size:0x800000]
I> Task: Crypto init
I> Task: Program CBB PCIE AMAP regions
I> Task: Burn fuses
I> Index : 1    SecurityMode    size: 4
I> Fuse Blob found
I> 
I> Burning fuses
I> 
I> Calculated H2 CRC ecc is 0x04a2b9b9
I> Fuse is already burned with the same value
E> FUSE: Could not write Fuse: 0x3a.
E> FUSE: Failed burn fuses as per fuse info.
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x6217002c)
E> Top caller module: FSKP, error module: FUSE, reason: 0x2c, aux_info: 0x00
I> Busy Spin
7

hello uvealonso,

just an FYI,
here’s limitation with FSKP package for burning SecurityMode after SBK+PKC have already been fused.
so.. you should working with odmfuse.sh directly for burning additional fuses.

it seems a fuse has already burned according to the logs.
were you able to boot this target for entering linux? you may execute nv_fuse_read.sh to read fuses for checking.
besides, it’s able to check secureboot authentication scheme via BR_CID. please also share your BR_CID for cross check.

8

Hello JerryChang,

Here is the additional information you requested.

Fuse state from target Linux (nv_fuse_read.sh)

Running nv_fuse_read.sh on the target, I get the following:

odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0xHEX_CODE_OF_PKH_NOT_ZERO
boot_security_info: 0x00003209
odmid: 0x0000000000000000
pk_h1: 0x00000000...(all zeros)
pk_h2: 0x00000000...(all zeros)
security_mode: 0x00000000
reserved_odm0-7: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet0-3: 0x00000000
ecid: 0xHEX_CODE

This shows that PKC is programmed, BootSecurityInfo is set to SBK+PKC (0x3209), but SecurityMode is still reported as 0x0.

Fuse state from host (flash.sh --read-info)

I also ran:

./flash.sh --read-info -u ../pkc/PKC.pem -v ../sbk/SBK.hex \
    jetson-orin-nano-devkit nvme0n1p1

Relevant fuse output:

PublicKeyHash: HEX_CODE_FOR_PKH_NOT_ZERO
BootSecurityInfo: 00003209
ArmJtagDisable: 00000001
SecurityMode: 00000000
OdmLock: 00000000
OdmId: 0000000000000000
ReservedOdm0-7: 00000000
Uid: HEX_CODE

This is consistent with what is reported from Linux on the target: SecurityMode remains 0.

BR_CID from BootROM (RCM)

From the flash.sh log, during BootROM communication, I can see the BR_CID being reported successfully:

[   1.2478 ] BR_CID: 0xA9012344705DE5032C00000016FE81C0

This BR_CID was obtained while communicating with the BootROM in RCM mode.

Summary

  • SBK + PKC are programmed and functional.

  • BootSecurityInfo is set to 0x3209.

  • Both nv_fuse_read.sh and flash.sh --read-info report SecurityMode = 0x0.

  • During fuse-burning attempts, MB2/FSKP reports:

    Fuse is already burned with the same value

  • BootROM communication works correctly and BR_CID is available.

Thank you.

9

hello uvealonso,

please also burn FUSE_KEYS_PSC_STATIC_OEM since you’ve OEM_K1/K2 keys. PscOdmStatic will affect the function of PV Key Encrypt/Decrypt UEFI.
for PscOdmStatic, we recommend burning it to 0x60, which sets the purpose of:
– OEM_K1 to encryption. (see-also OEM_K1_PURPOSE=0x0)
– OEM_K2 to KDK(key derive key) (see-also OEM_K2_PURPOSE=0x6)

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="PscOdmStatic" size="4" value="0x60"/>
    <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>
11

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