Burning fuses doesn't work on latest Orin Nano

Robotics & Edge Computing Jetson & Embedded Systems Jetson Orin Nano
1

Hi, I’m having similar problems to others since a new revision of the Jetson Orin Nano was released with BootSecurityInfo set to a non-zero value. Those other posts didn’t lead to a solution for me, and it seems the manual has not been updated yet.

My OLD fuse.xml looks like:

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

and my revised one looks like:

<genericfuse MagicId="0x45535546" version="1.0.0">
  <fuse name="SecureBootKey" size="32" value="0xblah"/>
  <fuse name="OemK1" size="32" value="0xblah"/>
  <fuse name="BootSecurityInfo" size="4" value="0x3e9"/>
  <fuse name="SecurityMode" size="4" value="0x1"/>
</genericfuse>

and the result from serial:

I> FSKP (version: 0.0.0.0-t234-54845784-33c9168e)
I> t234-A01-1-Silicon (0x12347)
I> Emulation: 
I> Entry timestamp: 0x00a6f21a
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    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
3

hello wesmundoid,

had you ever burn this module yet? is this device able to boot-up?
please try below commands to read the fuse variables.
for instance,
$ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>

4

Hi Jerry,

yes it flashes fine without secureboot & encryption, via SDKM.

That command doesn’t need the keys because the fusing hasn’t happened:

sudo ./flash.sh --read-info -u rsa.pem -v sbk.key jetson-orin-nano-devkit nvme0n1p1
###############################################################################
# L4T BSP Information:
# R36 , REVISION: 4.3
# User release: 0.0
###############################################################################
ECID is 0x80012344705DF6453400000001010040
# Target Board Information:
# Name: jetson-orin-nano-devkit, Board Family: generic, SoC: Tegra 234, 
# OpMode: production, Boot Authentication: NS, 
# Disk encryption: disabled ,
###############################################################################
Error: either RSA key file and/or SBK key file are provided for none SBK and PKC protected target board.

but this works:

sudo ./flash.sh --read-info jetson-orin-nano-devkit nvme0n1p1
...
==== Fuse Info (/home/user/Linux_for_Tegra_JP6.2_release/bootloader/fuse_t234.bin) ====
PublicKeyHash: 293...354
PkcPubkeyHash1: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
PkcPubkeyHash2: 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
BootSecurityInfo: 000001e0
ArmJtagDisable: 00000000
SecurityMode: 00000000
SwReserved: 00000000
DebugAuthentication: 00000000
OdmInfo: 00000000
OdmId: 0000000000000000
OdmLock: 00000000
ReservedOdm0: 00000000
ReservedOdm1: 00000000
ReservedOdm2: 00000000
ReservedOdm3: 00000000
ReservedOdm4: 00000000
ReservedOdm5: 00000000
ReservedOdm6: 00000000
ReservedOdm7: 00000000
Sku: 000000d5
Uid: 400001010000003445f65d7004000000
OptEmcDisable: 0000000c

full output here:

flash_read_info.txt (23.2 KB)

5

hello wesmundoid,

it looks this board has fused with one PKC key already?
you should at least assign the same PKC key for flashing, could you please build from scratch to setup a fresh Jetpack release for image flashing?

6

Solved.

It’s stuck on BootSecurityInfo because I’m inadvertently trying to change 1’s to 0’s. So I amend BootSecurityInfo to the correct value and try again, and it fails.

When I do fuse query I see that PublicKeyHash is already done so realising that it will refuse to overwrite that fuse (even though I’m only trying to write the same value), I remove that from the xml, but it still fails.

The thing to realise is that it’s got a list of fuses to burn, in order, like this:

I> Index : 1    PublicKeyHash    size: 32
I> Index : 2    SecureBootKey    size: 32
I> Index : 3    OemK1    size: 32
I> Index : 4    BootSecurityInfo    size: 4
I> Index : 5    SecurityMode    size: 4

It’s refusing to re-write the next one in the list, SecureBootKey, but I didn’t realise this has already been written, because it doesn’t show up in the fuse query!

The logs don’t make it clear what’s going on.

All you have to do to remedy this is delete everything before the original failure point:

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

and run odmfuse again.

(of course, restore those lines for the next Jetson or you’ll ruin it)

So how do you deal with having a mix of old and new units? Personally I left the fuse xml from my key creation script with BootSecurityInfo as 0x209 but in my fusing script I query the existing BootSecurityInfo, OR it with 0x209 and sed that into the fuse xml.
(Each script run restores the original xml so the value reverts in case the next is an older unit)

There are more elegant ways, I know the keys and xml should be being dynamically generated for every unit but for dev&test units I’m reusing one set of keys.

1 Like
7

Hi @wesmundoid can I confirm your BootSecurityInfo was 0x3e9? I’m using 0x200 but I also see 0x209 in some places. Not sure why the reserved bits for your case would differ from mine (11110 vs 00000) since we’re both using Orin Nanos.

8

BootSecurityInfo was 0x0 for most of my Jetsons. My settings were 0x209.
I got a new one where it was 0x1e0, so combine them for 0x3e9, just for that one unit.

1e0 - 0001 1110 0000
209 - 0010 0000 1001
      0011 1110 1001 - 3E9

I had a quick look at your post and I think your OemK’s did burn, because it got past that point to burning BootSecurityInfo, they just don’t show up in the query because they’re secret.

I got the 0x209 value from the example here

The first 3 bits from the right are Secure Boot mode and the 4th activates it, according to Jetson Orin Fuse Specification - Application Note

And bit 9 is “ODM key valid” which activates the OEMK1 for disk encryption.

So I guess you aren’t trying to use Secure Boot.

I’ve seen other posts in passing that suggest you can do encryption without Secure boot like this one

You mention recreating the keys which worries me because won’t that mean they’ll be different to what’s already been fused?

Also It looks like you haven’t set SecurityMode yet, don’t we need that for any of this to take effect? Seek further advice first though, I don’t want you to brick your Jetson based on something I said!

1 Like
9

Thanks for your reply! I intend to use 0x209 eventually for secure boot. I was just wondering why the initial BootSecurityInfo for your case was 0x1e0 to begin with.

You mention recreating the keys which worries me because won’t that mean they’ll be different to what’s already been fused?

That’s right, they would be. But I’m using a fixed internal process to generate the keys from some values in the chip’s ROM, so each recreation will give the same key.

I’ll read and explore more, thanks for the links!

10

BootSecurityInfo was 0x1e0 for one new unit we bought, and I imagine any more we buy will be the same. Nvidia started setting that fuse at the factory.

0001 1110 0000

As the Fuse doc says, bits 8:4 are reserved for Nvidia’s own internal purposes, and they’ve set 4 out of those 5 for some reason known only to them.

It’s something to do with fuse encryption, and it doesn’t affect any feature we’re using, according to:

1 Like