Flash with initrd failed r3273

[854053437]

I would like to reflash a Xavier NX using l4t_initrd_flash.sh, and follow README_initrd_flash to configuration. When burning to a certain stage， it will stuck in “Ongoing processes:11821” for a long time
Here are host log, flash log and serial log, I want to know why causes it
host log.txt (1.2 KB)
flash_1-8_0_20230831-194909.log (3.5 KB)
jetson serial log.txt (1.9 KB)

by the way, it was still printing “ongoing process” for forty minutes in the first time, so this log is cancelled when it started printing “ongoing process”.

It was my first time to reflash Jetson board, so maybe I neglected many key points, and thank you for help!

[DaveYYY]

Hi,

what was the flashing command you used?
Is is a DevKit or a custom board?
Does changing to r35 make any difference?

[854053437]

I used this command:
ROOTFS_AB=1 ROOTFS_RETRY_COUNT_MAX=1 l4t_initrd_flash.sh --external-device mmcblk1 -c myboard_flash_external.xml myboard internal

it’s a custom board

we used another board to flash r35 is successed, but it’s a AGX Xavier.

I noticed that in the host flash log,

/NVME/Jetson/jacb/Linux_for_Tegra/temp_initrdflash/bootloader0 /NVME/Jetson/jacb/Linux_for_Tegra
./tegraflash.py

missing “–bldtb xxx.dtb” compared with AGX Xavier

[DaveYYY]

Hi,

can you please attach the full flashing log and serial console log, instead of the cropped one?

@854053437

ROOTFS_AB=1 ROOTFS_RETRY_COUNT_MAX=1 l4t_initrd_flash.sh --external-device mmcblk1 -c myboard_flash_external.xml myboard internal

Assuming it’s an SD card on the carrier board, you should be using mmcblk1p1 instead of mmcblk1.

@854053437

missing “–bldtb xxx.dtb” compared with AGX Xavier

Did you remember to add the dtb entry for bootloader in the config file?
You should set both dtb for kernel and bootloader like this:
(from p3668.conf.common)

DTB_FILE=tegra194-p3668-all-p3509-0000.dtb;
TBCDTB_FILE=tegra194-p3668-all-p3509-0000.dtb;

[854053437]

sorry for that, but the log I uploaded is the full log
I only extract the host flash log and here is the full host log
host flash log.txt (165.4 KB)

my board is used eMMC not SD card

the dtb entry has already added into .conf.common file

[DaveYYY]

Hi,

then can you please check your device tree, and make sure only one sdhci instance is enabled?
If you only have one storage device (eMMC/SD card), then it should present as mmcblk0p1 instead of mmcblk1p1.
Either way, you need to flash with mmcblkxp1, but not just mmcblkx.

Also, have you tried flash.sh instead of initrd flash?

[854053437]

thanks,
I’ll check this point, and in the flash log, it stucked in RCM boot BootRom communication

I have already flashed the BSP successfully using by flash.sh, the reason why I want to use initrd flash is that I want to flash the external emmc directly

[DaveYYY]

Hi,

@854053437

the reason why I want to use initrd flash is that I want to flash the external emmc directly

eMMC and SD cards are directly supported in the MB2 firmware, so whether it’s on the module itself or on the carrier board, you should be able to flash them with flash.sh, and there is no need to use initrd flash.

[854053437]

Sorry, there’s a problem with my expression.
I want to use initrd flash to burn both internal and external EMMC at the same time, and I tried many times is will stuck in bootrom communication

[DaveYYY]

Hi,

so you have both mmcblk0 (eMMC on the module) and mmcblk1 (eMMC on the carrier board), and you want to flash them at the same time?
Then does flashing them individually with flash.sh work?
(You may need to modify the script so it accepts mmcblk1 as an valid internal device.)

@854053437

jetson serial log.txt (1.9 KB)

Is this all you can get from serial console?

What if without ROOTFS_AB=1 and using the default partition layout file? Did you design the config correctly so it can support A/B redudancy?

[854053437]

Yes, the perpose is to flash some application into external eMMC while flashing the OS.

the serial console only had these infomation, the reason may is in the flash log stopped in bootrom communication

I’m trying to only use the default way to use initrd flash, and it’s the same phenomenon that flash stucked in the same place, bootrom is not running. And there is no problem in r3521.

I think there is no problem in configueration because using flash.sh is correct

[DaveYYY]

Hi,

@854053437

I’m trying to only use the default way to use initrd flash, and it’s the same phenomenon that flash stucked in the same place, bootrom is not running. And there is no problem in r3521.

What was the full command you used in this step?
Would it work by flashing only one device at a time with initrd flash like this?

sudo ./tools/kernel_flash/l4t_initrd_flash.sh <board-name> <rootdev>

[854053437]

the command I used is
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device mmcblk1 -c uih_vdcb_flash_external.xml uih_vdcb internal

and also used
sudo ./tools/kernel_flash/l4t_initrd_flash.sh uih_vdcb mmcblk0p1

They all failed in the same way

[854053437]

I notice a strange thing，I didn’t use --no-flash option but it’s just in the host flash log

[DaveYYY]

Hi,

@854053437

host flash log.txt (165.4 KB)

so either way, the flashing log stopped with:

Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes: 21187
Ongoing processes:
Flash complete (WITH FAILURES)

, and serial console log gave nothing more than

[0058.639] I> Rebooting : reboot-recovery

?

@DaveYYY

Then does flashing them individually with flash.sh work?
(You may need to modify the script so it accepts mmcblk1 as an valid internal device.)

Have you checked this?

@854053437

I notice a strange thing，I didn’t use --no-flash option but it’s just in the host flash log

This is expected.
The process of initrd flash is splitted into generating the flashing package with --no-flash and actually flashing with --flash-only.

[854053437]

Yes, they are the whole log content

Have you checked this?

I didn’t get this one, and in another board using mmcblk1 to flash with initrd did not have any problem

This is expected.
The process of initrd flash is splitted into generating the flashing package with --no-flash and actually flashing with --flash-only .

Then my flash is actually failed in the flash-only stage?

[DaveYYY]

@854053437

I didn’t get this one, and in another board using mmcblk1 to flash with initrd did not have any problem

Are these two boards of the same hardware design?
I’d suggest trying if flash.sh is able to flash mmcblk1 first.
Patch you flash.sh like this:

-- if [[ "${target_rootdev}" == "internal" || "${target_rootdev}" == mmcblk0p* || \
++ if [[ "${target_rootdev}" == "internal" || "${target_rootdev}" == mmcblk0p* || "${target_rootdev}" == mmcblk1p* \

@854053437

Then my flash is actually failed in the flash-only stage?

Sounds like the case.
I don’t see any error in generating the flashing package.

[854053437]

Thanks, I’ll try