Orin fuse writing error

Robotics & Edge Computing Jetson Systems Jetson AGX Orin
1

I was trying to fuse these secure boot keys into an Orin:

fuse.txt (577 Bytes)

But I got an error stating I was trying to set 1 bits to 0, after which i found that this batch of Orins has 0x1e0 written in BootSecurityInfo by the factory. After finding out about this I read the fuses out and saw that PublicKeyHash had been fused successfully but nothing else visible had changed:

PublicKeyHash: 76462886846f2e3851f066f2524a41d2bfa58e262cce2432b6a5d4cfcdd0e9ab71dc97e3347b4f4d38dd3ec5528e28e6003429c6dcfc421235b4b62deb334a48
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

After this I modified the fuse.xml to have the BootSecurityInfo ORed with 0x1e0 and tried writing fuses again, which gave this error over the UART interface from which I assumed that the SecureBootKey had also been successfully written earlier:

I> 1. Start PublicKeyHash burn
I> Fuse is already burned with the same value
I> 1. PublicKeyHash burn skipped
I>
I> 2. 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

I also tried modifying the fuse.xml to only include the OemK1 field which gave a similar error from which I assumed that key had also been written successfully earlier. Next I modified the fuse.xml to have only the BootSecurityInfo and SecurityMode fields since I thought all fields before BootSecurityInfo had been fused successfully. After doing this I am not able to read read the fuses anymore, it seems that the orin does not accept the rsa.pem and sbk.key that should have corresponded to these fuses.

My questions are:

  1. Is there any way to still flash this Orin?
  2. I have another Orin from this batch on which I have just done the first failed fuse write, how should I proceed on that Orin?
  3. I have more fresh Orins from this batch, can I assume that if I set the BootSecurityInfo to the correct value from the start I will not see any problems or is there anything else I should change?

Notes:
I have flashed many Orins previously successfully with the same process so I think my keys are generated correctly and the overall process has worked for all Orins from earlier batches. For writing fuses I use the command
sudo ./odmfuse.sh -i 0x23 -X fuse.xml jetson-agx-orin-devkit
and for reading fuses I use
sudo ./odmfuseread.sh -i 0x23 -k rsa.pem -S sbk.key jetson-agx-orin-devkit

2

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

Based on the provided context, it appears that you are experiencing issues with fusing secure boot keys into an Orin fusetxt. You have encountered an error stating that you are trying to set 1 bits to 0, which is likely due to the BootSecurityInfo field being set to 0x1e0 by the factory.

To address your questions:

  1. Is there any way to still flash this Orin?

It seems that you have already attempted to modify the fusexml to include only the BootSecurityInfo and SecurityMode fields, but this has resulted in the Orin not accepting the rsapem and sbkkey. Unfortunately, it is unlikely that you will be able to flash this Orin successfully, as the BootSecurityInfo field has already been set to 0x1e0, which may have caused irreversible changes to the fuse configuration.

  1. How should I proceed on the other Orin from this batch that has only had the first failed fuse write?

For the other Orin from this batch, you should modify the fusexml to include the correct BootSecurityInfo value (0x1e0) from the start. This may prevent the same issue from occurring. However, it is essential to note that the BootSecurityInfo field is only 2 bytes long, and only the last two bytes are programmable. Therefore, you should ensure that the correct value is set for the BootSecurityInfo field.

  1. Can I assume that if I set the BootSecurityInfo to the correct value from the start, I will not see any problems or is there anything else I should change?

While setting the correct BootSecurityInfo value from the start may prevent the issue you encountered, it is crucial to note that other factors may still affect the fuse configuration. For example, the PublicKeyHash, SecureBootKey, and OemK1 fields may still need to be fused correctly.

To minimize potential issues, you should:

  • Verify that the BootSecurityInfo field is set to the correct value (0x1e0) from the start.
  • Ensure that the PublicKeyHash, SecureBootKey, and OemK1 fields are fused correctly.
  • Use the same process that has worked for earlier batches of Orins.
  • Double-check the fusexml configuration to ensure that it is correct and consistent with the Orin’s fuse configuration.

In summary, while setting the correct BootSecurityInfo value from the start may help prevent issues, it is essential to be cautious and verify that all other fuse fields are configured correctly to ensure a successful fuse configuration.

Comparison with other Orin batches:

It appears that the issue you encountered is specific to this batch of Orins, as you have successfully flashed many Orins from earlier batches using the same process. This suggests that the BootSecurityInfo field may have been set differently in this batch, which has caused the issue.

To avoid similar issues in the future, it is recommended to verify the BootSecurityInfo field value for each batch of Orins and adjust the fusexml configuration accordingly. Additionally, it is essential to ensure that the fuse configuration is consistent across all Orins in a batch to prevent potential issues.

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

4

hello joosepn,

please refer to Jetson Orin Series Modules Fuse Update Field Services Bulletin for the details of FUSE_BOOT_SECURITY_INFO_0 changing to 0x1e0.

let me have confirmation, what’s your 1st fuse process, did you attempt to burn PKC+SBK keys?
is the attached fuse.txt is the xml file you’re trying to burn fuse at the first place?

Q&As.
>> Q1)
it should be, but let me have confirmation and trying to resolve it.
>> Q2)
>> Q3)
please check [Jetson Orin Series Modules Fuse Update Field Services Bulletin].
you must do bitwise logically OR your desired value with 0x1E0 in the fuse programming flow.

5

Hi, that is correct, I initially tried to burn PKC+SBK keys using the attached fuse.txt. After finding the bulletin I replaced the BootSecurityInfo in the xml file with 0x3e9 which is (0x209 | 0x1e0).

6

hello joosepn,

thanks for confirmation.
according to the fuse info you shared in the description. your board should be have PKC keys fused, however, fuse burning has aborted due to there’s mismatch of BootSecurityInfo,
i.e. 0x209 in the xml file, but 0x1e0 on the target.

FYI,
it’s BootSecurityInfo’s bit [3:0] to indicate the target’s secureboot authentication scheme.
please try to burn only BootSecurityInfo, assume it’s PKC key with 3072-bit RSA. (i.e. 001b for BootSecurityInfo)
let’s try below to burn your target with following,
$ sudo ./odmfuse.sh -X <fuse_config> -i 0x23 -k <pkc.pem> <target_config>

<genericfuse MagicId="0x45535546" version="1.0.0">
    <fuse name="BootSecurityInfo" size="4" value="0x1e1"/>
</genericfuse>
7

So I burned 0x1e1 to BootSecurityInfo and now when I try to read the fuses without giving any keys it says “Error: PKC key file is not provided for PKC protected target board.” and when i gave it the rsa.pem I was able to successfully read the keys again. So it seems this key was accepted successfully, what should I attempt next?

8

hello joosepn,

according to your test results. this target has fused only PKC key, actually.
to be more specific, let’s back-to your 1st fuse process, it’s only PKC key within fuse.txt has programmed.

you may have additional fuses burn onto this module.
see-also developer guide, Burn Fuses with the Fuse Configuration file.
note, it’s basically the same approach as mentioned earlier to add fuses.

9

So if it now has only PKC key fused, is it possible to add an SBK key? I tried modifying the fuse.xml to only include the SBK key:

but running sudo ./odmfuse.sh -i 0x23 -k rsa.pem -X fuse_alt.xml jetson-agx-orin-devkit to fuse it gives these errors over the UART interface:

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

10

hello joosepn,

please share fuse_alt.xml and also the complete flashing logs for reference.
note, you should also toggle bit-3 of BootSecurityInfo to have SBK authentication scheme.

11

Sorry, I thought I added the fuse_alt.xml but it seems it got lost, here it is:


But now I toggled the third bit of BootSecurityInfo by writing the following xml to the fuses:



And after that when trying to read fuses I see the board is SBK+PKC protected but when I give both of the keys odmfuseread.sh fails with the attached error logs, which seems to mean that the SBK key is not accepted

log_invalid_fuse_read.txt (18.8 KB)

12

It seems adding xml as text in the posts makes it be interperted as html tags? I attached both the xmls as files now.

fuse_alt2.txt (123 Bytes)

fuse_alt.txt (181 Bytes)

13

There is no update from you for a period, assuming this is not an issue anymore.
Hence, we are closing this topic. If need further support, please open a new one.
Thanks ~0325

hello joosepn,

umm.. why there’re two xml files.
may I know what’s your fuse process for running with fuse_alt.xml and fuse_alt2.xml?