Burning fuses on secure board

I have a Jetson Orin NX custom board which has the SBK and PKC burned. I would like to burn additional fuses such as OEM K2. I am running:
odmfuse.sh -i 0x23 -x odmfuse.xml -k pkc.pem -S sbk.key --test jetson-orin-nx-custom
The XML file has the MagicId, ArmJtagDisable, OemK2, SecureBootKey, PublicKeyHash and BootSecurityInfo

On a new board, this works. On a board that already has the SBK and PKC burned, it fails.

The first issue is that it hangs with the message “Input applet”. I believe that this is due to the fact that odmfuse.sh along with odmfuse.func fail to specify a --applet parameter when invoking tegraflash.py in the secure case.

If I add “–applet mb1_t234_prod.bin” to the tegraflash.py invocation, I run into another error: “Error: read partition with --securedev not support yet”. Am I interpreting that correctly to mean that accessing fuses on a secure board is not possible, preventing additional fuses from being burned?

A couple of notes:

  1. I am using Jetson 35.3.1, but see the same “not support yet” message in tegraflash_burnfuses in 36.2.0.
  2. I see that the notes on odmfuse.sh indicate that you have to be cautious to burn the fuses considering dependencies. However, I don’t see where it defines which fuses are dependent on which and it doesn’t seem like there should be a dependency on OemK2 and the other fuses.

Thanks,
Steve

hello steve.schefter,

did you enable SecurityMode fuse? FYI, once SecurityMode has burned, there is no way back. (even by adding keys to non-fuse fields)
please check fuse variable via odmfuseread script, or, please boot-up the target to check fuse variables, (/sys/devices/platform/tegra-fuse).

Hi Jerry.

I’ve not used the -p option with odmfuse.sh to set SecurityMode.

odmruseread -i 0x23 -k pkc.pem -S sbk.key jetson-orin-nx-custom-ai
fails in the same way as odmfuse.sh:
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

    Input applet:

That’s because, for secure boards, it too is invoking tegraflash.py without a --applet parameter.

Via Linux, in /sys/devices/platform/tegra-fuse, which entry did you have in mind? boot_security_info is 0x00000000.

Steve

hello steve.schefter,

please double check you’re using correct PKC,SBK keys for reading fuse variables.
and… please share the complete logs of odmruseread for quick checking.

Hi Jerry.

Yeah, I’m using the same keys as I do to generate images, and they run fine.

I’ve attached the output from running:
odmfuseread.sh -i 0x23 -k pkc.pem -S sbk.key jetson-orin-nx-custom

Note that it ends with it asking for the input applet. That’s because the final invocation of tegraflash.py by odmfuseread.sh doesn’t include a --applet option. As I mentioned above, I experienced the same thing with odmfuse.sh. The command line args passed to tegraflash.py are built up according to the auth variable in odmfuse.func/odmfuse.sh, and in the SBKPKC case it’s not including --applet. It’s figuring that auth is SBKPKC on it’s own by looking at the board.

Steve

readout.txt (101.8 KB)

One additional detail in case it’s relevant: The custom board is using the P3637 Orin NX SoM.

hello steve.schefter,

there’s a bug with r35.3.1 release version.
as you can see in odmfuse.func, which was taking 0x19 approach for SBKPKC fused 0x23 targets.

so…
please try again with the latest rel-35 version, (i.e. jetson-linux-r3550) for confirmation.

Thanks Jerry. I will see if the customer wants to update or just live with not being able to work with boards that already have SBK and PKC set.