Bootloader or fullimage flashing failed

hello team,

please help on this flashing issue, sometime it works, sometimes not.
one time we used this command to flash nvme and bootloader together and it was succfull,

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 jetson-orin-nano-devkit internal

now are unable to falsh:
we are unabble to flash bootloader full image to orin nano 8GB production SOM with custom carrier board,

i have attached the logsfrom both device and host side.

we tried these two commands.

  1. initrd: Waiting for device to expose ssh …Run command: flash on fc00:1:1:0::2
sudo ./tools/kernel_flash/l4t_initrd_flash.sh -p "-c bootloader/generic/cfg/flash_t234_qspi.xml" --showlogs jetson-orin-nano-devkit nvme0n1p1
  1. flash.sh is getting failed : E> NV3P_SERVER: Failed to initialize partition table from GPT.
 sudo ./flash.sh --no-systemimg -c bootloader/generic/cfg/flash_t234_qspi.xml jetson-orin-nano-devkit internal

Please still use this one and check your serial console log and host side log. Need to share two logs together. Also, we need full log.

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 jetson-orin-nano-devkit internal

Hello Wayne,

sorry we missed to attach the logs in prev chat,

i have the tried the command u shared again
and getting the same error,

host_initrd_flash_cmd_fail.txt (255.0 KB)
device_console_logs2.txt (81.1 KB)
please find the logs,

please suggest us the solution.

When the board get into initrd state, are you able to see it in lsusb command on your host PC?

yes, lsusb i can read Nvidia pid and vid

Are same host pc and same custom board able to work fine when it is on jetpack5?

no we have not used jetpack, we are working with 36.2, and same carrier was working fine initially.

Not sure if this is some known issue on rel-36.2 which is still a developer preview.

What I saw is ssh based on the usb device interface somehow cannot launch.

Do you have NV devkit to validate if your host really can ssh to jetson through usb interface?

currently we dont hav edevkit rightnow. anu other options to make sure that ssh works?

What is the result of these commands on your host when issue happened?

ip a
lsusb

Hi Wayne,

when issue happens, this is output for the commands u asked to check for,

user123@Legion-Y9000P:~$ lsusb
Bus 002 Device 003: ID 8564:4000 Transcend Information, Inc. microSD/SD/CF UHS-II Card Reader [RDF8, RDF9]
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 048d:c105 Integrated Technology Express, Inc. ITE Device(8910)
Bus 001 Device 012: ID 0955:7035 NVIDIA Corp. Linux for Tegra
Bus 001 Device 010: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 004: ID 8087:0033 Intel Corp. 
Bus 001 Device 003: ID 174f:246a Syntek Integrated Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
user123@Legion-Y9000P:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp12s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether fc:5c:ee:5b:56:0b brd ff:ff:ff:ff:ff:ff
3: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 60:45:2e:15:58:24 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.111/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp0s20f3
       valid_lft 5417sec preferred_lft 5417sec
    inet6 fe80::9df:33a9:4924:9f50/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: enxc693f1030657: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether c6:93:f1:03:06:57 brd ff:ff:ff:ff:ff:ff
    inet6 fc00:1:1::1/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::c493:f1ff:fe03:657/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::2/128 scope link 
       valid_lft forever preferred_lft forever
user123@Legion-Y9000P:~$ 

Looks like usb deivce mode node does not launch on your host side.

If your custom board modify anything to the usb device mode port, then you need to modify device tree to make it work.

Default device tree is a type C setting for Orin Nano devkit. If your port is not using type C, then must change configuration.

Hi Wayne,

FYI:
same boards were flashed successfully flashed in another host PC, here any hostside driver to be installed to support type c device.

when we put it in reset mode, we are able to see the VID and PID of orin nano

Bus 001 Device 012: ID 0955:7035 NVIDIA Corp. Linux for Tegra

Hi,

Recovery mode does not matter to what we are talking about. Recovery mode and usb device mode are different things.

Then could you move to another host PC and confirm your statement that this issue is host related?

unfortunately Currently we are in different location, where we can’t use that old Host PC which i was using flash, so any suggestions to fix this flashing issue in the same PC which i am using now,?

please let us know what is the USB device mode port, how can i confirm you that the device is detected properly in usb device mode port.

Hi,

Could you try more times with initrd flash command and see if it fails in the same error everytime?

hi,
we have tried around 10 times as of now, still seeing the same issue.

Hi,

I mean I want to be more specific here. Do you always see the error as this one?

Waiting for device to expose ssh …Run command: flash on fc00:1:1:0::2
SSH is not ready

Hi,

yeah, we always see the same error, w.r.t ssh, as i shared in the logs in previous msgs.

Ok. Could you really get any other ubuntu host PC to test this too? Need to clarify whether this is host side missing items issue or Jetson side.

For example, does this host PC ever ssh to other device through ipv6 before?