Jetson Orin Nano 8GB no output after burning SecurityMode fuse on JNX41S carrier

Robotics & Edge Computing Jetson Systems Jetson Orin Nano
1

Hello,

I just attempted to prepare a Jetson Nano Orin 8gb for production deployment by burning the security fuse. The board is now unresponsive with no output on any interface. Here are the details:

Initial State:

  • JNX41S carrier board with Jetson Orin Nano 8GB

  • ODMK1 and ODMK2 fuses already burned

  • Software installed on external NVMe (attached to carrier)

  • Board successfully booting with full disk encryption (JetPack 5.1.4)

Steps Executed:

  1. Put board into recovery mode

  2. Read current fuse state:

./odmfuseread.sh -i 0x23 orin_nx_JNX42

Results showed:

PublicKeyHash: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000003e0
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
  1. Burned security fuse:
sudo ./odmfuse.sh -X fuses.xml -i 0x23 orin_nx_JNX42

With fuses.xml containing:

xml

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

Current State After Burning:

  • Board consuming 0.2A at 12V

  • SIM card LED is illuminated

  • No output on UART

  • No output on HDMI

Can anyone help me understand what might have happened? I’m particularly puzzled that there is absolutely no output on any interface anymore.

Could you also confirm that flashing the SecurityMode fuse after having a working OS installed is a valid workflow? Or should it be burned before any OS is flashed on the device?

Any assistance would be greatly appreciated.

Please find the output of the flashing host attached

fuse.txt (81.0 KB)

5

hello spam8pw3w,

you may refer to Jetson Orin Fuse Specification for checking FUSE_BOOT_SECURITY_INFO_0.
as you can see..
it’s bits [2:0] for Secure Boot Authentication Scheme,
it’s bit [3] for secure boot encryption scheme (SBK) enable.
however, your fuse xml BootSecurityInfo: 000003e0 has toggle bit [9] to have ODM key valid only. is this intended?

just an FYI,
the “OemKeyValid” bit in fuse “BootSecurityInfo” (not SecurityMode) controls if the boot images need to be encrypted/signed or not.
typically, we’ll also burn PKC/SBK keys, so that the boot image authentication by PKC and decryption by SBK (technically it’s keys derived from SBK) to have secure boot enabled.

according to above, it’s unexpected to have a target fuse without PKC/SBK.

6

Yes the ODM key valid bit set to enable is intended based on this post here: Fusing OemK1 for Disk Encryption - #31 by chinmaypen

Since i dont specifically need secure boot, just the disk encryption.

I can of course try to put up a setup that also has secure boot enabled (in case that is recommended), but im mostly concerned about people stealing my external drives and then being able to read them.

What confuses me most is that I had a perfectly fine setup that seems bricked after “only” setting the SecurityMode fuse to 1. (Which is a process (setting all the other fuses, flashing software on, then burning the SecurityMode fuse) that I used on many Xavier NX boards)

7

hello spam8pw3w,

you don’t need secureboot to have disk encryption enabled.
please see-also similar thread, such as Topic 256705 for the steps.

8

Thanks for your reply! Lets maybe split it into sub-questions

Question 1: My Jetson Nano Orin SoM seems to be broken after setting the SecurityMode fuse

Can you confirm that

Should not break the SoM into the unusable state (as described in the “Current State After Burning” in my first post).

Im just asking to verify that since Jetson SoMs are not the cheapest things to brick

Question 2: Did I follow an incorrect flashing process?

I used the following to create a working system with full disk encryption:

  • sudo ROOTFS_ENC=1 ./flash.sh -i sym2_t234.key -c bootloader/t186ref/cfg/flash_t234_qspi.xml --no-systemimg orin_nx_JNX42 internal

  • sudo ROOTFS_ENC=1 ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_t234_nvme_rootfs_enc.xml -i ./sym2_t234.key --external-only -S 110GiB --showlogs --network usb0 orin_nx_JNX42 nvme0n1p1

Could that be the reason why the SoM bricked when setting the SecurityMode fuse?

Question 3: Secureboot

Are there workflows that are equally simple to what is mentioned in Flashing Support — Jetson Linux Developer Guide documentation to bring up a system with secureboot? (But I take that SecureBoot is not required for my attacker scenario)

9

hello spam8pw3w,

>> Q1
it should not brick the device by setting the SecurityMode fuse,
however, please refer to An Example: Fusing the Three PKC keys for sample fuse configuration, it normally having PKC/SBK keys with relative BootSecurityInfo for toggling SecurityMode.
note, fuse burning operations are high-risk because they cannot be reversed. after the SecurityMode fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.

>> Q2
it looks correct, please setup serial console to gather the UART logs for detais.

>> Q3
see-also above replies in Q1, you must fuse a target to enable secureboot, fuse-based bootloader secure boot so that the root-of-trust can start from the BootROM.
you then given the same keys for image flashing.

10

Hi,

Once SecurityMode is burned:

  • The chip will enforce the security policy defined by the other fuses.

  • If those other fuses don’t contain valid boot authentication keys that match the flashed boot content, the BootROM stops — and you see no output.

  • The host recovery mode USB might still enumerate, which means the chip isn’t physically dead, it just won’t run your boot content. It’s a security lockout, not a hardware failure.

  • This is the same mechanism documented in the Jetson Fuse Specification: SecurityMode should be burned after all key and policy fuses are set correctly, because it blocks additional fuse programming and enforces the policy.

Suggested next steps:

  1. Connect a serial console (UART) and check for BootROM messages. Even “no output” can sometimes show something if the UART is set correctly and the policy triggers a failure log.

  2. If the SoM still enumerates in recovery mode (lsusb showing NVIDIA APX), you can reflash. But you’ll need to either:

    • Fuse proper PKC/SBK + BootSecurityInfo values that match your signed boot content before locking SecurityMode.

    • Reflash a boot chain that matches the current policy if the policy was already correctly defined.

  3. Avoid burning SecurityMode until you have a validated secure boot image and matching fuse config.

11

@mac.pinnock

Thanks for your response. I have just checked and there is no output on UART and neither on dmesg on the host pc.

I cross checked the flashing setup for faults with another SoM on the an equal carrier where I receive something like

[791228.201549] usb 1-5: new high-speed USB device number 95 using xhci_hcd
[791228.352759] usb 1-5: New USB device found, idVendor=0955, idProduct=7523, bcdDevice= 4.01
[791228.352775] usb 1-5: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[791228.352783] usb 1-5: Product: APX
[791228.352789] usb 1-5: Manufacturer: NVIDIA Corp.
[791234.980388] usb 1-5: USB disconnect, device number 95

on dmesg. There is nothing for the bricked som.

There is also nothing on lsusb that resembles an nvidia som.

Regarding the suggested next steps:

  1. already done, see first post
  2. the setup had booted before successfully
  3. that what i did (at least i hope)

ill now follow up with JerryChang’s answer

12

@JerryChang

Q2:

So I retried the procedure again with another SoM. Same result: bricked SoM as described in the first post. I tried to capture as much log output as possible.

Find my UART log here:

uart-fuseburn.txt (20.9 KB)

–

Ill now try your suggestions from Q1 and Q3 to burn a full setup incl secure boot fuses burned.

Is there by any chance any set of instructions in the degree of detail as Orin Nano 8Gb dev-board issues with flashing encrypted root_fs of Jetpack 5.1.2 - #7 by isapient for my situation?

13

it’s UART logs of fuse burn, do you have logs for target booting up?

14

No, since the target does not boot at all after the burn anymore and is in the state described in “Current State after burning”. Since I can replicate this behavior now (bricked 2 SoMs) I suspect that there is something systematically wrong with the approach.

15

hello spam8pw3w,

as mentioned, SecurityMode should not be enabled individually.
it normally having PKC/SBK keys with relative BootSecurityInfo for toggling SecurityMode.