Problem when trying to burn ODM Reserved fuses

Hello, sorry if i keep on posting with new issues every now and then.
Hope you can help me with this one:

I have a jetson nano module emmc with PKC and production fuses burned.

For application specific needs, i’d like to burn some ODM_reserved fuses, but for some reasons i’m getting the following error

sudo ./odmfuse.sh -k keys/rsa_testkey.key -i 0x21 -c PKC -o 0x0000000000000000000000000000000000000000000000000000000000000001

*** Generating fuse configuration ... done.
done.
*** Start fusing  ... 
./tegraflash.py --chip 0x21 --applet nvtboot_recovery.bin --cmd "blowfuses odmfuse_pkc.xml;"
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
 
[   0.0018 ] Parsing fuse info as per xml file
[   0.0044 ] tegraparser --fuse_info odmfuse_pkc.xml blow_fuse_data.bin
[   0.0052 ] 
[   0.0052 ] Generating RCM messages
[   0.0075 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 0 --download rcm nvtboot_recovery.bin 0 0
[   0.0081 ] RCM 0 is saved as rcm_0.rcm
[   0.0085 ] RCM 1 is saved as rcm_1.rcm
[   0.0085 ] List of rcm files are saved in rcm_list.xml
[   0.0085 ] 
[   0.0085 ] Signing RCM messages
[   0.0104 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0110 ] Assuming zero filled SBK key
[   0.0144 ] 
[   0.0144 ] Copying signature to RCM mesages
[   0.0164 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml
[   0.0177 ] 
[   0.0177 ] Boot Rom communication
[   0.0194 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
[   0.0199 ] BR_CID: 0x<REDACTED>
[   1.1108 ] RCM version 0X13
[   1.2163 ] Boot Rom communication failed
[   1.2184 ] 
Error: Return value 3
Command tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
failed.

am i doing anything wrong?

the fuses as of now are configured as follows

 # cat reserved_odm*
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000

thanks in advance for your kind support

did you enable odm lock? you cannot burn the target even by adding keys to non-fuse fields.
the recommended way is to burn all fuses together instead of burning fuses step-by-step.

Hello, thanks for your kind reply.

No, i haven’t burned the ODM lock fuse.

I don’t understand what you mean by

“you cannot burn the target even by adding keys to non-fuse fields.”

According to the documentation odm reserved should be writable even if the board has already been set to “production mode” but ODM lock hasn’t been written yet

/sys/devices/7000f800.efuse/7000f800.efuse:efuse-burn # cat odm_lock
0x00000000

hello francescoacchiappati,

FYI,
when you begin production and burn the ODM production fuse, secure boot is enabled, JTAG debug is disabled, and all the fuses become inaccessible except Reserved_ODM.
however, Reserved_ODM fuse are programmable until it disabled by the ODM_lock fuse.

may I also know which Jetpack release you’re working with.

Hello
sure thing :)

JetPack_4.6.4 for Jetson nano targets
Linux 4 Tegra R32.7.4
secureboot_R32.7.4

According to what you just said, which is also written in the documentation, i was expecting to be able to burn ODM_reserved fuses with odmfuse.sh script even after the board was in production mode

hello francescoacchiappati,

please see-also Jetson Nano Fuse Specification Application Note for [ODM Field Programmable Fuses] section.
according to script usage, it should be -o <8-0xXXXXXXXX> to configure odm_reserved for setting 256bit Big Endian value.

I’ve noticed the help command line but i couldn’t interpret it properly, can you please provide an example on how to burn odm_reserved fuses on a board that has PKC already fused and ODM_production set?

thank you.

I think i have figured out the problem, which is related to the odmfuse.sh script or to the way the script invokes the child scripts like tegraflash.py.

Basically what happens is that odmfuse.sh doesn’t accept a parameter for loading a private key for signing rcm messages for a board that has already been set into production mode.

here is what happens when you try to burn the fuses with odmfuse.sh (from my first post)

....
[   0.0085 ] Signing RCM messages
[   0.0104 ] tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key

please note that the tegrasign is invoked with --key None

This causes the communication with the board to fail when sending RCM commands, which should be signed with my private key instead.

Here is a test blowing fuses by invoking directly tegraflash.py

$ sudo ./tegraflash.py --key ../keys/private_key.key --chip 0x21 --applet nvtboot_recovery.bin --cmd "blowfuses odmfuse_pkc.xml"

......
[   0.0089 ] tegrasign --key /home/rampage/nvidia/nvidia_sdk/JetPack_4.6.4_Linux_JETSON_NANO_TARGETS/Linux_for_Tegra/keys/private_key.key --list rcm_list.xml --pubkeyhash pub_key.key

please note that now the tegrasign command is invoked by passing the rsa2048 key file in PEM format, and it signes the rcm_list.xml file

and as a result:

[   0.0095 ] PKC key in Open SSL format
[   0.0096 ] Key size is 256 bytes
[   0.0096 ] Saving public key  in pub_key.key
[   0.0728 ] Saving public key Hash as binary: pub_key.hash
[   0.0728 ] Saving public key Hash as big-endian text: pub_key.hash_txt
[   0.0728 ] Saving public key Hash as little-endian(sysfs) text: pub_key.hash_sysfs_txt
[   0.0729 ]
[   0.0729 ] Copying signature to RCM mesages
[   0.0737 ] tegrarcm --chip 0x21 0 --updatesig rcm_list_signed.xml --pubkeyhash pub_key.key
[   0.0748 ]
[   0.0749 ] Boot Rom communication
[   0.0768 ] tegrarcm --chip 0x21 0 --rcm rcm_list_signed.xml
[   0.0773 ] BR_CID: 0x<REDACTED>
[   0.4243 ] RCM version 0X210001
[   0.5330 ] Boot Rom communication completed
[   1.5629 ]
[   1.5629 ] Blowing fuses
[   1.5707 ] tegrarcm --oem blowfuses blow_fuse_data.bin
[   1.5714 ] Applet version 00.01.0000
[   1.8360 ] Successfully burnt fuses as per fuse info blob

I’m not very good at bash scripting and therefore i don’t think i’ll be good enough for a pull request proposal for fixing the odmfuse.sh to take in account this specific scenario.

Maybe someone better then me can apply a fix to it?

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.