Error during fuse

Robotics & Edge Computing Jetson Systems Jetson Orin NX
1

Hello,

It’s a follow up of “ Flashing with l4t_initrd_flash.sh failed after burning OemK1 ”. I try to burn “SecurityMode” to 1 to lock my system. I previously burn the other fuses I needed.

To build the fuses blob I used “sudo FAB=300 BOARDID=3767 BOARDSKU=0000 BOARDREV=G.3 CHIPREV=1 CHIP_SKU=00:00:00:D3 FUSELEVEL=fuselevel_production ./odmfuse.sh --noburn --auth PKC -i 0x23 -k pkc.pem -X fuses_config jetson-orin-d131”

fuses_config only contain

Then I unpack the fuleblob archive and run the script with the command “sudo ./fusecmd”

The burn fail with the following error

I> Burning fuses
I>
I> Calculated H2 CRC ecc is 0x1ed1c47d
E> FUSE: Failed to reset bit: 0, for fuse: 0x3a.
E> FUSE: Could not write Fuse: 0x3a.
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: 0x62170413)
E> Top caller module: FSKP, error module: FUSE, reason: 0x13, aux_info: 0x04
I> Busy Spin

Does the command I used to generate the blob is correct?

Below the log of the fuse command

log_fusecmd_20250908_142130.txt (42.3 KB)

Below the log from the debug UART

fuse_error_20250908_142130.txt (16.2 KB)

Best regards

3

hello AFR,

may I double check.. is this fuse.xml with SecurityMode variable only?
for instance,

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

Hello JerryChang,

Yes, fuses_config only contain securityMode with the value you provide.

Sorry I didn’t saw that the value was not mention in my previous post

Best regards

7

hello AFR,

there’s -p options with odmfuse.sh to set production mode.
please try with below command-line.
$ sudo FAB=300 BOARDID=3767 BOARDSKU=0000 BOARDREV=G.3 CHIPREV=1 CHIP_SKU=00:00:00:D3 FUSELEVEL=fuselevel_production ./odmfuse.sh --noburn --auth PKC -i 0x23 -p -k pkc.pem jetson-orin-d131”

8

Hello,

I try with the option -p, but I got the same error.

fuse_error_20250908_152522.txt (16.2 KB)

I reset my system and run nv_fuse_read.sh, so far the “security_mode” is still 0.

Best regards

9

hello AFR,

is it correct auth type? did you have SBK keys?

let’s try online approach,
please use fuse.xml with SecurityMode variable only, and putting your target enter forced-recovery mode for running below.
$ sudo ./odmfuse.sh -X fuse.xml -i 0x23 -k PKC.pem <target_config>

10

Hello JerryChang,

I do not use SBK key on my system. I try the online approach and the result is the same, find bellow the log.

log_fusecmd_20250908_161002.txt (94.7 KB)

fuse_error_20250908_161002.txt (28.4 KB)

Best regards

12

hello AFR,

you’re able to boot-up this target, right?
could you please run the fuse read script for checking fuse variables.

13

Hello,

Yes I’m able to boot the system without issue.
Here the value return by nv_fuse_read.sh

odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000001
public_key_hash: hash_pkc
boot_security_info: 0x00000201
odmid: 0x0000000000000000
pk_h1: hash_pck1
pk_h2: hash_pkc2
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: 0x84726272c3280401

Best regards

14

hello AFR,

please try again with below xml file,

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

or..
it should using -p options with odmfuse.sh to set production mode directly.
$ sudo ./odmfuse.sh -i 0x23 -k PKC.pem -p <target_config>

15

Hello JerryChang,

I try both and got the same result each time.

run “sudo ./odmfuse.sh -X fuses_config -i 0x23 -k pkc.pem jetson-orin-d131” with fuses_config containing:

fuse_error_20250909_093719.txt (28.5 KB)

Run “sudo ./odmfuse.sh -i 0x23 -k pkc.pem -p jetson-orin-d131”

fuse_error_20250909_093855.txt (28.4 KB)

Best regards

16

Hello JerryChang,

Can you confirm that I should see “security_mode: 0x00000001” when running the command “sudo nv_fuse_read.sh” if the fuse was well burn?

I re-analyse all the logs of my different tests yesterday and in one of it, it seem the fuse was burned, I skipped this log yesterday because the securityMode was still 0 after the reboot of the system.

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-0-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x00a4c892
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> Successfully burnt fuses as per fuse info
I> Index : 1 SecurityMode size: 4
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished

So I’m now thinking the SecurityMode is always read at 0 even if it burn. Is there a way to read the value of this fuse to confirm the system is locked?

Best regards

17

hello AFR,

FYI,
as long as SecurityMode is burned, you will get 0xffff... when reading fuse variables.
that’s expected for security concern, it doesn’t matter if they are burned or not.

let’s dig into your fuse failure, Could not write Fuse: 0x3a
may I double check which L4T version you’re workring with?

18

Hello,

I’m using L4T r36.4 (Jetpack 6.1)

Does fuse 0x3a is SecurityMode or is it something else?

Best regards

19

hello AFR,

fuse 0x3a it’s a CRC fuse which is calculated from SecurityMode.
Could not write Fuse meant it was burned previously, this CRC fuse already has values.

let’s give it a try to read the fuses by nv_fuse_read.sh and also flash script with --read-info for comparison.
[on target] $ sudo nv_fuse_read.sh
[through RCM mode] $ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

20

Hello JerryChang,

Here the log for reading the fuses value using flash.sh

log_flash_cmd.txt (20.8 KB)

uart_debug_flash_cmd.txt (6.3 KB)

Here the result of nv_fuse_read.sh

sudo nv_fuse_read.sh
[sudo] password for administrator:
odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000001
public_key_hash: hash_pkc
boot_security_info: 0x00000201
odmid: 0x0000000000000000
pk_h1: hask_pkc1
pk_h2: hash_pkc2
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: 0x84726272c3280401

In both case the value of SecurityMode is 0.

Best regards

21

hello AFR,

CRC fuse is burn as long as SecurityMode is added in the xml file.
so.. it’ll burn CRC even you had below in the xml file, had you done this before?

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

Hello JerryChang,

It’s possible, I do not remember all the config file I used on my different tests I did over the past few month. Is there a way to bypass it? Or does it mean the board is lock in this mode?

Best regards

23

hello AFR,

unfortunately, your board is locked in this mode.
that’s why developer guide recommends burning all the fuses you need in a single operation.

24

Hello JerryChang,

Thank you for the support. it was simpler to burn fuse separately for development. We will burn all the fuse in 1 time on the next board.

Best regards