So we dropped the --test and burned the fuses. Again no errors.
After this the board would never come out of Boot ROM. When trying to flash, we see the following (a sure sign the board is in an unrecoverable state):
Welcome to Tegra Flash
Type ? or help for help and q or quit to exit
Use ! to execute system commands
[ 0.0147 ] Parsing partition layout
[ 0.0165 ] tegraparser_v2 --pt secureflash.xml.tmp
[ 0.0194 ]
[ 0.0195 ] Boot Rom communication
[ 0.0211 ] tegrarcm_v2 --chip 0x19 0 --rcm rcm_1_signed.rcm --rcm rcm_2_signed.rcm
[ 0.0227 ] BR_CID: 0xd8021911645995822400000015028280
[ 0.0242 ] Bootrom returned error 22
[ 0.0252 ] Boot Rom communication failed
[ 0.0252 ]
Error: Return value 22
What could be the cause of the board failing to come out of Boot ROM? What is wrong with the scripts we used to generate the keys, test the keys, and ultimately burn the fuses? We do not want to “brick” another expensive (and in fact no longer available to purchase without long lead times) board.
I have updated to 32.7.1, but I still have a couple of concerns:
tegrasign_v3.py has #!/usr/bin/env python but this is not valid in a default Ubuntu 18.04 installation. Was this intended to be #!/usr/bin/env python3?
Why is the odmfuse_pkc.xml from the --noburn mode different than the --test mode? The fuseblob.tbz2 version seems to be missing several fields. Attached are the two output logs (the command run is at the top of each log). gen-factory.log (76.9 KB) test.log (82.7 KB)
this command-line is running at offline mode, in the offline mode, the --auth options is used to indicate the board fuse status, because there is no boards connected, so odmfuse.sh doesn’t have a chance to know the board’s fuse status.
in this scenario… since the target has burned with PKC+SBK, -k is used to sign the encrypted images; -S is the command to encrypt the images. in the end, there only --KEK2 and KEK256 will be burned to the board, then it appears in the odmfuse_pkc.xml.
since there is neither board info nor --noburn in the command, odmfuse.sh will run in the online mode, which means a board must be connected; -c options is no needed in the online mode since odmfuse.sh is now able to get the board’s fuse status from the target. besides, the option -c is obsolete now. it’s replace by --auth options.
I assume you’re test this pipeline with unfused target, right? you should assign --auth NS options to the command-line due to neither PKC nor SBK is burned.
following above, for these options in the command-line, all fuse info will be burn to the target, such as… -p, -k, -S, -KEK2, -KEK256. so, that’s why odmfuse_pkc.xml include all those fuse information.
the 3072-bit RSA key option is supported only on Jetson Xavier series.
please use the multi-steps approaches to burn the fuse and flash the target.
for example, (1) using odmfuse.sh to create the fuse blob, (2) review all the fuse info and messages, running fusecmd.sh to burn the fuse to the device actually, (3) it’s flash.sh script to create the image blob, and (4) run flashcmd.txt to flash the target. please see-also this thread for reference, Jetson Xavier NX DEVKIT secureboot enabled - #7 by JerryChang
@JerryChang NOTE: neither sudo ./flash.sh –-no-flash --sign -u rsa_pub.pem -v sbk_hex_file jetson-agx-xavier-devkit mmcblk0p1 nor sudo ./flash.sh –-no-flash --sign -u rsa_priv.pem -v sbk_hex_file jetson-agx-xavier-devkit mmcblk0p1 works. Both tell me that the RSA or SBK key has not been provided. The rsa is 3k (3072) if that matters.
However, sudo ./flash.sh --no-flash -u ../rsa_priv.pem -v ../sbk_hex_file jetson-agx-xavier-devkit mmcblk0p1 does successfully generate the flashcmd.txt: