Failed to flash signed boot image

Autonomous Machines Jetson & Embedded Systems Jetson Xavier NX
1

Hi
I tried to flash Jetson Xavier NX by following guide"To sign and flash in separate steps" .But failed and It is showing the below error.

[ 2.0769 ] Sending BCTs
[ 2.0795 ] tegrarcm_v2 --download bct_bootrom br_bct_BR.bct --download bct_mb1 mb1_bct_MB1_sigheader.bct.signed --download bct_mem mem_rcm_sigheader.bct.signed
[ 2.0820 ] Applet version 01.00.0000
[ 2.1175 ] Sending bct_bootrom
[ 2.1184 ] […] 100%
[ 2.1208 ] 000000001d1d1118: E> LOADER: Failed to verify Stage2Signature SHA2.

Error: Return value 24

What means for this error code? Steps as belowing right? Or fuses must be burned firstly?

  1. Generate key by “$ openssl genrsa -out rsa_priv.pem 2048”
  2. Sign the boot files by “$ sudo ./flash.sh --no-flash -u rsa_priv.pem jetson-xavier-nx-devkit-emmc mmcblk0p1”
  3. Flash by “$ cd bootloader
    $ sudo bash ./flashcmd.txt”

Thanks in advance

3

hello huangml,

what’s your actual use-case?
is this target program fuse before, you’ll need to flash the board with the same key.

4

Hi Jerry,

No fuses burned before. Just want to know if the system is still workable after signed images flashed without fuses burned, and if the system still can enter RCM?

5

hello huangml,

it’s by default to have zero encrypt to flash the target.
here’s part of flashing message for your reference,

[ 459.4635 ] Writing partition kernel with boot_sigheader.img.encrypt
[ 459.5061 ] [................................................] 100%
[ 461.8474 ] Writing partition kernel_b with boot_sigheader.img.encrypt
[ 461.8555 ] [................................................] 100%
[ 464.1538 ] Writing partition kernel-dtb with tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt
[ 464.1617 ] [................................................] 100%
[ 464.1722 ] Writing partition kernel-dtb_b with tegra194-p3668-all-p3509-0000_sigheader.dtb.encrypt
[ 464.1949 ] [................................................] 100%

you may also enable Jetson Security to protect the device.
fuses are designed to be inaccessible for production. the concept of Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust;

those authenticates boot components (such as, Boot Configuration Table, bootloader binaries, and warmboot vector) were signed using private key. (i.e. PKC / SBK)
for example,
there’s PKC used to ensure data integrity.
with PKC protection, if there’s any boot code changes or corruption, boot should not be able to go through.
there’s also SBK to protect data confidentiality.
with SBK protection, boot code should be properly encrypted, it will check signature for boot.

please also refer to developer guide, please check Secureboot chapter for more details.
thanks

6

Hi Jerry,

I modify my last post. Could you confirm the fuses must be burned firstly or not before executing “sudo bash ./flashcmd.txt”?

7

hello huangml,

“sudo bash ./flashcmd.txt” it’s the generate flash command-line according to your previous options specify to the flash.sh
so, please don’t use this flash command line since you’re target is not fused.

8

Hi Jerry,

So only fuses burned firstly, images signed with non-zero key can be flashed to target. Right? If yes, is there any way to program the signed images bypass the key verification?

9

hello huangml,

may I know what’s the real use-case to enable this?
as you can see in comment #5, it’s Secureboot is to prevent execution of unauthorized code during boot process through chain-of-trust;

10

Hi Jerry,

We just want to try the process “flash signed image → reboot/shutdown → burn fuses” for MFG. So it sounds not feasible？

11

hello huangml,

that’s just an incorrect process, you should expect failures during image flash.

btw,
please also check developer guide as see-also, Jetson Xavier NX / AGX Xavier / TX2 Update and Redundancy.
there’s bootloader redundancy to reduce the risk of boot failure after a Bootloader update and when images on the current Bootloader slot are corrupted.
so,
if you’re using partition update, (i.e. -k kernel) to update one partition with your own signed image, it’s bootloader redundancy to handle the booting failure, you may look into bootloader logs for the details.
thanks

1 Like
13

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