I did the following steps and get an error when I tried to re-flash a fused Orin NX. The error code is 3. Could you please help to provide more information about the error code, and what could be the cause? Many thanks.
(1) I downloaded the Nvidia BSP 36.4.3 and signed the image using the following command.
(3)then I fused the Orin NX with the following fuse contents. I tested the fuse process and finally burned the fuse bits successfully to enable secure boot.
(4) Then it seems the system is not booting because I cannot see any output from serial.
(5) I tried to reflash the Orin NX, then I got the following error.
xxxx@xxxxxx-2:~/Linux_for_Tegra/bootloader$ sudo bash ./flashcmd.txt
Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands
please put the device enter forced recovery mode, and let’s read the fuse through flash script.
for instance, $ sudo ./flash.sh --read-info -u <pkc> -v <sbk> <target_conf> <rootdev>
and… please check Jetson Orin Fuse Specification, especially the FUSE_BOOT_SECURITY_INFO_0
I build and sign the image on AWS EC2. Because EC2 cannot detect any Orin NX attached, I comment out fill_devpaths in l4t_initrd_flash.sh, when I run the build script. However, the flashing operation is done locally on a Ubuntu machine with one Orin NX in the recovery mode. When I do flashing, I added the fill_devpaths back in l4t_initrd_flash.sh
Therefore, is that possible when I build and sign the image on EC2, it does not sign the RCM messages? Therefore the flashing failed?
I did build, sign, and flash by using one command on a local machine with one Orin NX attached several times already, all worked. However, the image I build on AWS cannot be flashed.
please refer to $OUT/Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt for [Workflow 8: Secure initrd Massflash].
it shows the steps to create massflash package.
Hi @JerryChang it seems it works now when I use openssl keys to sign the BSP images. However, I still have the same problems when I sign the images using AWS CloudHSM keys.
Could you please share some advices what would be the common or previous mistakes you saw when using AWS CloudHSM to do the signing? I would greatly appreciate any advice.
Are there specific ways that I can verify the signatures of the images on my local machine? The reason I am asking this is that, it seems the error is caused by invalid signatures. The host is sending some packages with signatures to Orin NX when this error happens. How can I find the corresponding signature files and raw data, so that I can verify the signatures on my local machine? For example, how can I verify if the signature of mb1_t234_prod_aligned_sigheader.bin.signed is correct?
In short, what is the way that I can use to verify the signing results on my local machine?
[ 0.0126 ] mb1_t234_prod_aligned_sigheader.bin.signed filename is from --mb1_bin
[ 0.0126 ] psc_bl1_t234_prod_aligned_sigheader.bin.signed filename is from --psc_bl1_bin
[ 0.0126 ] rcm boot with presigned binaries
[ 0.0131 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader.bct.signed
[ 0.0134 ] BR_CID: 0xC1012344705DF10F3000000004000140
[ 0.2642 ] Sending bct_br
[ 0.3611 ] Sending mb1
[ 0.3619 ] ERROR: might be timeout in USB write.
Hi @JerryChang thank you for all your help. I already figured out the root cause, now I can boot a BSP-36.4 image signed by a RSA 3K key in cloudhsm.
Two quick comments on the BSP code:
(1) the l4t_initrd_flash.sh calls fill_devpaths in the offline mass flash mode, which should be a bug in the BSP.
(2) When signing using Tegraopenssl, the python or bash script does not check if the Tegraopenssl signing returns error or not. In my case, it still generated the final image though the signing failed.