Flash_l4t_external.xml issue with L4T 36.4

Autonomous Machines Jetson & Embedded Systems Jetson Orin NX
1

Hi nVIDIA,

I try to use flash_l4t_external.xml with --no-flash flag to packing images.
The log show “XPath set is empty”, and it cause an empty parameter --bl with ./tegraflash.py

Using bpmp-dtb concatenated with odmdata in blob for t23x
XPath set is empty
./tegraflash.py --bl  --bct br_bct_BR.bct --bldtb tegra234-p3768-0000+p3767-0000-nv.dtb --applet rcm_2_encrypt.rcm --applet_softfuse rcm_1_encrypt.rcm --cmd "secureflash;reboot"  --cfg secureflash.xml --chip 0x23 --mb1_bct mb1_bct_MB1_sigheader.bct.encrypt --mem_bct mem_rcm_sigheader.bct.encrypt --mb1_cold_boot_bct mb1_cold_boot_bct_MB1_sigheader.bct.encrypt --mb1_bin mb1_t234_prod_aligned_sigheader.bin.encrypt --psc_bl1_bin psc_bl1_t234_prod_aligned_sigheader.bin.encrypt --mem_bct_cold_boot mem_coldboot_sigheader.bct.encrypt  --bins "psc_fw pscfw_t234_prod_sigheader.bin.encrypt; mts_mce mce_flash_o10_cr_prod_sigheader.bin.encrypt; tsec_fw tsec_t234_sigheader.bin.encrypt; mb2_applet applet_t234_sigheader.bin.encrypt; mb2_bootloader mb2_t234_with_mb2_bct_MB2_sigheader.bin.encrypt; xusb_fw xusb_t234_prod_sigheader.bin.encrypt; pva_fw nvpva_020_sigheader.fw.encrypt; dce_fw display-t234-dce_sigheader.bin.encrypt; nvdec nvdec_t234_prod_sigheader.fw.encrypt; bpmp_fw bpmp_t234-TE980M-A1_prod_sigheader.bin.encrypt; bpmp_fw_dtb tegra234-bpmp-3767-0000-a02-3509-a02_with_odm_sigheader.dtb.encrypt; rce_fw camera-rtcpu-t234-rce_sigheader.img.encrypt; ape_fw adsp-fw_sigheader.bin.encrypt; spe_fw spe_t234_sigheader.bin.encrypt; tos tos-optee_t234_sigheader.img.encrypt; eks eks_t234_sigheader.img.encrypt"
saving flash command in flashcmd.txt

*** no-flash flag enabled. Exiting now... ***

User can run above saved command in factory environment without
providing pkc and sbk keys to flash a device

Example:

    $ cd bootloader
    $ sudo bash ./flashcmd.txt

complete log: log.txt (238.2 KB)

In the end, it use uefi_jetson_with_dtb_aligned_blob_w_bin_sigheader.bin.encrypt in parameter --bl not uefi_jetson_with_dtb_sigheader.bin.encrypt

My device (Orin NX + our carrier board) cannot enter RCM when I use flash_l4t_external.xml with --flash-only.
This issue occur with L4T 36.4, but L4T 36.3 is fine.
The value of --bl always be uefi_jetson_with_dtb_sigheader.bin.encrypt when I used L4T 36.3

I found the root cause in Linux_for_Tegra/bootloader/odmsign.func, diff from 36.3 to 36.4

        if [ "${CHIPID}" = "0x23" ]; then
+               get_value_from_PT_table "A_cpu-bootloader" "filename" ${securecfgfile} flashername
+
                # handle differently with and without SBK key
                if [ "${sbk_keyfile}" != "" ]; then
-                       get_value_from_PT_table "A_cpu-bootloader" "filename" ${securecfgfile} flashername
-
                        # Special handling for --mb1_bin
                        extsig tmp_mb1bin ${mb1filename} '_aligned_sigheader_encrypt' 'signed'
                        # Special handling for --psc_bl1_bin

Is this an issue?

3

What is the exact error here? I checked your attachment but didn’t see any error.

If the error is this one,

My device (Orin NX + our carrier board) cannot enter RCM when I use flash_l4t_external.xml with --flash-only.

Then please share the log. I don’t quite understand what does that mean “cannot enter RCM” as entering RCM is triggered by using a hardware jumper or button.

Also, flashcmd is not able to flash external device.

4

Thanks for your quickly reply Wayne.

log of flash_l4t_external.xml with --flash-only:
flash_1-2_0_20241105-163755.log (9.5 KB)

My “cannot enter RCM” means RCM boot fail, and host PC cannot communicate to SoM by SSH.
Sorry for my imprecise wording, how should I describe it? Just RCM boot fail?

I can upgrade my device by “clean L4T 36.3” or “L4T 36.4 + patch” below:

        if [ "${CHIPID}" = "0x23" ]; then
-               get_value_from_PT_table "A_cpu-bootloader" "filename" ${securecfgfile} flashername
-
                # handle differently with and without SBK key
                if [ "${sbk_keyfile}" != "" ]; then
+                       get_value_from_PT_table "A_cpu-bootloader" "filename" ${securecfgfile} flashername
+
                        # Special handling for --mb1_bin
                        extsig tmp_mb1bin ${mb1filename} '_aligned_sigheader_encrypt' 'signed'
                        # Special handling for --psc_bl1_bin

I want to figure out why I cannot upgrade my device with clean L4T 36.4 ?
And I think it cause by --bl parameter

5

Just to clarify… I have no idea what you are doing here so I cannot comment to you why something go wrong here.
Just give the command you are using and why you want to use that.

Don’t show me that you added some patch in the script as that does not matter at this moment. Clarify your purpose first.

Also, if the flash attempt is stuck in “Waiting for target to boot-up…”, then it is telling you to check the serial log from UART. Take this as common sense if you want to dig into flash issues.

Also, some misleading points from your comment. “RCM” generally means “recovery mode”. But there are also something called “RCM boot”. These things are different and should not be used in wrong way.

6 
Just to clarify… I have no idea what you are doing here so I cannot comment to you why something go wrong here.
Just give the command you are using and why you want to use that.

We use Jetson Linux r36.3 with our carrier board about 2 months, every thing is fine.
I can packing images by:
sudo FUSELEVEL=fuselevel_production BOARDID=3767 BOARDSKU=0000 FAB=300 BOARDREV=G.3 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p " -c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit external
flash those images by:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 jetson-orin-nano-devkit external

Now we want to use Jetson Linux r36.4 instead of r36.3.
I can packing images by:
sudo FUSELEVEL=fuselevel_production BOARDID=3767 BOARDSKU=0000 FAB=300 BOARDREV=G.3 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p " -c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit external
but I can’t flash those images by:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 jetson-orin-nano-devkit external

Don’t show me that you added some patch in the script as that does not matter at this moment. Clarify your purpose first.

the patch is not for our carrier board, I just find the difference between r36.3 and r36.4,
restore these two lines from r36.4 back to r36.3, then it work.
We can ignore this, and follow your debug steps.

Also, if the flash attempt is stuck in “Waiting for target to boot-up…”, then it is telling you to check the serial log from UART. Take this as common sense if you want to dig into flash issues.

We have some trouble about this debug UART, we are trying to fix it now.
I have no uart debug log for now.

Also, some misleading points from your comment. “RCM” generally means “recovery mode”. But there are also something called “RCM boot”. These things are different and should not be used in wrong way.

Got it, from the logs, it start RCM boot but cannot have a connectable SSH server in time.
it should be RCM boot not RCM, thanks.

So, is there anything I can provide to you before we fix the debug UART?

7

No, just fix your uart first.

8

Also, does this board get any secure fuse?

9

As I know,

  1. SoM include a programmable fuse
  2. There is no secure fuse on our carrier board, only TPM chip.

We did not need to enable/verify secure boot for now.

11

I duplicate this issue again after my uart work

cmd:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml --showlogs --network usb0 jetson-orin-nano-devkit external
log:
flash_1-2_0_20241113-131414.log (9.6 KB)
uart_log.txt (72.2 KB)

from the uart_log, I think it should boot with kernel cmdline with “root=/dev/initrd”, but it doesn’t

12

  1. Before you run the flash command, did you also put the board to recovery mode?

  2. Is there any other log prior to the timestamp 60 sec here? When the Boot-mode showed “Coldboot”, it means it is another normal boot but not the RCM boot for initrd flash.

[0060.765] I> MB1 (version: 1.4.0.4-t234-54845784-e89ea9bc)
[0060.771] I> t234-A01-0-Silicon (0x12347) Prod
[0060.775] I> Boot-mode : Coldboot

13

  1. Yes, I move the jumper first, then power on enter RCM.
    Using lsusb to confirm “Bus 001 Device 007: ID 0955:7323 NVIDIA Corp. APX”, then run flash command

  2. There is no more log.
    I capture the uart log after I confirmed lsusb. (before run flash command)

Then I try it again, capture the uart log before power on, there is no more log too.
uart_log_2.txt (71.4 KB)

14

So it just blanked for 60 sec and then give you that cold boot log?

15

I think the 60s is not static.
It depend on the interval between device power on and flash command.

The second log start from 4s not 60s.

16

What is “second log” here? The uart log you shared?

17

it means uart_log_2.txt
I run the flash command again, but shorten the interval between device power on and flash command.

18

I see. Let us check what is going on there.

20

Hi chuka_chiu,
After our internal check, please try running the following commands:

#1. create internal
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --no-flash --network usb0 jetson-orin-nano-devkit internal
#2. create external
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --no-flash --external-device nvme0n1p1 -p "-T 251658240" -S 50GiB -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --external-only --append --network usb0 jetson-orin-nano-devkit external
#3. flash both
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --showlogs --network usb0 --flash-only
21

Hi David,

I can flash my device successfully with your command, but rootfs UUID is mismatch, can you check the uart log?
uart_log_w_nvcmd.txt (182.0 KB)

Another question, why r36.4 need to create internal and external separately but r36.3 doesn’t ?

22

Hi Chuka_Chiu,

To resolve the rootfs ID mismatch, please try formatting the NVMe to the ext4 format and then reflash it.
Regarding the flash command issue, we will do further checks to reproduce the problem.

Thank you.

24

Hi David,

Any update for the flash command issue?