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
version 1.0.0
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.
to burning Xavier series, please program all the fuse, and odm production modes at once.
please also refer to Topic 123506 and Topic 176834 as see-also. thanks
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.
Q3>
the 3072-bit RSA key option is supported only on Jetson Xavier series.
Q4>
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
Aha! So the --auth NS is the current state of the board (unfused target). And as you said, this is only needed in ‘off-line’ mode because no communication is happening with the board.
I was also not realizing that the -c option is not needed in ‘on-line’ mode because the actual state of the fuses is being read. I thought this was needed to set the mode (from NS to PKC or SBKPKC).
@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:
And sudo bash ./flashcmd.txt did successfully flash the board (after the fuses had been burned with sudo ./flashcmd.sh).
It seems to me that the commands should be either providing better warnings or throwing errors. This was a very confusing and nerve wracking experience. It should not be.
I will also note that when I tried to perform the same operations with 32.6.1 I came across the error in orrupted-kernel-headers-package-in-l4t-32-6-1. This is on a bare-metal Ubuntu 18.04 host.