Issues flashing Jetson Orin nano devkit with TEGRA_SIGNING_ARGS set and fused keys

[wavesid]

Hello

Describe the bug I have the exact same setup as this issue: https://github.com/OE4T/meta-tegra/issues/1639 i already opened an issue and the outcome was to fuse the keys and re-test https://github.com/OE4T/meta-tegra/issues/1674.

I am using Jetson Orin Nano 8GB devkit, with this option: TEGRA_SIGNING_ARGS set to the following

TEGRA_SIGNING_ARGS = "-u pkc.key -v sbk.key"

The keys are fused. The official script l4t_initrd_flash.sh from Jetson Linux works with my keys so I suppose the fusing happened without issues and the keys are correct.

This is the logs:

using sudo ./doflash.sh

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.0100 ] Parsing partition layout
[   0.0105 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0119 ] Parsing partition layout
[   0.0122 ] tegraparser_v2 --pt secureflash.xml.tmp
[   0.0134 ] mb1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --mb1_bin
[   0.0134 ] psc_bl1_t234_prod_aligned_sigheader_encrypt.bin.signed filename is from --psc_bl1_bin
[   0.0134 ] Boot Rom communication
[   0.0137 ] 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.0141 ] BR_CID: 0x80012344705DF11F2400000013028100
[   0.0405 ] Sending bct_br
[   0.0800 ] Sending mb1
[   0.0807 ] 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

using sudo ./initrd-flash

Starting at 2024-08-23T18:03:47+02:00
Machine:       jetson-orin-nano-devkit-nvme
Rootfs device: nvme0n1p1
Found Jetson device in recovery mode at USB 1-1
== Step 1: Signing binaries at 2024-08-23T18:03:47+02:00 ==
== Step 2: Boot Jetson via RCM at 2024-08-23T18:03:48+02:00 ==
Found Jetson device in recovery mode at USB 1-1
./initrd-flash: line 191: ./rcm-boot.sh: No such file or directory
ERR: RCM boot failed at 2024-08-23T18:03:48+02:00

To Reproduce Steps to reproduce the behavior:

1. Build meta-tegra branch 'scarthgap' (latest commit) with MACHINE set to 'jetson-orin-nano-devkit-nvme'
2. Set TEGRA_SIGNING_ARGS with -u pkc.key -v sbk.key
3. Build with bitbake image
4. Deploy to hardware with method tegraflash using sudo ./doflash.sh (or using sudo ./initrd-flash)
5. See logs above

Additional context I checked USB connection, using PKC + SBK keys, I do not have logs in UART

The keys are fused. The official script l4t_initrd_flash.sh from Jetson Linux works with my keys so I suppose the fusing happened without issues and the keys are correct.

Let me know if there is any way to debug

[ichergui]

Hi @wavesid

Did you try to build without TEGRA_SIGNING_ARGS and flash your device with this command line $ sudo ./doflash.sh -u PKC.pem -v SBK.key ?

[wavesid]

Yes if I build an image without TEGRA_SIGNING_ARGS set, both commands works without issues:

sudo ./initrd-flash -u PKC.pem -v SBK.key and sudo ./doflash.sh -u PKC.pem -v SBK.key

[ichergui]

@wavesid thanks for your quick feedback. I need to investigate that.I tried the Orin AGX devkit and it does work perfectly. I mean signing at build time and post build. Both methods works fine. @madisongh Could you please share your thoughts ? @wavesid is able to flash his device when signing/encrypting images/binaries post build. with the following command

$ sudo ./doflash.sh -u PKC.pem -v SBK.key

However, the signing at build time doesn't work when using jetson-orin-nano-devkit-nvme.

[madisongh]

If it works when directly flashing, but not when signing during the build, then my bet would be on some difference between the default FAB/BOARDSKU/etc. settings we have for the machine vs. the actual ones being reported during the flashing process.