Cannot burn key-type fuses (SecureBootKey, OemK1) incrementally after PublicKeyHash-only fuse burn — FSKP fails with "Could not write Fuse" regardless

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Platform: Jetson Orin Nano 8GB Devkit, BOARDID 3767, BOARDSKU 0005, FAB 300, BOARDREV T.1, CHIP_SKU 00:00:00:D5. JetPack 6.2 / L4T R36.4.3. PKC key is ECDSA P-256.

SUMMARY

I burned PublicKeyHash alone in a first operation (successfully). BootSecurityInfo/SecurityMode were never set in that same operation (left at factory-default 0x1e0/0x0). Any subsequent attempt to burn a key-type fuse (SecureBootKey or OemK1) via odmfuse.sh -k <pkc.pem> now fails at the hardware/FSKP level with “Could not write Fuse”, regardless of the fuse value used and regardless of --auth mode.

FIRST FUSE BURN (single operation, all fuses together)

Command: sudo ./odmfuse.sh -X fuse_config.xml -i 0x23 jetson-orin-nano-devkit

Result: process finished without a fatal error on host. Afterward, nv_fuse_read.sh confirmed boot_security_info=0x1e0 (factory default) and security_mode=0x0 — neither was burned. public_key_hash matched the intended value (confirmed burned). SecureBootKey/OemK1 cannot be read back (not exposed by nv_fuse_read.sh), so their state is unknown.

(In hindsight, BootSecurityInfo=0x209 encoded the RSA-3K scheme bit rather than ECDSA-256, and didn’t OR in the factory pre-burned value 0x1e0 — likely why the burn stalled before reaching BootSecurityInfo/SecurityMode.)

SECOND ATTEMPT — incremental (PublicKeyHash already fused)

Command: sudo ./odmfuse.sh -X fuse_config2.xml -i 0x23 -k pkc_priv.pem jetson-orin-nano-devkit

UART log:
I> Task: Burn fuses
I> Index : 1 SecureBootKey size: 32
I> Index : 2 OemK1 size: 32
I> Index : 3 BootSecurityInfo size: 4
I> Index : 4 SecurityMode size: 4
I> Fuse Blob found
I>
I> Burning fuses
I> 1. Start SecureBootKey burn
E> FUSE: Failed to burn fuse addr: 0x2fe.
E> FUSE: Could not write Fuse: 0x66.
E> FUSE: Could not write Fuse: 0x66.
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

Retried with the exact same SecureBootKey value used in the first attempt (in case of a bit-conflict from a prior partial burn) — identical failure, no “Fuse is already burned with the same value” message.

THIRD TEST — isolating OemK1 alone

Command: sudo ./odmfuse.sh -X fuse_oemk1_only.xml -i 0x23 -k pkc_priv.pem jetson-orin-nano-devkit

UART log:
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

Same error signature (err: 0x62170302, reason: 0x02, aux_info: 0x03) as with SecureBootKey alone, just a different fuse address/type ID. This rules out a value-specific bit conflict.

FOURTH TEST — --auth flag Tried explicitly setting --auth SBKPKC: sudo ./odmfuse.sh -X fuse_oemk1_only.xml -i 0x23 -k pkc_priv.pem -S sbk.key --auth SBKPKC jetson-orin-nano-devkit

Result: Error: wrong “–auth” option is set. The board’s authentication type is: NS. — the tool reports the board’s current authentication type as NS even though PublicKeyHash is already fused (likely because BootSecurityInfo was never set together with PublicKeyHash in the original burn, so no scheme is declared yet).

Retried with --auth NS (matching what the tool detected): sudo ./odmfuse.sh -X fuse_oemk1_only.xml -i 0x23 -k pkc_priv.pem -S sbk.key --auth NS jetson-orin-nano-devkit

Same identical failure as before (Could not write Fuse: 0x6a, err: 0x62170302).

QUESTIONS

1. Does this confirm that key-type fuses (SecureBootKey, OemK1) cannot be added in a follow-up odmfuse.sh operation once PublicKeyHash was burned separately without BootSecurityInfo declaring the scheme at the same time — i.e., is the scheme transition (NS → SBKPKC) only supported within the single original fusing operation?

2. What does err: 0x62170302 (module FUSE, reason 0x02, aux_info 0x03) mean specifically?

3. Is there any supported recovery path for a board already in this intermediate state, short of the fuse being permanently limited to PublicKeyHash-only Secure Boot (no SBK/OemK1/disk encryption)?

Device is a devkit used for testing/learning purposes, so a full re-flash / accepting Secure Boot without SBK+disk encryption is an acceptable fallback if there is truly no recovery path — but confirmation from NVIDIA on whether this is a known FSKP limitation would help decide how to proceed.

4

hello daniel.gomez3,

let me check your 1st fuse burn, please share the fuse_config.xml and the fuse read results for cross check.

5

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

PublicKeyHash: 1db788f844a2cbc1d9772f21dcbb15f0c63700e55192082d94bf56ccc7559cbdd6d1f0b4ab11026082b9426a947350823d7227167bcf9594dba25f403cc7a544 BootSecurityInfo: 000001e0 SecurityMode: 00000000

Try first:
sudo ./odmfuse.sh -X ~/jetson_keys/fuse_config.xml -i 0x23 jetson-orin-nano-devkit

Second try:
sudo ./odmfuse.sh -i 0x23 -X ~/jetson_keys/fuse_config2.xml --noburn jetson-orin-nano-devkit
sudo ./odmfuse.sh -i 0x23 -X ~/jetson_keys/fuse_config2.xml jetson-orin-nano-devkit

3er (with SBK key)
sudo ./odmfuse.sh -i 0x23 -S ~/jetson_keys/OemK1.key -X ~/jetson_keys/fuse_config2.xml jetson-orin-nano-devkit
Assuming zero filled SBK key...

4: ( with PKC y SBK)
sudo ./odmfuse.sh -i 0x23 -k ~/jetson_keys/pkc_priv.pem -S ~/jetson_keys/OemK1.key -X ~/jetson_keys/fuse_config2.xml jetson-orin-nano-devkit
Burning fuses. Please check the uart to get the result of fuse burning.
ERROR: failed to read rcm_state
Assuming zero filled SBK key

Thanks for looking into this. Here’s the requested information:

fuse_config.xml (first burn attempt):

Command used: sudo ./odmfuse.sh -X fuse_config.xml -i 0x23 jetson-orin-nano-devkit

(Note: SecureBootKey and OemK1 were mistakenly set to the same 32-byte value in this attempt — flagging for transparency, though I don’t believe it’s related to the current write failure since a later test isolating a fresh, distinct value for these fuses failed identically.)

Fuse read results (from nv_fuse_read.sh on target, current state):

public_key_hash: 0x1db788f844a2cbc1d9772f21dcbb15f0c63700e55192082d94bf56ccc7559cbdd6d1f0b4ab11026082b9426a947350823d7227167bcf9594dba25f403cc7a544
boot_security_info: 0x000001e0
security_mode: 0x00000000
odm_lock: 0x00000000

So public_key_hash matches the intended value from fuse_config.xml (confirmed burned). boot_security_info and security_mode remain at factory default — neither was burned in that first attempt. SecureBootKey and OemK1 cannot be read via nv_fuse_read.sh (not exposed), so their actual state is unknown from software alone.

Let me know if you need anything else (PKC public key, ECID, BR_CID, etc.).

6

hello daniel.gomez3,

please aware below as mentioned by developer guide.

NVIDIA recommends burning all the fuses you need in a single operation.

anyways,
there’re some erroneous in the 1st step.
we may ignore your 2nd, 3rd, 4th test trails at the moment,
for instance, boot_security_info remain the default pre-burn value 0x1e0.

please refer to Jetson Orin Fuse Specification for FUSE_BOOT_SECURITY_INFO_0.
it’s Bits [2:0] mapped to secureboot authentication scheme, it shows 0 means this is non-fused target.

please refer to Burn Fuses with the Fuse Configuration file.
you should at least toggle bit-0 for your 3072-bit RSA PKC key.
let’s try to have additional fuses burn onto this module. please give it a try with below fuse.xml file to burn your target again BootSecurityInfo only.

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

according to your fuse read results, your secureboot authentication scheme shows 0 means this is non-fused target.
in order to adding fuse, you should execute odmfuse script without a PKC to treat it as non-fused device.
for instance, $ sudo ./odmfuse.sh -X fuse.xml -i 0x23 jetson-orin-nano-devkit

8

Thanks for the guidance! One clarification before I burn this (since it’s irreversible): my PKC key is ECDSA P-256 (confirmed via openssl — 256-bit EC key), not RSA-3072. Per the Fuse Specification, bits[2:0] of BootSecurityInfo should be 010b (ECDSA P-256) rather than 001b (RSA-3072) in that case. Should I use 0x1e2 instead of 0x1e1? Want to confirm before burning given the fuse is one-time.

Thanks in advance

9

hello daniel.gomez3,

it’s crucial to configure secureboot authentication scheme correctly.
in this case, you must have BootSecurityInfo Bits [2:0] = 010b for ECDSA P-256 Curve.

10

Thanks — following your guidance, BootSecurityInfo now burns successfully (0x1e2, confirmed via flash.sh --read-info). SecurityMode is still unburned, so I understand the device is still open for additional fuses.

However, SecureBootKey and OemK1 still fail with the exact same error as before, now correctly using -k (since the board is now properly detected as PKC-protected after BootSecurityInfo was fixed):

sudo ./odmfuse.sh -X fuse_keys_only.xml -i 0x23 -k pkc_priv.pem jetson-orin-nano-devkit

UART:

Task: Burn fuses
Index : 1 SecureBootKey size: 32
Index : 2 OemK1 size: 32
Fuse Blob found

Burning fuses

  1. Start SecureBootKey burn
    FUSE: Failed to burn fuse addr: 0x2fe.
    FUSE: Could not write Fuse: 0x66.
    FUSE: Could not write Fuse: 0x66.
    FUSE: Failed burn fuses as per fuse info.
    FSKP: Failed to burn fuses.
    Task 0x0 failed (err: 0x62170302)
    Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03

So the BootSecurityInfo/-k fix resolved that specific fuse, but SecureBootKey/OemK1 are still rejected identically.

I noticed in the Jetson Orin Fuse Specification (DA-10877-001_v1.5) that SecureBootKey and OemK1 are listed as “Platform Security Controller” (PSC) fuses, each with an associated “TAG” fuse field (128-bit, e.g. FUSE_KEYS_SBK_0_TAG_0, FUSE_KEYS_OEM_K1_0_TAG_0) for “wrapped key” info, and that SBK “may be programmed in encrypted form, with decryption performed by PSCROM.” Our fuse_config.xml only specifies the plain key value, with no TAG. Separately, the same document states (in the Shadow Fuses section) that certain security fuses “must be programmed in the same burn session… without a reset between the two burn operations.”

Given PublicKeyHash was burned in a separate, earlier session (with a reset since), could this PSC/TAG requirement, or a same-session requirement, explain why SecureBootKey/OemK1 specifically cannot be added now, even though BootSecurityInfo can? Is there a way to provide the required TAG/wrapped format via odmfuse.sh, or is this fuse now permanently unreachable for this module?

11

Update: Following your guidance, we burned BootSecurityInfo=0x3EA (ODM Key Valid bit set), confirmed successfully via UART (“Successfully burnt fuses”) and independently via flash.sh --read-info (BootSecurityInfo: 000003ea). However, SecureBootKey/OemK1 still fail with the exact same error signature as before, ruling out the auth-scheme bits as the cause:

> FUSE: Failed to burn fuse addr: 0x2fe.
> FUSE: Could not write Fuse: 0x66.
> Task 0x0 failed (err: 0x62170302)
> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x03

More critically: after this BootSecurityInfo burn, the device no longer boots normally. We suspect this is expected given bit3 (SBK enable) is now set, but SecureBootKey was never confirmed burned.

We attempted recovery via RCM (QSPI-only reflash, flash.sh -u <pkc.pem> -v <sbk.key> -c bootloader/generic/cfg/flash_t234_qspi.xml <board> internal), testing multiple candidate SBK values including all-zero. Every attempt fails identically:

[ x.xxxx ] Sending bct_br
[ x.xxxx ] Sending mb1
[ x.xxxx ] ERROR: might be timeout in USB write.
Error: Return value 3

Notably, this occurs even with a completely unencrypted mb1 (-u only, no -v) — same failure point, same timing. We’ve ruled out host-side USB issues (ModemManager, autosuspend, multiple cables/ports all tested). This suggests BootROM itself is rejecting the RCM download outright given the current fused security policy.

Our open questions remain from the original post (PSC/TAG wrapped-key format for SecureBootKey/OemK1 via odmfuse.sh, and the same-burn-session requirement for shadow fuses), plus a new one: is there any way to recover RCM boot on a module where BootSecurityInfo declares SBK-enable/ODM-Key-Valid but the corresponding key fuses never successfully burned? Is this module still recoverable, or are we looking at a permanently bricked state?

12

hello daniel.gomez3,

all right, that’s why it recommends burning all the fuses you need in a single operation.
fuse burning operations are high-risk because they cannot be reversed.

let’s double check your fuse_config.xml in the very first stage,
if you’ve SBK/OEM_K1/OEM_K2 in the xml file, it should have those written to modules as well. it is impossible to read SBK, OEM_K1/K2 due to security concerns.

it usually due to a mismatch key,
an error in the very beginning image flash stage, (i.e. BootRom) if you given wrong key to abort flashing process.

please share the flash messages for checking BR_CID, which also contain the board authentication types.
for instance,
BR_CID: 0xA9012344705DF8881800000015008040, it’s a board fused with 3072-bit RSA PKC, enable SBK, enable ODM key valid bit.

13

Thanks for the quick check.

  1. Confirming: our very first fuse burn (before any of this troubleshooting) already included SecureBootKey and OemK1 together with PublicKeyHash and BootSecurityInfo in a single odmfuse.sh -X fuse_config.xml operation:

xml

<genericfuse MagicId="0x45535546" version="1.0.0">
  <fuse name="PublicKeyHash" size="64" value="0x<REDACTED>"/>
  <fuse name="SecureBootKey" size="32" value="0x<REDACTED>"/>
  <fuse name="OemK1" size="32" value="0x<REDACTED>"/>
  <fuse name="BootSecurityInfo" size="4" value="0x209"/>
  <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>

PublicKeyHash burned successfully; SecureBootKey/OemK1 failed with the same FUSE: Could not write Fuse: 0x66 error we’re still seeing today — even in this very first, single-session attempt. So the “burn everything together” recommendation was already followed from the start.

  1. BR_CID from our RCM attempts (consistent across every test, encrypted and unencrypted):
BR_CID: 0xAA012344705DF8C68400000006FF0140

Could you help us decode what this indicates for our board’s current auth state, the way you did for the 0xA9012344705DF8881800000015008040 example? We want to confirm whether BootROM currently sees SBK-enable / ODM-Key-Valid as active despite SecureBootKey/OemK1 never having burned successfully.

Regards,

14

hello daniel.gomez3,

this shows PKC with ECDSA P-256 Curve, enable SBK, enable ODM key valid bit.

it’s very likely your 1st fuse burn process has those keys written to modules. the fuse burning process has abort due to BootSecurityInfo mismatched (without 0x1e0 OR’ed).

please try again with the original (1st attempt) PKC/SBK key to re-flash your target.

15

Hello,

Following up — we tried the original (1st attempt) key as you suggested, but it still failed identically. After ruling out host-side USB issues, we tested one more possibility: since fuses are OTP (bits only ever go 0→1, never back), and we had two separate failed SecureBootKey burn attempts across different sessions (each aborting with the same FUSE: Could not write Fuse: 0x66 error), we suspected each failed attempt may have still latched some bits before aborting. We computed the bitwise OR of the two values we’d tried, and used that as the SBK for -v on flash.sh.

That worked — the device flashed successfully (“Secure Flashing completed”) and is now booting normally again.

So to close the loop: despite odmfuse.sh reporting Could not write Fuse on both SecureBootKey attempts, both partially wrote real bits to the OTP fuse, and the actual latched value ended up being the OR of the two. Thought this might be useful for you to know, in case it helps explain the burn failures for other users hitting the same error signature.

Thanks for your help getting us unblocked.

16

hello daniel.gomez3,

that’s good news, thanks for status update.