Hello i am trying to flash an Orin Nano that already has its PKC and SBK fuses burned and therefore secure boot activated. Below is the command:
Environment:
- Host: Ubuntu 20.04
- Jetpack 6.2
- Connected via USB-C
sudo ./tools/kernel_flash/l4t_initrd_flash.sh -u keys/rsa_priv.pem -v keys/sbk.key --external-device mmcblk0p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
but it fails, below is the log (initrd.log)
initrd.log (215.6 KB)
I tried passing the variables to the command. I read this variables with flash.sh --read-info -u pkc.key -v sbk.key:
sudo BOARDID=3767 BOARDSKU=0005 FAB=300 BOARD_REV="N.2" CHIP_SKU="00:00:00:D5" ./tools/kernel_flash/l4t_initrd_flash.sh -u keys/rsa_priv.pem -v keys/sbk.key --external-device mmcblk0p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
but fails to finish flash process succesfully and asks to run another command (initrd2.log):
initrd2.log (424.7 KB)
here is the message after running the flashcmd script
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
Entering RCM boot
[ 0.0337 ] mb1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --mb1_bin
[ 0.0337 ] psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --psc_bl1_bin
[ 0.0337 ] rcm boot with presigned binaries
[ 0.0357 ] tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct.signed
[ 0.0366 ] BR_CID: 0x89012344705DE5196C000000100102C0
[ 0.2443 ] Sending bct_br
[ 0.4656 ] Sending mb1
[ 0.4676 ] ERROR: might be timeout in USB write.
Error: Return value 3
Command tegrarcm_v2 --new_session --chip 0x23 0 --uid --download bct_br br_bct_BR.bct --download mb1 mb1_t234_prod_aligned_sigheader_encrypt.bin.signed --download psc_bl1 psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed --download bct_mb1 mb1_bct_MB1_sigheader_encrypt.bct.signed
I wanted to ask for some help on this topic to be able to flash using command line.
It is worth mentioning that flashing with the GUI (SDKManager) works just fine. The device boots up correctly. That raises a question. How is that possible if the GUI does not have access to the private key to sign the boot codes?
hello cristian.hidalgo,
however, flashing through SDKManager it did not provide any keys.
it doubts how you fuse a target, may I have your steps and fusing logs for reference.
yes, for sure. I followed the steps on the FSKP guide.
I created an RSA 3k key for PKC fuse and a 32 byte sbk key for SBK fuse. Below is the configuration file:
<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64" value="0x99a6b7d25ffd5d7cc49bf2612d01d7fe58b5121f9c473748728232bc114c25ae2415d56666157c79fc9bf0e3b4445344ff8af51a64f334289912cdff7414fa00"/>
<fuse name="SecureBootKey" size="32" value="0x8acf54e1c1372a143fd79873d16111174f8d7450c2e93597d6e019c0d3a3952f"/>
<fuse name="BootSecurityInfo" size="4" value="0x9"/>
</genericfuse>
and then to burn the fuses you can take a look at the following logs:
- delete1.log: command to generate real fuse blob and its output
- delete2.log: command to actually burn fuses and its output
- delete3.log: UART output from the board
delete.log (57.1 KB)
delete2.log (1.0 KB)
delete3.log (175.6 KB)
Let me know if you need anything else
hello cristian.hidalgo,
please execute below on your target to parse the fuse info
for instance. $ sudo /usr/sbin/nv_fuse_read.sh
Hello @JerryChang
below, is the output:
nvidia@tegra-ubuntu:~$ sudo /usr/sbin/nv_fuse_read.sh
[sudo] password for nvidia:
odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0x99a6b7d25ffd5d7cc49bf2612d01d7fe58b5121f9c473748728232bc114c25ae2415d56666157c79fc9bf0e3b4445344ff8af51a64f334289912cdff7414fa00
boot_security_info: 0x00000009
odmid: 0x0000000000000000
pk_h1: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
pk_h2: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
security_mode: 0x00000000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
ecid: 0x8472633b5f40040b
hello cristian.hidalgo,
FYI,
please refer to Jetson Orin Fuse Specification.
Bits [8:4] Not available and may not be logic 0 by default
recently, in T234 chips fuse v70, the fuse value for boot_security_info was burned (by manufacturing) to 0x1E0.
you should update the content of fuse-config.xml “BootSecurityInfo” value to set 0x1E9 for your use-case.
Hello, @JerryChang
Thanks for the help so far.
The response raises a couple of questions:
-
Why is it exactly 1E9? Shouldn’t all the bits be different than 0? in which case it would be 1F9.
-
Also it is mentioned that the boot_security_info fuse was burned to 1E0 by manufacturing recently, why does it comes as 0x00000009 when reading it? and how recent was this done? does it apply for all Jetson Orin Nano platforms?
those Bits [8:4] has some default values, boot_security_info was burned (by manufacturing) to 0x1E0 .
Hello @JerryChang
Tried to burn boot_security_info to 1E9 instead of just 9 but did not work.
here is the the fuse config file:
<genericfuse MagicId="0x45535546" version="1.0.0">
<fuse name="PublicKeyHash" size="64" value="0x99a6b7d25ffd5d7cc49bf2612d01d7fe58b5121f9c473748728232bc114c25ae2415d56666157c79fc9bf0e3b4445344ff8af51a64f334289912cdff7414fa00"/>
<fuse name="SecureBootKey" size="32" value="0x8acf54e1c1372a143fd79873d16111174f8d7450c2e93597d6e019c0d3a3952f"/>
<fuse name="BootSecurityInfo" size="4" value="0x1E9"/>
</genericfuse>
In the following logs are the commands used with their outputs:
log1E92.log (57.1 KB)
log1E91.log (1006 Bytes)
After running these commands and resetting the board, i still read the following fuse values:
sudo /usr/sbin/nv_fuse_read.sh
[sudo] password for nvidia:
odm_lock: 0x00000000
revoke_pk_h0: 0x00000000
revoke_pk_h1: 0x00000000
optin_enable: 0x00000000
public_key_hash: 0x99a6b7d25ffd5d7cc49bf2612d01d7fe58b5121f9c473748728232bc114c25ae2415d56666157c79fc9bf0e3b4445344ff8af51a64f334289912cdff7414fa00
boot_security_info: 0x00000009
odmid: 0x0000000000000000
pk_h1: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
pk_h2: 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
security_mode: 0x00000000
reserved_odm2: 0x00000000
reserved_odm3: 0x00000000
reserved_odm0: 0x00000000
reserved_odm1: 0x00000000
reserved_odm6: 0x00000000
reserved_odm7: 0x00000000
reserved_odm4: 0x00000000
reserved_odm5: 0x00000000
odminfo: 0x00000000
system_fw_field_ratchet1: 0x00000000
system_fw_field_ratchet0: 0x00000000
system_fw_field_ratchet3: 0x00000000
system_fw_field_ratchet2: 0x00000000
ecid: 0x8472633b5f40040b
Also the board is being flashed with unsigned images and is still booting.
hello cristian.hidalgo,
I doubt it’s due to you tested on the same working directory.
could you please download another new JP-6.2 public release, build from scratch, re-flash this target for confirmation.
besides, please also setup serial console to collect complete UART logs.
Hello, @JerryChang
Here is the log for the UART output when trying to burn the fuses with the new value of boot_security_info. It seems like it identifies that the pkc value is the same but fails when burning sbk, and does not even get to try to burn boot_security_info.
sudo ./fskp_fuseburn.py --board-spec orinnano-board-spec.txt -P ./out -b -c 0x23 -B ~/work/devdir/security-features-RnD/nvidia-jetson4/Linux_for_Tegra/jetson-orin-nano-devkit.conf
log1.log (41.9 KB)
In regards to the board accepting an unsigned image, this was tested from SDKManager creating a completely new directory and the flash was succesful. Also from command line, a new directory was created and the flash finished successfully. Below is the flash log from the host and the UART output (flashnew.log):
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk0p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal
flash_1-1.2_0_20250419-125931.log (48.3 KB)
flashnew.log (311.6 KB)
hello cristian.hidalgo,
since you’ve fused the target with PublicKeyHash, you should run flash command-line with keys, a signed image is required to boot.
is the host machine has multiple Jetson boards connected?
in other words, when you tried to flash the board using an unsigned image, you’re flashed a different board.
hello @JerryChang
No, I did not have a second jetson board connected to the host. I connected just the one we are testing on. But it is accepting unsigned boot codes. Or in more precised words the flash process is finishing successfully as shown in the previous log. It is doing so even when not passing any keys in the command.
Could there be another reason for this happening?
Does the FUSE_SECURITY_MODE_0 has to be burned?
Also is there a reason for the BootSecurityInfo fuse not changing its value?
hello cristian.hidalgo,
FYI, ubuntu 20.04 host is by default set the USB autosuspend enabled.
this may lead to Jetson recovery mode gets suspended before flash.
hence, please try below to bypass this communication error,
$ sudo -s
$ echo -1 > /sys/module/usbcore/parameters/autosuspend
you should plug-out the USB cable, put Jetson back into recovery mode again, and plug-in the USB cable back. let’s check whether it resolve USB timeout errors.
Hi @JerryChang
Thanks a lot for the help so far, this have taken a while.
That could be helpful with the flashing process. But the main issue is that the board is accepting unsigned images. Did you find any possible cause for this issue?
Hi @JerryChang
Please note the question above.
- I wanted to also ask if the Jetson Orin Nano devkit 8GB with no EMMC has support for secure boot?
Maybe this is causing the issue.
- Does production mode fuse needs to be activated?
hello cristian.hidalgo,
FYI,
we’ve confirmed by burning SBKPKC fuses (flash and boot-up successfully) with Orin-NX-8GB (no eMMC).
here’re our steps for your reference,
(1) $ sudo ./odmfuse.sh -X fuses.xml -i 0x23 jetson-orin-nano-devkit
(2) $ sudo ADDITIONAL_DTB_OVERLAY_OPT="BootOrderNvme.dtbo" ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml" -u rsa_priv-3k.pem -v sbk.key --showlogs --network usb0 jetson-orin-nano-devkit internal
(3) $ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only -u rsa_priv-3k.pem -v sbk.key jetson-agx-orin-devkit internal
note,
as mentioned by developer guide, it recommends burning all the fuses (including production mode) you need in a single operation.
Hello @JerryChang
That is good to know. We have a problem, our board does not support NVME at the moment, it stopped working. We are only able to flash with SD card.
Could you try flashing using SD card and sending the logs please?
hello cristian.hidalgo,
let me check internally whether we’ve logs for sharing.
you may see-also developer guide, To Flash the Jetson Developer Kit Operating Software for the commands to flash Orin Nano SD.