FATAL ERROR from Bootloader when flash from massflashblob

We are working with [OrinNano EVK(p3768-000) + OrinNano 8GB CPU Module(p3767-0003) + NVMeSDD] environment.

We want to check flashing by massflashblob in R36.2.0.

When we flash directly without massflash blob, there is no error and boot succeed.

$ time sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1  \
 -c tools/kernel_flash/flash_l4t_external.xml -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
 --showlogs --network usb0 p3768-0000-p3767-0000-a0 nvme0n1p1

When we create and flash from massflash blob, stop booting at UEFI and following error happened.

FATAL ERROR [FILE=platform/top/bpmp/startup/sku.c, ERR_UID=598]: chip sku 0xd5 not in <nv>/sku/te980m_0
...
綸RROR: camera-ip/isp5/isp5.c:2031 [isp5_pm_init] "ERROR: Failed to turn isp1 power on"

 痳BUG: core/init/init.c:86 [init_all] "*** FIRMWARE INIT FAILED AT LEVEL 95 ***"

Could you tell me how to create massflashblob in 36.2.0 for (p3768-000 + p3767-0003) envirmonment?

Seqnence:

  1. Extract new Linux_for_Tegra
$ tar jxf ./jetson_linux_r36.2.0_aarch64.tbz2
Linux_for_Tegra/rootfs$ sudo tar jxf ../../tegra_linux_sample-root-filesystem_r36.2.0_aarch64.tbz2 
  1. Modifying bootloader dtsi for the EEPROM

https://docs.nvidia.com/jetson/archives/r36.2/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html#modifying-the-eeprom

Linux_for_Tegra/bootloader/tegra234-mb2-bct-common.dtsi (the MB2 BCT file),
make the following modification:

- cvb_eeprom_read_size = <0x100>
+ cvb_eeprom_read_size = <0x0>
  1. Create Massflashblob
$ TARGET_CONF=p3768-0000-p3767-0000-a0
$ ROOTFS_SIZE=$((8*1024*1024*1024))

$ sudo BOARDID=3767 BOARDSKU=0003 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash \
        --external-device nvme0n1p1 \
        -S ${ROOTFS_SIZE} \
        -c tools/kernel_flash/flash_l4t_external.xml \
        -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
        --massflash 5 \
        --showlogs \
        --network usb0 \
        ${TARGET_CONF} \
        nvme0n1p1
  1. Flash from Massflashblob
mfi_p3768-0000-p3767-0000-a0$ time sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0 --massflash 5
mfi_p3768-0000-p3767-0000-a0/tools/kernel_flash/l4t_initrd_flash_internal.sh --network usb0 --usb-instance 3-2 --device-instance 0 --flash-only --external-device nvme0n1p1 -c "tools/kernel_flash/flash_l4t_external.xml" -S 8589934592 --network usb0 p3768-0000-p3767-0000-a0 nvme0n1p1
Start flashing device: 3-2, rcm instance: 0, PID: 6270
Log will be saved to Linux_for_Tegra/initrdlog/flash_3-2_0_20240301-104248.log 
Ongoing processes: 6270
Ongoing processes: 6270
Ongoing processes: 6270
Ongoing processes: 6270
Ongoing processes: 6270
Ongoing processes: 6270
^C

flash_3-2_0_20240301-104248_console.log (24.7 KB)
flash_3-2_0_20240301-104248.log (6.1 KB)

Have you tested on DevKits?
I don’t feel like it’s even related to massflash.
It should also happen when you flash these devices one-by-one without massflash.

We also checked [OrinNano EVK(p3768-000) + EVK CPU Module(p3767-0005) + NVMeSDD] environment.

Same error occurred when writing to DevKits with a massflash blob.

  1. Create Massflashblob
$ TARGET_CONF=p3768-0000-p3767-0000-a0
$ ROOTFS_SIZE=$((8*1024*1024*1024))

$ sudo BOARDID=3767 BOARDSKU=0005 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash \
        --external-device nvme0n1p1 \
        -S ${ROOTFS_SIZE} \
        -c tools/kernel_flash/flash_l4t_external.xml \
        -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" \
        --massflash 5 \
        --showlogs \
        --network usb0 \
        ${TARGET_CONF} \
        nvme0n1p1
  1. Flash from Massflashblob
mfi_p3768-0000-p3767-0000-a0$ time sudo ./tools/kernel_flash/l4t_initrd_flash.sh --flash-only --network usb0 --massflash 5
mfi_p3768-0000-p3767-0000-a0/tools/kernel_flash/l4t_initrd_flash_internal.sh --network usb0 --usb-instance 3-2 --device-instance 0 --flash-only --external-device nvme0n1p1 -c "tools/kernel_flash/flash_l4t_external.xml" -S 8589934592 --network usb0 p3768-0000-p3767-0000-a0 nvme0n1p1
Start flashing device: 3-2, rcm instance: 0, PID: 14834
Log will be saved to Linux_for_Tegra/initrdlog/flash_3-2_0_20240301-161638.log 
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes: 14834
Ongoing processes:
Flash complete (WITH FAILURES)

real	2m31.701s
user	0m11.376s
sys	0m8.662s

Could you please tell me the steps to create a massflash for DevKit?

flash_3-2_0_20240301-161638.log (9.5 KB)
flash_3-2_0_20240301-161638_console.log (24.7 KB)

I don’t belive you should still hit this on DevKits, please make sure you are using the clean BSP from NVIDIA without any changes for test with DevKits.
For you custom carrier board, I think the issue comes from ODMDATA regarding PCIe usage.
Please check the two posts and also our documents:
https://docs.nvidia.com/jetson/archives/r35.4.1/DeveloperGuide/text/HR/JetsonModuleAdaptationAndBringUp/JetsonOrinNxNanoSeries.html?highlight=odmdata#uphy-lane-configuration

Again, this is not related to massflash at all.
Please don’t get stuck in the wrong direction.

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