Writing fuses with reserved bits

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

Hi,

We have already designed a procedure to burn the fuses and we’ve successfully done for around 50 devices. We have just received some devices with non 0 content in BOOT_SECURITY_INFO fuse reserved bits. We didn’t expect that and get an error applying our custom value for such fuse:

E> Tried to set fuse bit 0 from 1 to 0

But OK, it’s our fault because it’s clearly explained in doc:

Bits [8:4] Reserved (may not be logic 0 by default)
...
Bits not listed are reserved

We’ve successfully apply our expected value by reading these bits, performing a logic OR with our custom value, updating our fuses file and burning the updated value. All right.

0x1e0 = 0...0 0001 1110 0000 -> already burnt bits 0x20b = 0...0 0010 0000 1011 -> our custom bits 0x3eb = 0...0 0011 1110 1011 -> updated with logic OR

However, we have doubts that this is the expected approach because of the warnings shown in doc:

IMPORTANT:
All ODM and manufacturing programmable fuses have the value of ZEROs when shipped to an ODM.
NVIDIA reserves the right to change the value of the reserved fuse bits at any time to improve the
manufacturability. A non-zero value can be expected at any time when read.
Customers are advised to not read the values of the reserved fuse bits and/or make any kind of decisions
based on them

How are we supposed to apply our custom value on BOOT_SECURITY_INFO fuse if we don’t read the reserved bits and make an OR based on them?

Also, what do latest bits mean?

Bit [11] OEM DICE1 Feature enable
Bit [13] FMC DICE Feature enable

I can’t find details of these features in any version of the doc, reviewed up to the one published 2 days ago (2025-04-28) https://developer.download.nvidia.com/assets/embedded/secure/jetson/agx_orin/Jetson-Orin-Fuse-Specification_DA-10877-001v1.5.pdf?__token__=exp=1746025240~hmac=399753739c8634b2a8806f26203ca506d3b792d3694207e1b5683de2cd50cf15 nor in the online Developer Guide Search — Jetson Linux<br/>Developer Guide 34.1 documentation

Thanks in advance,
jetxeberria

5 Likes
3

hello jetxeberria,

may I know what’s the actual use-case?

FYI, BOOT_SECURITY_INFO, Bits [8:4] as “Reserved” bits, they are used for fuse encryption. however, L4T does not support this feature.
please refer to Jetson Orin Fuse Specification for [ODM Field Programmable Fuses] section,
you should use RESERVED_ODM fuses instead of adding customize values onto BOOT_SECURITY_INFO .

4

Hello Jerry,

Sure, I have bootloader images encrypted with SBK + PKC.

We have followed the official Nvidia Documentation to do so for Jetson Orin Nano as explained here: Secure Boot — NVIDIA Jetson Linux Developer Guide 1 documentation

Here, we are said to fuse BootSecurityInfo with “0x20b” and that’s what we were doing. It has worked on all the devices we’ve found until we’ve received some devices where BootSecurityInfo is not “0x0”

image
image1122×235 55.4 KB

If I can’t use BOOT_SECURITY_INFO to set this information, as the official documentation says, how am I supposed to achieve same result without using this fuse? In the doc you’ve pointed there is no info about any alternative way to set this configuration

Thanks in advance,
jetxeberria

4 Likes
5

that’s due to recently, the fuse value for boot_security_info was burned (by manufacturing) to 0x1E0 as default value.
as mentioned above comment #3, those were “Reserved” bits.

6

Hello Jerry,

Yes, we assume that these are reserved bits.

We’ve successfully apply our expected value by reading these bits, performing a logic OR with our custom value, updating our fuses file and burning the updated value. All right.

0x1e0 = 0...0 0001 1110 0000 -> already burnt bits 
0x20b = 0...0 0010 0000 1011 -> our custom bits 
0x3eb = 0...0 0011 1110 1011 -> updated with logic OR

However, we have doubts that this is the expected approach because of the warnings shown in doc.
This is what I tried to explain in the topic opening: Writing fuses with reserved bits

How are we supposed to apply our custom value on BOOT_SECURITY_INFO fuse if we don’t read the reserved bits and make an OR based on them?

7

it looks okay to program as 0x3eb for your use-case.

8

Hello Jerry,

All right.

The problem is that we don’t know if the devices will come in future or other batches with those reserved bits as 0x0, 0x1E0, or any other value. That’s why we are unavoidably forced to read these bits and ‘make decision based on them’. Following this procedure:

  • Read the reserved fuse bits
  • Perform a logic OR with our custom value
  • Update our fuses file with the new updated value
  • Then, fuse them

That’s why we were concerned about the warning in docs telling that:

Customers are advised to not read the values of the reserved fuse bits and/or make any kind of decisions
based on them

I understand from your response that such warning doesn’t actually apply if you need to burn any fuse with reserved bits

9

hello jetxeberria,

please see-also Topic 330828. the fuse value for boot_security_info was burned by manufacturing to 0x1E0. it’s around in the beginning of 2025.
since they’re “Reserved”, for those reserved bits as 0x0 or 0x1E0 modules, you may program boot_security_info as 0x3EB directly for your real use-case.

10

Hello Jerry,

All right. Since the reserved bits may change, I understand that the procedure described here — Writing fuses with reserved bits - #8 by jetxeberria — is the best general approach for handling fuse burning when reserved bits are involved.

Thank you Jerry Chang

11

I’ve also added this to Orin Nano HW FAQ.