Jetpack version 35.6.0
Module: Orin NX 16GB
We have a product that currently uses Xavier NX as the compute board, and are in the process of releasing a new product line with Orin NX.
Now, as part of provisioning and deployment, we have a requirement in our factory process to fuse our Jetson modules with runtime scripts on-board (using the sysfs kernel interface for fusing) instead of using the USB fuse method with odmfuse.sh. This process was incorporated since Xavier and we would like to keep it for deploying our new product line with Orin NX. It appears that the /sysfs interface for Tegra 234 does not have some critical fuses in the driver - namely odm_production_mode and secure_boot_key.
My question is:
Is there a reason they were not added? Are these fuses not writable at runtime?
If we can fuse them, then how do I derive the values for FUSE_BURN_DATA? I don’t quite understand how to derive m_off, sbit and c_off values. Is there documentation on the register mapping for these fuse addresses?
ex:
FUSE_BURN_DATA(boot_security_info, 0xc7, 0, 32, 0x168, false, false),
Looking at the “Jetson Orin Fuse Specification”, i can only make sense of the size (32 bits), but not sure how to get the other values.
On a side note:
Jetpack 36 onwards, fuse-burn support from Linux has been dropped, but are we still able to back port this interface to allow fusing on-board? Or there are other things to consider and this simply wont work going forward? We really prefer a runtime method of fusing as changing our factory processes is a big hurdle.
hello vipul.vishnoi,
please see-also Topic 329077 Burning ReservedODM fuses in Linux,
re-cap as below..
in JP-6, we’ve deprecate and remove the fuse-burn driver, you cannot burn fuse from Linux kernel.
Hi Jerry,
Thank you for the response. My question is more for JP5. In the past, support was added for Tegra194 for KEK fuses How to read KEK0/1/2 Fuse values on Jetson AGX Xavier - #3 by DaneLLL. Can Nvidia provide support for the two fuses i mentioned above in this ticket for Orin NX? or share any documentation on how to derive those register/address values so i can patch the kernel driver for our application
hello vipul.vishnoi,
let’s check sysnodes, you should have below efuse-burn node, right?
for instance, /sys/devices/platform/efuse-burn
if yes, may I know which fuse variable you’re going to program at kernel layer.
and, what’s your board’s current authentication status.
Hi Jerry,
Our current board status NS (or not fused).
Yes i do have sysfs nodes for fuses
ls /sys/devices/platform/efuse-burn
boot_security_info of_node reserved_odm3
debug_authentication opt_customer_optin_fuse reserved_odm4
driver opt_tpc_disable reserved_odm5
driver_override pdi reserved_odm6
ecid power reserved_odm7
modalias public_key subsystem
odm_info reserved_odm0 uevent
odm_lock reserved_odm1 wakeup
odmid reserved_odm2
We want to be able to program odm_production_mode and secure_boot_key
Here is our current xml file with a list of fuses:
<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="SecureBootKey" size="32" value="<our sbk>" />
<fuse name="PublicKeyHash" size="64" value="<our pkc hash>" />
<fuse name="BootSecurityInfo" size="4" value="0x209" />
<fuse name="SecurityMode" size="4" value="0x1" />
</genericfuse>
hello vipul.vishnoi,
you should connect the device via USB port to program those two.
after the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.
also, SBK for encryption, if SBK is burned, then the SBKFILE users provide is for encrypting the images.
in short.
you should program reserved fuses at kernel layer only.