I have just fused my Orin NX 16GB using JP 6.2, with 3k RSA key + sbk key. This is done on my custom carrier board, with the pinmux + device tree are working fine before fuse.
Here is my fuse command:
The fuse process looks good. After that I don’t see the board goes into recovery mode with usual buttons sequence (no USB device shown), there is nothing printed on debug serial as well. I don’t see any sign of the working Orin NX module :(, I guess it is bricked now.
Can you please enlighten me where I’m wrong, and is there any solution to rescure my Orin NX module? Thank you so much.
I’ve never actually worked on a fused unit, so I’m not much help with actual flash. However, one detail to be certain of is that some boot parameters normally found in “/boot/extlinux/extlinux.conf” would be a higher priority over content in binary partitions. Those parameters are no longer accepted when fuses are burned (e.g., the device tree via the FDT key/value pair is not longer used when fuses are burned). Only the partition with a valid signature will be accepted.
I don’t know the correct flash commands for specifying keys, but you’d need to post the exact Jetson model, and the flash command you used after the fuse burn. The theory is that flashing with your expected content and with the correct fuses would add a properly signed binary partition, but any previous partition (with a default NULL signature) would fail if not updated with the new key from a flash.
FYI, for those reading, it looks like it is using JP 6.2.
The problem is, after fused, the recovery USB doesn’t appear :( . So I can’t flash or doing any troubleshooting.
So, I I have to find out what is wrong with the fusing process, to prevent another bricked module. And solution to recover the bricked module if any.
and.. what’s the FUSE_RESERVED_SW_0 you’ve burned.
if you burn bit-3 and bit-23 of FUSE_RESERVED_SW_0, you’ll disable the device for entering RCM mode.
regrading to PscOdmStatic, we recommend burning it to 0x60, which sets the purpose of.
– OEM_K1 to encryption
– OEM_K2 to KDK(key derive key)
In “Jetson Orin Fuse Specification - Application Note” version 1.5 Mar 2025, the bits [4:8] are Reserved, and due to the Bulletin, it is default fused 0x1E0. There is no where to said it should keep Bit[4] = 0. This make me confused. Is there any secret regarding Bit[4] that we should avoid burning?
Regarding the FUSE_RESERVED_SW_0, I don’t think I have burned it (the field SwReserved is commented in the XML file). That means the RCM should be fine? But I don’t see it on the board after fused. Do you have any idea why?
Regarding the PscOdmStatic, thank you pointing it out, I will update my configuration.
PS: this is the first time it fused, you can see in the log, the fuse reading are all zero.
PS2: You mentioned PscOdmStatic to set OEM_K2 to be KDK . I can’t find much information regarding KDK, Key derive key, or Key decryption key from Jetson Orin Fuse Specification or Secure boot section in Developer Guide. Can you please share some details? And I guess I have to add KDK key as Kdk0 field in XML fuse configuration file?
As I said in the first post, there is nothing logged through debug UART.
Before fuse, I have OS running fine, also have logged throught Debug UART. But after fused, nothing. No RCM USB, no UART log.
BTW..
I see something wrong in your fuse commands and xml file.
is this your 1st time to fuse burn? please refer to Burn Fuses with the Fuse Configuration file, your command is going to have additional fuses burned onto SBKPKC target.
This is the first time the fuse command succeeded. I have tried before but using wrong –-auth mode (SBKPKC as you mentioned). It should be NS for the first time. for those wrong --auth mode, the fuse process doesn’t success, it stopped by kind of error not able to write USB, timeout .
anyways, it’s unexpected that you cannot enter RCM mode after fuse burning. (without fuse bit-3 and bit-23 of FUSE_RESERVED_SW_0)
are you able to put this Orin NX module to Orin Nano carrier board (i.e. developer kit) for confirmation?
I have tried. The same result, nothing on debug UART, no USB RCM.
Do you think the wrong --auth argument even when it not success, then a correct fusing, causes this brick? Or any reason you can think of? Thank you.
bootloader logs should be omitted after secureboot has enabled.
there should be LED to indicate power-on, please check it’s actually power-on, and let’s leave it for a while (as you may not see logs after enter ubuntu-os) for confirmation.
Hello Jerry,
The power LED is fine. I leave the board for minutes (hour) but it doesn’t seem that it is running. Nothing on Debug UART, its IP address is not online, …
The heatsink is hot, but the fan is not running as normal.
If you monitor “dmesg --follow” on your flash host PC, and put the Jetson in recovery mode, then plug in the recovery mode Jetson to the PC, is there any log line indicating the host PC knows the Jetson was plugged in to the USB? If so, then I think you still might succeed if you can get the right key files to be used during a flash.
I don’t know what would happen with serial console under a key-enforced boot. Any software in any partition other than the root filesystem would be rejected if it isn’t correctly signed by that specific key, and I would think that serial console would output something, but if it doesn’t and the hardware is still good, then this would probably be because some partition in eMMC is not correctly signed to match the fused key.
I assummed the Orin module above is bricked. Then I changed to a new Orin NX 16GB module. The fusing looks good. The module is working after fused, it is now having issue regarding UEFI secure boot, but I will open new thread for that.
For this fusing, I used following config file:
It has PscOdmStatic and BootSecurityInfo updated as your suggestion. But I found that the BootSecurityInfo should be 0x39 to fuse bit 9 ODM Key Valid also. Do you think that matters?
One more thing, as I have fused SecurityMode, it is able to update the BootSecurityInfo to 0x39?
BootSecurityInfo should be 0x3e9 as you’ve burned OEM keys,
I doubt there’ll be an issue after updating EKS image since you did not toggle ODM key valid bit.
BTW, please refer to Topic 341811 as see-also for OEM_K1/K2.
unfortunately, all additional fuse write requests will be blocked after the SecurityMode fuse is burned with a value of 0x1.
