Fuse Burning Failure on Jetson Orin Nano JP6.2.2 (r36.5)

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Was burning fuses with such config (values for keys were changed for posting on the forum)

<genericfuse MagicId="0x45535546" version="1.0.0"> 

<fuse name="ArmJtagDisable" size="4" value="0x1"/> 

<fuse name="CcplexDfdAccessDisable" size="4" value="0x1"/>

<fuse name="ReservedOdm4" size="4" value="0x11111111"/> 

<fuse name="ReservedOdm5" size="4" value="0x22222222"/> 

<fuse name="ReservedOdm6" size="4" value="0x33333333"/> 

<fuse name="ReservedOdm7" size="4" value="0x44444444"/>

<fuse name="PublicKeyHash" size="64" value="0x9f0ebf0aec1e2bb30c0838096a6d9de5fb86b1277f182acf135b081e345970167a88612b916128984564086129900066255a881948ab83bebf78c7d627f8fe84"/> 

<fuse name="SecureBootKey" size="32" value="0x123456789abcdef0fedcba987654321000112233445566778899aabbccddeeff"/>

 <fuse name="OemK1" size="32" value="0xf3bedbff9cea44c05b08124e8242a71ec1871d55ef4841eb4e59a56b5f88fb2b"/> 

<fuse name="BootSecurityInfo" size="4" value="0x20b"/> 

<fuse name="SecurityMode" size="4" value="0x1"/> 
</genericfuse>

with this command:
sudo ./odmfuse.sh -i 0x23 -k ecp521.pem -S sbk.key -X fuse_prod_jp6.xml jetson-orin-nano-devkit

Somehow BootSecurityInfo and SecurityMode were not burned.

Fuse reading is done. The fuse values have been saved in: /home/nvidia/nvidia/nvidia_sdk/JetPack_6.2.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/bootloader/fuse_info.txt
PublicKeyHash: 9f0ebf0aec1e2bb30c0838096a6d9de5fb86b1277f182acf135b081e345970167a88612b916128984564086129900066255a881948ab83bebf78c7d627f8fe84
BootSecurityInfo: 000001e0
ArmJtagDisable: 00000001
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 11111111
ReservedOdm5: 22222222
ReservedOdm6: 33333333
ReservedOdm7: 44444444

Unfortunately i didn’t read debug UART when was making first burning attempt.
But when was trying to burn <fuse name="BootSecurityInfo" size="4" value="0x20b"/> separatelly afterward, I got via debug UART this:

[0010.834] I> MB1: MSS reconfig completed
I> FSKP (version: 0.0.0.0-t234-54845784-0793996d)
I> t234-A01-1-Silicon (0x12347)
I> Emulation:
I> Entry timestamp: 0x00a5ac95
I> Regular heap: [base:0x40040000, size:0x10000]
I> DMA heap: [base:0x273800000, 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
E> FUSE: Failed to reset bit: 0, for fuse: 0x0.
E> FUSE: Could not write Fuse: 0x0.
E> FUSE: Could not write Fuse: 0x0.
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

Hardware:

  • Module: P3767-0003 (Orin Nano 8GB), Chip SKU 0xD5, FAB 301 H.1

  • Carrier: Waveshare JETSON-ORIN-IO-BASE-H (clone of P3768-0000)

  • BSP: JP6.2.2 / R36.5.0

  • Config used for fuse burn: jetson-orin-nano-devkit

3

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

Based on the provided context, it appears that you are attempting to burn fuses on a Jetson Orin Nano device using the odmfuse.sh script. However, you encountered an issue where the BootSecurityInfo and SecurityMode values were not burned successfully.

To troubleshoot this issue, let’s break down the command you used to burn the fuses. You mentioned that you used a command with config values for keys, but you didn’t provide the exact command. However, based on the context, I can infer that you likely used a command similar to the following:

sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config>

Or, if you were burning additional fuses on a device that already had a PKC key fused:

sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k <pkc.pem> <target_config>

To resolve the issue, I recommend checking the following:

  1. Fuse Configuration File: Verify that your fuse configuration file (<fuse_config>) contains the correct values for BootSecurityInfo and SecurityMode. Make sure that these values are correctly formatted and match the expected values for your device.
  2. Chip ID: Ensure that the chip ID (<chip_id>) you provided matches the actual chip ID of your device. You can find the chip ID in the device’s documentation or by using a tool like lspci.
  3. Target Configuration: Verify that the target configuration (<target_config>) you provided matches the actual configuration of your device. You can find the target configuration in the device’s documentation or by using a tool like lspci.
  4. PKC Key: If you were burning additional fuses on a device that already had a PKC key fused, ensure that the PKC key file (<pkc.pem>) you provided is correct and matches the key that was previously fused to the device.
  5. Debug UART Output: Review the debug UART output to see if there are any error messages or warnings that can help you identify the cause of the issue.

To compare the burning process with and without the PKC key, here are the key differences:

  • When burning fuses without a PKC key, you use the following command:
sudo ./odmfuse.sh -X <fuse_config> -i <chip_id> <target_config>
  • When burning additional fuses on a device that already has a PKC key fused, you use the following command:
sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k <pkc.pem> <target_config>

The main difference between these two commands is the addition of the -k option and the PKC key file (<pkc.pem>) in the second command. This option tells the odmfuse.sh script to use the provided PKC key to authenticate the burning process.

In summary, to resolve the issue, you should verify that your fuse configuration file, chip ID, target configuration, and PKC key (if applicable) are correct. Additionally, review the debug UART output to identify any error messages or warnings that can help you troubleshoot the issue.

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

4
  1. Fuse XML is correct. Verified by odmfuseread — the fuses that were attempted (PublicKeyHash, ArmJtagDisable, ReservedOdm4-7) burned to the exact values in my XML. The XML format is fine.
  2. Chip ID and target config are correct. -i 0x23 is Orin (T234), jetson-orin-nano-devkit is correct for my Orin Nano.
  3. PKC and SBK keys are correct. Verified — odmfuseread.sh -k ecp521.pem -S sbk.key succeeds and returns valid fuse data. If keys were wrong, the readback would fail with USB timeout (per JerryChang’s comment in topic 353179).
  4. UART logs were captured and shared in my original post. They show the actual FSKP error codes:
    • BootSecurityInfo burn: Failed to reset bit: 0, for fuse: 0x0, reason: 0x13, aux_info: 0x04
6

hello vdoom.heretic,

here’re couple of items need to resolve.

(1) let me double check, is this target fused before?
according to your odmfuse commands..
sudo ./odmfuse.sh -i 0x23 -k ecp521.pem -S sbk.key -X fuse_prod_jp6.xml jetson-orin-nano-devkit
this is the fuse command to have additional fuse burn onto PKC/SBK devices.

(2) as you can see from Jetson Orin Series Modules Fuse Update Field Services Bulletin, we’ve update to the FUSE_BOOT_SECURITY_INFO_0 fuse for ALL Jetson Orin Series Modules.
the fuse value for boot_security_info was burned (by manufacturing) to 0x1E0 now.
for instance,

according to above,
this is incorrect BootSecurityInfo in your fuse configuration file.
you must have bitwise logically OR the desired value with 0x1E0 in the fuse programming flow.

7

Thanks for the clarification

  1. Confirming: this was the first burn on a fresh module. PKC, SBK, OemK1, and security info fuses were all included in the same XML for a single odmfuse.sh invocation. The -k and -S flags were used but the device had not been previously fused.

  2. I was not aware of the manufacturing pre-burn of BootSecurityInfo = 0x1E0. My XML used 0x20b instead of 0x1E0 | 0x20b = 0x3EB, which would explain the “Failed to reset bit” errors. I’ll re-burn with the correct value 0x3EB.

Question before I attempt recovery: with the corrected value 0x3EB, is the standard PKC/SBK invocation correct?

sudo ./odmfuse.sh -i 0x23 -k ecp521.pem -S sbk.key -X fuse_recovery.xml jetson-orin-nano-devkit-super

with

<fuse name="BootSecurityInfo" size="4" value="0x3EB"/>
<fuse name="SecurityMode" size="4" value="0x1"/>

Module: P3767-0003 (Chip SKU 0xD5), carrier: Waveshare JETSON-ORIN-IO-BASE-H. Will use jetson-orin-nano-devkit-super config this time.

8

hello vdoom.heretic,

that still incorrect. you should remove -k and -S flags for the fresh module.
for instance, $ sudo ./odmfuse.sh -i 0x23 -X fuse_recovery.xml jetson-orin-nano-devkit-super
it’s fuse script to burn fuse variables according to your xml file.
note, since you’ve SBK key, please also have ODM key valid (bit-9 of BootSecurityInfo) enabled as well.

anyways, you may sharing your latest fuse.xml file for cross-check.

9

Thanks @JerryChang.

Sharing the XML for cross-check:

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

Decoding 0x3EB:

  • 0x1E0 — factory pre-burn (bits 5-8)

  • bits 0-1 = ECDSA P-521 auth scheme (matches my burned PKC, ecp521.pem)

  • bit 3 = SBK encryption enabled

  • bit 9 = OemKeyValid (as you noted, required since SBK is burned)

Command:

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

Please confirm the XML is correct before I burn.

10

hello vdoom.heretic,

unfortunately, it still doesn’t looks correct.
please see-also developer guide, Burn Fuses with the Fuse Configuration file.
it’s fuse burning by using odmfuse.sh (-X option) script with the Fuse Configuration file.

as you can see of Jetson Orin Fuse Configuration File section.
please double check those examples carefully,
you should have all fuse variables within the xml file since you’re going to burn all the fuses you need in a single operation,
besides.. after the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.

11

Thanks @JerryChang !!! 🙏

It is working now. I managed to burn rest of the fuses on the the same half fused module.