Getting flashing error using initrd.sh on JP 6.0 for orion NX on external 16 GB NVMe

[nagesh_accord]

Hi,

We are getting error ( where the target failing to boot in the middle of flashing ) while flashing using initrd.sh script.
Please find the attached error log for the same and let us know what might be the issue.

Thanks.
NVME_fLASH_lOG_Error_device_Boot.txt (287.2 KB)

command used for flashing external nvme for orion NX is :

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -p “-c ./bootloader/generic/cfg/flash_t234_qspi.xml” -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p1

[nagesh_accord]

Also, we are getting below error, when we tried the same flashing command second time again.

/home/trident/Downloads/r36_3_0/Linux_for_Tegra/tools/kernel_flash/l4t_initrd_flash_internal.sh --no-flash --external-device nvme0n1p1 -p -c ./bootloader/generic/cfg/flash_t234_qspi.xml -c ./tools/kernel_flash/flash_l4t_t234_nvme.xml --showlogs --network usb0 jetson-orin-nano-devkit nvme0n1p1

---

•                              *
  

• Step 1: Generate flash packages *

•                              *
  

---

Create folder to store images to flash
Generate image for internal storage devices
Generate images to be flashed
ADDITIONAL_DTB_OVERLAY=“” /home/trident/Downloads/r36_3_0/Linux_for_Tegra/flash.sh --no-flash --sign -c ./bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit nvme0n1p1

###############################################################################

L4T BSP Information:

R36 , REVISION: 3.0

User release: 0.0

###############################################################################
ECID is
Board ID() version() sku() revision()
Chip SKU(00:00:00:D3) ramcode() fuselevel(fuselevel_production) board_FAB()
emc_opt_disable_fuse:(0)
Error: Unrecognized module SKU
Error: failed to generate images
Cleaning up…

[WayneWWW]

1. Is this custom board or NV devkit?

2. Your second issue is just the board is not in recovery mode.

[nagesh_accord]

@WayneWWW

1. Is this custom board or NV devkit?

It’s customized board

@WayneWWW

2. Your second issue is just the board is not in recovery mode.

But when I check with lsusb command
it lists as “Nvidia corp” on the host pc

[WayneWWW]

Hi,

Your uart log during flash will tell.

Using lsusb command may not be the correct way. That is only for flash.sh. Not really 100% mean initrd flash can flash your board. Initrd flash requires more.

[nagesh_accord]

Ok.

1)So next step is to collect uart log during flashing using initrd.sh script ?

2. flash.sh script does not work for this orion nx as we don’t have internal emmc Memory right?

3. can you please confirm and let me know the correct flashing command using initrd.sh for orion nx 16 GB external nvme

[WayneWWW]

Yes, collect the log. It will tell the exact situation.

Actually, if you ever read your own log. It already told you what to do… really try to spend more time reading those things…

Waiting for target to boot-up...
Waiting for target to boot-up...
Timeout
Device failed to boot to the initrd flash kernel. Please retrive the serial log during flashing to debug further.
Cleaning up...

And you can copy the command directly from quick start guide.
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/IN/QuickStart.html

[nagesh_accord]

@WayneWWW

Yes, collect the log. It will tell the exact situation.

Actually, if you ever read your own log. It already told you what to do… really try to spend more time reading those things…

Actually I had read this error. As our board is still in development stage, we don’t have the serial output option currently to.log.the flash log on a seperate pc, hence I posted this question here.

I was bit surprised why flashing stopped in the middle where the target faile to reboot from.initrd.

[WayneWWW]

Most of the error cases are not initrd boot. It is the usb device mode not configured correctly on your board.

When it enters initrd, your recovery mode is gone. That usb device mode becomes the job for initrd (which is also linux kernel driver) to do. Which means if device tree is wrong, usb device mode won’t work.

But there are still other kinds of situation, so UART log is the precise way to debug.

[nagesh_accord]

@WayneWWW

And you can copy the command directly from quick start guide.
Quick Start — NVIDIA Jetson Linux Developer Guide 1 documentation

I copied the command from.here only just modified internal to nvme01P1 and tried but still its not working half way through. The target is not booting…

$ sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1
-c tools/kernel_flash/flash_l4t_t234_nvme.xml -p “-c bootloader/generic/cfg/flash_t234_qspi.xml”
–showlogs --network usb0 jetson-orin-nano-devkit internal

I have one more query. I observe this note section on the quick start guide:
Should be do this while. flashing or should we manually.do it UEFI menu during booting.please through more light on this. Thanks.

When booting your system, make sure to select the corresponding flashed boot media from the UEFI menu to boot. For example, if flashing from an NVMe drive, make sure to select the NVMe drive as your boot option from the UEFI menu.

[nagesh_accord]

Thanks a lot for very informative and elaborate reply.

@WayneWWW

Most of the error cases are not initrd boot. It is the usb device mode not configured correctly on your board.

Configured through hardware or software?
Please. provide some hint how to do this in software (may be device tree) just in case…

@WayneWWW

When it enters initrd, your recovery mode is gone.

When recovery mode is gone…it means when we do lsusb, it won’t list “nvidia corp…” on this host pc?

Or.it’s not the case always as you told earlier for initrd flashing…

@WayneWWW

That usb device mode becomes the job for initrd (which is also linux kernel driver) to do. Which means if device tree is wrong, usb device mode won’t work.

So there are chances that I need to update my device tree file(s). Please provide hint of which dts file I need to. update for this USB device mode stuff,.

@WayneWWW

But there are still other kinds of situation, so UART log is the precise way to debug.

Sure.I will.ask our hardware team to setup option from the custom board to.log serial data while flashing itself.
I hope we get log as we have not done flashing once also on this orion nx module.

[nagesh_accord]

Jetson orin nano - jetpack 6 not flashing with SDK manager ubuntu 22.04

Is there any USB devices other than the flashing cable, like mouse or keyboard, connected to Jetson while flashing? Make sure there is one. Then you know you should have been asking here instead of not making a single reply in 10 days.

Found this thread which says , if any other USB device like mouse or keyboard is connected to the Jetson then flashing will be successful.

Will try this out if the hardware supports more than one USB port and our team can bring them out from.carrier board…

[WayneWWW]

Hi,

Please stop trying anything and just listen to the explanation first… your trying in hurry may just lead to waste of time.

1. The post to connect a usb device to bypass the flash error is just for Jetpack6 DP but not Jeptack6 GA. If you are using jeptack6 GA version, then that post has no value to refer to. Solution is already included…

2. Initrd flash is like this flow:
   board enter recovery mode first (lsusb will show it) → host flash bootloader and initrd to the board → after flash is finished, recovery mode is finished. (lsusb gone) → bootloader tries to boot initrd → initrd will enable usb device mode according to device tree setting → if deivce tree is correct, lsusb will show it again and start the usb device mode and flash data to external drive.

If you totally don’t know what I am talking about with that device tree setting, then it means you are most likely this case. This is software configuration and requires to match your usb hardware. Detail document over this link:
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=universal#porting-the-universal-serial-bus

[nagesh_accord]

@WayneWWW

Hi,

Please stop trying anything and just listen to the explanation first… your trying in hurry may just lead to waste of time.

1. The post to connect a usb device to bypass the flash error is just for Jetpack6 DP but not Jeptack6 GA. If you are using jeptack6 GA version, then that post has no value to refer to. Solution is already included…

Oh ok. thanks for the confirmation.

@WayneWWW

2. Initrd flash is like this flow:
   board enter recovery mode first (lsusb will show it) → host flash bootloader and initrd to the board → after flash is finished, recovery mode is finished. (lsusb gone) → bootloader tries to boot initrd → initrd will enable usb device mode according to device tree setting → if deivce tree is correct, lsusb will show it again and start the usb device mode and flash data to external drive.

Thanks for the deeper explanation of the USB mode entangled with the initird flashing.if you see the log file, I see this flow is happening properly and device tree settings are correct in the BSP downloaded version from nvidia website.

@WayneWWW

If you totally don’t know what I am talking about with that device tree setting, then it means you are most likely this case. This is software configuration and requires to match your usb hardware. Detail document over this link:
Jetson AGX Orin Platform Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide 1 documentation

This looks too complex with USB hardware internals. Why cannot nvidia provide fix this patch in there release itself?

Or is it like this varies depending on the carrier board design of routing the USB port accordingly?

[WayneWWW]

Yes, you finally get the point… it is related to carrier board in use for each user…

Hardware design leads to different software so actually this comment totally does not make any sense…

, I see this flow is happening properly and device tree settings are correct in the BSP downloaded version from nvidia website.

This is totally false. Most of custom board won’t work in usb part with default NVIDIA device tree…

[nagesh_accord]

@WayneWWW

This is totally false. Most of custom board won’t work in usb part with default NVIDIA device tree…

Ok fine.

Mean while could you please help me in pointing to the dts (device tree files) related to USB where I should be making the changes as per the carrier board customized connections for USB port .

Also parallely, I shall try to get the serial flash log also with help of hardware team.

[WayneWWW]

tegra234-p3768-0000.dtsi

[nagesh_accord]

@WayneWWW

If you totally don’t know what I am talking about with that device tree setting, then it means you are most likely this case. This is software configuration and requires to match your usb hardware. Detail document over this link:
Jetson AGX Orin Platform Adaptation and Bring-Up — NVIDIA Jetson Linux Developer Guide 1 documentation

This link refers to jetson AGX Orion series, where as for my Orion NX series, I should be referring to the below link, Hope I am right.

https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonOrinNxNanoSeries.html#porting-universal-serial-bus

[WayneWWW]

The usb device tree concept for Orin AGX and NX/Nano are totally same.

That is why only one document.

[nagesh_accord]

@WayneWWW

The usb device tree concept for Orin AGX and NX/Nano are totally same.

That is why only one document.

I see there are two types

1. Host port type
2. On the Go - OTG port type
   which one should we configure by updating the device tree for the same.
   I feel it should be On the Go Type as per my understanding.

a) what is your thoughts on this?

b) Also I observe some GPIO pins configuring involved under OTG device tree update. It might need pin muxing as well. PLease confirm if possible.

c) Also the OTG part for Orin NX series points to the same link as OTG part for Orion Nano. Hope its fine, as they both are similar when it comes to OTG type configuring