Failed to turn isp power on error at OrinNano 8GB L4T 35.5.0

Hardware:
	Jetson Orin based CustomBoard
BSP:
	L4T 35.5.0 

We are working on OrinNano based Custom Board.
During the migration from L4T 35.4.1 to 35.5.0, we encountered the following.

1. In L4T 35.5.0, create a massflashblob as follows, specifying BOARDID=3767 and BOARDSKU=0003.

$ sudo BOARDID=3767 BOARDSKU=0003 ./tools/kernel_flash/l4t_initrd_flash.sh --no-flash \
        --external-device nvme0n1p1 \
        -S $((18*1024*1024*1024)) \
        -c tools/kernel_flash/flash_l4t_external.xml \
        -p "-c bootloader/t186ref/cfg/flash_t234_qspi.xml --no-systemimg" \
        --erase-all \
        --massflash 5 \
        --showlogs \
        dx-u2200+p3767-0000 \
        nvme0n1p1

2. While writing the firmware, the following error and hangup occurs during Bootloader startup.

Jetson UEFI firmware (version 202210.4-65fa3650 built on 2024-03-12T02:56:33+00:00)
...

ERROR: camera-ip/isp5/isp5.c:1980 [isp5_pm_init] "ERROR: Failed to turn isp power on"
BUG: core/init/init.c:85 [init_all] "*** FIRMWARE INIT FAILED AT LEVEL 95 ***"

After long investigation, when creating firmware for OrinNano 8GB/4GB,
The following BPFFILE=bpmp_t234-TE980M-A1_prod.bin is used in the OrinNano 8GB/4GB firmware,
This error was found to occur.

Existing bpffile(.../Linux_for_Tegra/bootloader/bpmp_t234-TE980M-A1_prod.bin) reused.

20240415_1547_initrd_massflashgen_qspinvme_0003_log_bootNG.txt (340.1 KB)

No error occurred when BPFFILE=bpmp_t234-TE950M-A1_prod.bin is used, as shown below.

Existing bpffile(.../Linux_for_Tegra/bootloader/bpmp_t234-TE950M-A1_prod.bin) reused.

20240416_1654_initrd_massflashgen_qspinvme_0003_log_bootOK.txt (340.3 KB)

This error is due to the following difference in p3767.conf.common from R35.4.1 → R35.5.0.

[p3767.conf.common]

process_board_version()
{
...
-	if [ "${board_sku}" = "0003" ] || [ "${board_sku}" = "0004" ] || \
-		[ "${board_sku}" = "0005" ]; then
-			BPFFILE="bootloader/bpmp_t234-TE950M-A1_prod.bin";
-	fi
}

Why this process been removed in R35.5.0?

I am aware that the following files should be used for OrinNano 8GB/4GB (SKU=0003/0004) like L4T 35.4.1. Is this correct?

bpmp_t234-TE950M-A1_prod.bin 
bpmp_t234-TE950M-A1_prod_sigheader.bin.encrypt

Hi,

The logic is changed from deciding based on board SKU to chip SKU:

process_chip_sku_version()
{
	local chip_sku="${1}";
	local chip_minor_revision_id="${2}";
	local bootrom_revision_id="${3}";
	local ramcode="${4}";
	local fuselevel="${5}";
	local board_FAB="${6}";
	declare -A bpmp_fw_binary;
	bpmp_fw_binary['D3']="TE980M-A1";
	bpmp_fw_binary['D4']="TE980M-A1";
	bpmp_fw_binary['D5']="TE950M-A1";
	bpmp_fw_binary['D6']="TE950M-A1";

	chip_sku="${chip_sku:-${DEFAULT_CHIP_SKU}}"

	if [[ "${chip_sku}" =~ ":" ]]; then
		chip_SKU=`echo "${chip_sku}" | awk -F ":" '{print $4}'`;
	fi;

	# do not override BPFFILE for INT SKU "00"
	if [ "${chip_SKU}" != "00" ]; then
		BPFFILE=`echo "${BPFFILE}" | sed "s|T.*-A1|${bpmp_fw_binary[${chip_SKU}]}|"`;
	fi;

	echo "Chip SKU(${chip_sku}) ramcode(${ramcode}) fuselevel(${fuselevel}) board_FAB(${board_FAB})"
}

We will check if there’s a bug here.

Hi,

Can you make sure again if you are really using Orin Nano SKU3?

Board ID(3767) version() sku(0003) revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()

chip SKU D3 means it’s TE980M, which is either Orin NX SKU0/SKU1.

Board ID(3767) version() sku(0003) revision()
Chip SKU() ramcode() fuselevel(fuselevel_production) board_FAB()

This one succeeded because somehow the chip SKU was not read, so it by default used TE950M for the firmware.

If you are unsure of the module, try not specifying BOARDID=3767 and BOARDSKU=0003, and it will read the board SKU number from the module itself.

Hi,

The logic is changed from deciding based on board SKU to chip SKU:

Does this logic assume the creation of a massflashblob without connecting the actual device?

We have already developed a common Custom CarrierBoard for the following CPUs

https://docs.nvidia.com/jetson/archives/r35.5.0/DeveloperGuide/IN/QuickStart.html

OrinNX 16GB (P3767-0000)
OrinNX 8GB (P3767-0001)
OrinNano 8GB (P3767-0003)
OrinNano 4GB (P3767-0004)

When we create a massflashblob for each CPU, we create the blob by specifying no-flash, BOARDID, and BOARDSKU without actually connecting the Board to the HostPC.

Can you make sure again if you are really using Orin Nano SKU3?

Yes, to create a massflashblob for an OrinNano 8GB (P3767-0003),
we specify BOARDID=3767 and BOARDSKU=0003.

If BOARDID and BOARDSKU are specified directly,
wouldn’t TE950 be selected without the following logic?

[p3767.conf.common]

process_board_version()
{
...
	if [ "${board_sku}" = "0003" ] || [ "${board_sku}" = "0004" ] || \
		[ "${board_sku}" = "0005" ]; then
			BPFFILE="bootloader/bpmp_t234-TE950M-A1_prod.bin";
	fi
}

So both tests are done wiothout actually connecting the board?
I’m not sure why you are getting different results as:

Board ID(3767) version() sku(0003) revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()

Board ID(3767) version() sku(0003) revision()
Chip SKU() ramcode() fuselevel(fuselevel_production) board_FAB()

You can also check the real chip SKU this way.

So both tests are done wiothout actually connecting the board?

Yes. That what we want to do.
We want to create massflashblob without connecting the board every single time.

I’m not sure why you are getting different results as:

Board ID(3767) version() sku(0003) revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()

Board ID(3767) version() sku(0003) revision()
Chip SKU() ramcode() fuselevel(fuselevel_production) board_FAB()

Are you talking about dirrerence between
[20240415_1547_initrd_massflashgen_qspinvme_0003_log_bootNG.txt]
and
[20240416_1654_initrd_massflashgen_qspinvme_0003_log_bootOK.txt ]?

This is because we already restore L4T 35.4.1 code
about process_chip_sku_version(), process_board_version() in [bootOK.txt ] case.

You can also check the real chip SKU this way.

We confirmed SKU again by not specifying BOARDID, BOARDSKU like below.
This environment p3767.conf.common is Linux_for_Tegra 35.5.0 original.

[   1.3259 ] MB2 Applet version 01.00.0000
Board ID(3767) version(300) sku(0003) revision(L.3)
Chip SKU(00:00:00:D5) ramcode(00:00:00:02) fuselevel(fuselevel_production) board_FAB(300)
emc_opt_disable_fuse:(0)

20240417_1617_initrd_massflashgen_qspinvme_0003_with_cpu_log.txt (128.7 KB)

OK, so I think the issue is that the previous version (35.4.1) only relies on board SKU to determine which BPMP firmware to use, as you can see in

process_board_version()
{
...
	if [ "${board_sku}" = "0003" ] || [ "${board_sku}" = "0004" ] || \
		[ "${board_sku}" = "0005" ]; then
			BPFFILE="bootloader/bpmp_t234-TE950M-A1_prod.bin";
	fi
}

Therefore, specifying only BOARDID=3767 and BOARDSKU=0003 is enough for this scenario.
However, in 35.5, the same logic is determined by chip SKU, but since no physical boards are connected, it fails to read the info, and falls back to the default one, which is

BPFFILE="bootloader/bpmp_t234-TE980M-A1_prod.bin";
DEFAULT_CHIP_SKU="00:00:00:D3";

(This is not an issue on 35.4.1 as described above.)

If you want to stick with your current script, I think it’s fine to revert the config file back with the one in 35.4.1, or you either specify CHIP_SKU in the command, or have a physical board connected when generating the package, so the right info is populated.

If you want to stick with your current script,
I think it’s fine to revert the config file back with the one in 35.4.1,
or you either specify CHIP_SKU in the command,

Thank you for your confirm.
We will also consider specify CHIP_SKU.

1 Like

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