Orin NX flash fail >> Waiting for SSH times out

Hi,

I am trying to flash an Orin NX module but during flashing it times out in the state of waiting for SSH connection.

We developed a custom base bord compatible with Xavier NX and Orin NX, the Xavier works just fine in our bord but the flashing of the Orin gives some problems.

The script hangs in the following state:


  •                                 *
    
  • Step 3: Start the flashing process *
  •                                 *
    

Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for target to boot-up…
Waiting for device to expose ssh …RTNETLINK answers: File exists
RTNETLINK answers: File exists
Waiting for device to expose ssh …Timeout
Cleaning up…

Our host system is an Ubuntu 18.04 device (not a virtual machine).
Below are the logs of the Host and the debug console output of the Jetson Orin module.

Our base bord uses a 128GB NVME disk for booting (i have seen a configuration file for a 512GB NVME flash disk (which is referenced via the flash command, but i dont know if i need to change/edit this file.

My flash command is the following:
sudo ./tools/kernel_flash/l4t_initrd_flash.sh --external-device nvme0n1p1 -c tools/kernel_flash/flash_l4t_external.xml -p “-c bootloader/t186ref/cfg/flash_t234_qspi.xml” --showlogs --network usb0 p3509-a02+p3767-0000 internal

I did modify the ‘l4t_initrd_flash_internal.sh’ with the edit of “flash_only=1”.

If you require more debugging information please let me know.

Ubuntu host l4t_inittrd_flash log (6.9 KB)
Jetson debug console log.txt (75.5 KB)

Hoping you can help,

Kind regards,

Koen.

Hi, can you first try if you can burn your Orin NX without the flash-only tag?
With the tag, you are burning your Orin NX using the image intended to be used on Xavier NX, which is likely to cause an error.

Hi DaveYYY,

I also tried to run the default script, sadly with the same result (before i set this flag to 1), it hangs after the first SSH exposure.
I thought the “flash_only=1”. flag is used whenever you need to flash the existing image build. so it won’t rebuild but just re-flash the module (lets say you have to flash multiple units, this way every unit will get the same image flashed) or is my perception of this flag wrong?

I set this flash to 1 because of some HW tests which i thought where producing problems and this saved time.

The image flasher seems to fail after the first SSH exposure (according to the host debug output), so i think the initial SSH seems to work but i can’t think of a reason why a secondary SSH link is necessary/why this wouldn’t work.
Is the secondary exposure somehow different to the first (e.g. different ports used or something)?

Hi, do you have a reference carrier board for Xavier NX (P3509)?
Not sure if your problem is related to the carrier board, but if it still happens on our official DevKit, it may be easier for us to reproduce the issue.
Also, can you elaborate more about “it hangs after the first SSH exposure”?
Please attach the log without the flash_only option.

Is it also based on rel-35.3.1?

Are you able to see the usb interface in your host side ifconfig when device enters initrd?

Hi WayneWWW,

At what stage in the flashing enters the device initrd, is this when the flashing script enters this


Step 2: Boot the device with flash initrd image


or is this when the device is booted and remains in the SSH exposure loop:

Waiting for target to boot-up…
Waiting for device to expose ssh …RTNETLINK answers: File exists
RTNETLINK answers: File exists

This is all very new to me so forgive my ignorance.

Hi,

I just checked, it seems not possible to validate this. Please just ignore my comment.

Please check with Dave’s question first if you have XNX devkit or Orin Nano devkit to validate this first.

Hi DaveYYY, WayneWWW,

An update, adfter you request for flashing with flash_only=0 the flashing is successfull, i think it is working now because
we modified the eeprom disabling (see below). I dit this yesterday and thought that running ./apply_binaries also processed these changes.
So yesterday i tried flashing with the flash_only=1 after running ./apply_binaries for image rebuilding (i thought), but now i retried the whole script with
flash_only=0 and it flashed correctly.

It is currently running (but we don’t have an HDMI output, we can access the Orin via serial communication)

Answers to your question DaveYYY
Our HW board is based around the “P3509-A01” Xavier NX board. (! Without the EEPROM !).

Currently the source for the “Sample Root filesystem” and “Driver package (BSP)” is the rel-35.2.1
from this link:

We modified/removed the EEPROM following this documentation:
https://docs.nvidia.com/jetson/archives/r35.3.1/DeveloperGuide/text/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>

When the Orin enters Recovery mode the host machine lsusb command show the following output:
Bus 001 device 007: ID 0955:7323 Nvidia Corp. APX

During the flashing the Orin presented the USB port as
Bus 001 device 007: ID 0955:7035 Nvidia Corp. Linux for Tegra

And was visible indeed via ifconfig (as usb0).

A new question regarding the currently running OS:
Does the sample Root file system and Driver package have an HDMI output or is this a non GUI build?

Hi, glad to see your issue get solved.
But please file a new topic if you have questions other than the original one.

1 Like

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