Help burning fuses after PublicKeyHash fuse was burned

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin NX
, ,
1

Hello,

I need help burning fuses after an unsuccessful attempt left my board with partially burned fuses.

The issue that caused the partially burned state is that the BootSecurityInfo fuse had an initial value of 0x1e0.
From what I gathered the bits set are reserved bits and do not to anything. But my fuse.xml configuration had
attempted to add the value of 0x209 to this fuse. Resulting in the “trying to turn 1 into 0” error, and the fuse process being stopped.

Note that this was not reported by the odmfuse.sh script as an error! The error was only observed on serial.
After the failed attempt the odmfuseread.sh reports the following values:

PublicKeyHash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx(my key hash)
BootSecurityInfo: 000001e0
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

Looks like only the PublicKey was fused.
Seeing that the production mode is not set. Fuses should still be burnable?
After fixing the value to 0x3e9(0x209 | 0x1e0). The --test command looks good on serial

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

Last part of serial output:

I> Burning fuses
I> 1. Start PublicKeyHash burn
I> Fuse is already burned with the same value
I> 1. PublicKeyHash burnt successfully
I> 
I> 2. Start SecureBootKey burn
I> Dry run detected, returning now.
I> 2. SecureBootKey burnt successfully
I> 
I> 3. Start PscOdmStatic burn
I> Dry run detected, returning now.
I> 3. PscOdmStatic burnt successfully
I> 
I> 4. Start OemK1 burn
I> Dry run detected, returning now.
I> 4. OemK1 burnt successfully
I> 
I> 5. Start OemK2 burn
I> Dry run detected, returning now.
I> 5. OemK2 burnt successfully
I> 
I> 6. Start BootSecurityInfo burn
I> Dry run detected, returning now.
I> 6. BootSecurityInfo burnt successfully
I> 
I> Successfully burnt fuses as per fuse info
I> Index : 1    PublicKeyHash    size: 64
I> Index : 2    SecureBootKey    size: 32
I> Index : 3    PscOdmStatic    size: 4
I> Index : 4    OemK1    size: 32
I> Index : 5    OemK2    size: 32
I> Index : 6    BootSecurityInfo    size: 4
I> Index : 7    SecurityMode    size: 4
I> Fuse Blob found
I> No RPMB provisioning details is found. Skip RPMB Provisioning.
I> FSKP finished

But the real fuse commad fails! Again, this is only observable on serial odmfuse.sh does not return an error!

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

serial output:

I> Burning fuses
I> 1. Start PublicKeyHash burn
I> Fuse is already burned with the same value
I> 1. PublicKeyHash burnt successfully
I> 
I> 2. Start SecureBootKey burn
E> Fuse burn failed
E> error = 0x17173002 in fuse_burn
E> Error = 0x17173002 in tegrabl_fuse_write
E> 2. Failed to burn SecureBootKey
E> Failed to burn fuses as per fuse info
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62173002)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x30
I> Busy Spin

Since the production mode fuse is not burned, why is it that this fails? We have 6 affected systems now because of this error and would like to fuse them properly in order for our security features to work.
Also, why did our systems come with fuse values being nonzero?

Please advise,
Thank you

5

Hi,
Would like to confirm status of the Orin NX module, so it is

  1. PKC key is fused
  2. SBK and KEK keys are not fused
  3. Production bit(SecurityMode) is not fused

Please confirm if above status of the module is correct. And do you use Jetpack 6.2 or 6.1?

6

Hi Dane,

Both odmfuseread.sh and nv_fuse_read.sh show zeroes on all the fuses except PublicKeyHash, and BootSecurityInfo(see output in my initial post)

  1. PKC is fused
  2. SBK and KEK are not fused.
  3. Production bit is not fused.

I use jetpack 5.1.4.

7

hello dv345,

as mentioned by developer guide, Burn Fuses with the Fuse Configuration file.
re-cap as below…
NVIDIA recommends burning all the fuses you need in a single operation.

that’s true, it’s burned by manufacturing by default.

you should run the odmfuse.sh command with -k option to assign your PKC key to have additional fuses burned.
for instance,
$ sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k <pkc.pem> <target_config>

8

I’ve managed to successfully program the remaining fuses and flash. The problem was that, unlike with the value of PKC, the firmware did not allow for the other fuses to be programmed again with the same value.

I> Burning fuses
I> 1. Start PublicKeyHash burn
I> Fuse is already burned with the same value
I> 1. PublicKeyHash burnt successfully
I> 
I> 2. Start SecureBootKey burn
E> Fuse burn failed
E> error = 0x17173002 in fuse_burn
E> Error = 0x17173002 in tegrabl_fuse_write
E> 2. Failed to burn SecureBootKey
E> Failed to burn fuses as per fuse info
E> FSKP: Failed to burn fuses.
C> Task 0x0 failed (err: 0x62173002)
E> Top caller module: FSKP, error module: FUSE, reason: 0x02, aux_info: 0x30
I> Busy Spin

By removing the values, one by one from my fuse.xml file, I can only conclude that all the values were programmed in the previous attempts, all but the faulty BootSecurityInfo and SecurityMode which came after it… The final xml only included 2 entries BootSecurityInfo
and SecurityMode.

It would help a lot if odmfuseread.sh actually returned something usefull. It doesn’t display SKB, Oem status at all…
It would also help if the firmware ignored RESERVED bits, and if odmfuse.sh returned some errors if there is an error…

Is there any documetation about BootSecurityInfo values being set in manufacturing? The previous systems we had did not run into this issues. I can only assume that the value was not set in previous revisions.

Thank you for your help.

9

hello dv345,

odmfuseread.sh should shows SBK, KEK…etc in fuse_info, but, it’ll be 0xff... as long as SecurityMode is burned. that is expected for security concern.
just an FYI, it’s now using flash script for reading fuse,
for instance, $ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

10

odmefuseread.sh does not return anything regarding SBK even with SecurityMode enabled.

From flash command i get nothing regarding fuses:

sudo ./flash.sh --read-info -u $KEYS_DI/rsa-1_priv.pem -v $KEYS_DIR/sbk_key jetson-orin-nano-devkit internal


Board ID(3767) version(301) sku(0000) revision(G.1)
Chip SKU(00:00:00:D3) ramcode(1) fuselevel(fuselevel_production) board_FAB(301)
ECID is 0xE9012344705DF3430C0000000F030100

==== Fuse Info (/Linux_for_Tegra/bootloader/) ====
cat: /Linux_for_Tegra/bootloader/: Is a directory
11

hello dv345,

my bad, flash script for reading fuse should works on JP-6.

anyways,
may I know what’s your command-line to execute odmfuseread.sh ?
did you put the device enter forced-recovery mode as well?

12

sudo ./odmfuseread.sh -i 0x23 -k pkc.pem -S sbk_key jetson-orin-nano-devkit

PublicKeyHash: <hash val>
BootSecurityInfo: 000003e9
ArmJtagDisable: 00000000
SecurityMode: 00000001
SwReserved: 00000000
DebugAuthentication: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
15

hello dv345,

may I know what’s the current status?
it looks okay, it’ll return failure if you’re using an incorrect SBK key.

16

The original problem is solved, my main concern now is how to get SBK status at least, so that in the future this doesn’t happen again. Fuse read script should at least return some form of status forr SBK, OEM etc.

Also where can one find information about fuse default values? This all started because BootSecurityInfo had a value of 0x1e0 already programmed at manufacturing, our previos SOMs did not have it.

17

hello dv345,

you may check BootSecurityInfo for understanding the board authentication types.
for instance,
you’ve enable below…

Boot Security Info
Bits interpreted by boot software with following mapping:

where:
Bits [2:0] 001b: 3072-bit RSA
Bit [3] secure boot encryption scheme (SBK) enable
Bits [8:4] Not available and may not be logic 0 by default
Bit [9] ODM Key Valid

ya, fuse value for boot_security_info was burned (by manufacturing) to 0x1E0 now.
please refer to the latest Jetson Orin Fuse Specification, v1.4 for clarification.
there’s no impact to the real function on Jetson module.

18

There is an impact on the fusing process. If you try to write something to those bits it will fail, and odmfuse.sh will not return an error.

Debugging this would have been easier with additional information, like error codes, or SBK status(programmed/not programmed).

19

hello dv345,

that’s due to once a fuse bit is set to 1, you cannot change its value back to 0.
besides, that’s why it recommends burning all the fuses you need in a single operation in the developer guide.