Fusing BootSecurityInfo & SecurityMode fails on Orin AGX

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

We are running into a problem when burning the fuses on some of our Orins.

We fuse the Orin in 3 stages, manually resetting it each time to place it in recovery mode.

  • Stage 1: we burn the ODM[0..3] fuses
  • Stage 2: we burn the secure boot keys using FSKP
  • Stage 3: we burn BootSecurityInfo to 0x209 and SecurityMode to 1 to enable secure boot.
<genericfuse MagicId="0x45535546" version="2.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x00000209"/>
    <fuse name="SecurityMode" size="4" value="0x00000001"/>
</genericfuse>

Stage 1 & 2 seem to work OK as we can readback the fuses and confirm they are burnt but stage 3 does not change the fuses from their default value, although the script does not return any error.

I noticed the following in the log, which looks a bit worrying.

(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 1: syntax error
(standard_in) 1: syntax error
MagicId=0x45535546 version=0x2
node: name=BootSecurityInfo size=4
type 0x0 size 4 
  value=0x00000209
node: name=SecurityMode size=4
type 0x1d size 4 
  value=0x00000001
done.
size of FSKP binary 386320
size of Fuse Blob 100
File saved as fskp_t234_updated.bin
done.

Any idea what these errors are and if they are a concern?

I am also confused as to why FSKP is involved at this stage, since we are not making use of it… Could you shine some light?

In addition, I noticed the following line in https://developer.download.nvidia.com/assets/embedded/secure/jetson/agx_orin/Jetson-Orin-Fuse-Specification_DA-10877-001v1.5.pdf:

The programming of fuses should be done without a system reset between different phases.

We have split the process in the 3 stages above and manually reset the Orin into recovery mode each time.
I was wondering if this could cause problem and if we need to burn all fuses in one go?
If so, how to do this with FSKP?

Finally, and maybe most suspicious, on the unit that is failing to burn I noticed that the default value of BootSecurityInfo : was 000001e0 whereas on the other units we have successfully burnt it was 00000000 .
I know those bits are reserved and not guaranteed to be 0, but this is a difference on the very fuse we are trying to burn.
Is that potentially linked to our problem since we are trying to burn this fuse tos 0x209, so reset those fuses to 0, which is impossible.

Note that I obfuscated the fuse values in the log file attached.

manual_odmfuse.txt (94.5 KB)

2

*** Please note that this reply is generated by LLM automatically ***

The issue you’re encountering with burning fuses on the Jetson AGX Orin in a multi-stage process involves several aspects that need clarification and potentially correction. Let’s break down the key points and address them step by step:

  1. Multi-stage Fuse Burning Process: You’re currently burning fuses in three stages, manually resetting the device into recovery mode between each stage. This process involves:

    • Stage 1: Burning the ODM03 fuses.
    • Stage 2: Burning the secure boot keys using FSKP (Fuse Security Key Provisioning).
    • Stage 3: Burning BootSecurityInfo to 0x209 and SecurityMode to 1 to enable secure boot.

  2. Errors and Concerns: You’ve noticed errors in the log that seem concerning, and you’re unsure about their implications. Additionally, you’re puzzled about why FSKP is involved in this stage since you’re not utilizing it for its primary purpose (secure boot key provisioning).

  3. Fuse Burning Without System Reset: The Jetson Orin Fuse Specification document (DA10877001-v1.5) advises that fuse programming should be done without a system reset between different phases. Your current process involves manual resets between stages, which might be problematic.

  4. Default Fuse Values: You’ve observed a difference in the default value of a specific fuse between units that successfully burned fuses and the one that failed. The failing unit has a default value that is not zero for bits that are reserved and not guaranteed to be zero. This discrepancy is particularly noteworthy since you’re trying to burn this fuse to a value that resets those bits to zero, which could be impossible if the hardware doesn’t support it.

Addressing the Concerns:

  • FSKP Involvement: FSKP is typically used for provisioning secure boot keys. If you’re not using it for secure boot key provisioning, its involvement in the process might be unnecessary or even problematic. Review the documentation and your process to ensure FSKP is being used as intended or if it can be safely omitted.

  • Multi-stage Process: Given the recommendation to burn fuses without a system reset between phases, consider modifying your process to burn all necessary fuses in a single session. This might require adjusting your scripts or the order in which fuses are burned to ensure compatibility and to avoid errors.

  • Default Fuse Values: The discrepancy in default fuse values between units could be significant, especially if the bits in question are not just reserved but also read-only or have specific requirements for being set to zero. Investigate the specific fuse and its properties to understand if this discrepancy is the root cause of your issue. It might be necessary to contact NVIDIA support for further clarification on these reserved bits and their behavior.

  • Log Errors: Without specific details on the errors you’re seeing, it’s challenging to provide a precise solution. However, errors during the fuse burning process can often indicate issues with the fuse values being written, the process itself, or even hardware problems. Ensure that your process and the values you’re attempting to write are correct and supported by the hardware.

Recommendations:

  1. Review Documentation: Carefully review the Jetson Orin Fuse Specification and any relevant documentation to ensure your process aligns with NVIDIA’s recommendations.

  2. Simplify the Process: Attempt to burn all fuses in a single session without manual resets to see if this resolves the issue.

  3. Investigate FSKP Usage: Determine if FSKP is necessary for your specific use case and adjust your process accordingly.

  4. Contact Support: If issues persist, especially regarding the default fuse values and their implications, consider reaching out to NVIDIA’s support for more detailed guidance tailored to your specific situation.

By addressing these points and potentially simplifying your fuse burning process, you should be able to resolve the issues you’re encountering with burning fuses on the Jetson AGX Orin.

*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***

3

This automatic reply is not helpful; could a human please look into my query and respond please?

We have very carefully read the documentation. We cannot just try another way and see what happens. We are burning fuses in a controlled production environment and need to understand the root cause of the issue and resolve it.

5

hello jeanphilippe.arnaud,

according to Jetson AGX Orin HW FAQ,
let me re-cap as below..

Q35: FUSE_BOOT_SECURITY_INFO_0 have a pre-fused Boot Security Info value of 0x000001e0.

BOOT_SECURITY_INFO was burned (by manufacturing) to 0x1E0 as default value.
please update with logic OR, for example, an OR of BOOT_SECURITY_INFO + 0x1E0 from now on.
here’re related topics for reference. Topic 330828, Topic 335952.

6

Hi Jerry,
Many thanks for your speedy answer, excellent, as usual!
Do I understand correctly that the process silently fails because we are attempting to reset the reserved fused that came already set from Nvidia?
As a result, do we need to readback the BootSecurityInfo fuse prior to fusing and OR what we want to fuse with it to avoid this issue?
I am asking you to confirm as this goes against the doc that states we should not readback this fuse to make any assumptions based on the value of those reserved bits.
Many thanks,
JP

7

hello jeanphilippe.arnaud,

although there’s error log reported from serial console with mismatch BootSecurityInfo
for instance,

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

the fusing process silently fails on the host side. that should be why the script does not return any error.

as mentioned by Jetson Orin Fuse Specification v1.5.
let me re-cap as below.

FUSE_BOOT_SECURITY_INFO_0

  • Bits [8:4] Reserved (may not be logic 0 by default)

please give it a try for updating content of fuse-config.xml,
you should revise BootSecurityInfo value by doing an OR with 0x1E0 to fuse correctly.
besides, let’s ignore SecurityMode, because once the SecurityMode (also known as odm_production_mode) fuse is burned with a value of 0x1, all additional fuse write requests will be blocked.

<genericfuse MagicId="0x45535546" version="2.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x000003e9"/>
</genericfuse>