Unable to Flash R36 on Orin Nano 8GB Dev Kit Using External Storage

I believe I might be running into a very similar issue. I am trying to flash my Orin NX 16GB installed on an Orin Nano Dev Kit. I have an M2.2280 NVME drive installed on the longer PCIe C4 slot. The command I’m running 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/generic/cfg/flash_t234_qspi.xml" --showlogs --network usb0 jetson-orin-nano-devkit internal

and the log file of that invocation is provided here:
flash.log (294.4 KB)
I tried what WayneWWW suggested with plugging something into one of the USB A ports and got the following result:
flash-with-usb-drive-attached.log (356.0 KB)
And finally I tried what apa found success with by flashing in 2 steps:

$ sudo ./flash.sh -c bootloader/generic/cfg/flash_t234_qspi.xml --no-systemimg jetson-orin-nano-devkit-nvme internal
$ sudo ./flash.sh jetson-orin-nano-devkit-nvme internal

flash-no-systemimg.log (83.9 KB)
flash-final-step.log (90.1 KB)

And the board is flashed! Let me know if there’s anything you want me to test to get this working according to the Quick Start Guide. For now, would recommend changing the quick start guide to this solution until it’s fixed or you’ll probably have lots of people with the same issue.

I also had problems with flashing JetPack 6.0 to an Orin Nano 4GB from Ubuntu 22.04. I tried a lot of things including the ideas in this thread. Nothing worked.

Then I did a flash of JetPack 5.1.2. from an Ubuntu 20.04 machine. It was successful so I tried to flash JetPack 6.0 from the same Ubuntu 20.04 machine and it actually succeeded. So in my case Ubuntu 20.04 was the key to flashing JetPack 6.0 successfully

Hello,
I would like to report that R36.2 installation failed even with this method.

Environment:

  • Host: x86_64 Ubuntu22.04
  • Jetson: Orin Nano 8GB Developer Kit with NVMe SSD at C4 slot

As reported by others, the l4t_initrd_flash.sh command failed.
device side log is here:
capture_l4t_initrd_flash.txt (77.2 KB)

Also, the method proposed using `flash.sh’ was able to flash QSPI, but writing to NVMe did not complete due to a timeout due to erasing nvme.

[  12.8690 ] Erasing spi: 0 ......... [Done]
[ 203.8866 ] Writing partition secondary_gpt with gpt_secondary_3_0.bin [ 16896 bytes ]
[ 203.8870 ] [................................................] 100%

[ 204.1236 ] Erasing nvme: 4 ......... [Failed]
Error: Return value 8

device side log is here:
capture_nvme_failed.txt (57.8 KB)

I want these will be resolved in JetPack6.x GA.

please add this patch to Linux_for_Tegra/tools/kernel_flash/initrd_flash/nv_enable_remote.sh

This will bypass this error in initrd flash.

        echo "${cfg_str:1}" > "${cfg}/strings/0x409/configuration"

        + echo on > /sys/bus/usb/devices/usb2/power/control
        echo "${udc_dev}" > UDC

Thanks for your information.

I tried following your advice, but the installation failed at the same steps as before the change.
In particular, unlike with 35.4.1, the cooling fan also stops before and after Linux Kernel Boot, so it seems like it will overheat, so I turn off the power after 80 seconds.

initrd.log (9.4 KB)
capture_initrd_with_power_on.log (78.7 KB)

Hello,

I have the same issue as fumiya.fujinaka.

Environment : Ubuntu 20.04
Jetson: Orin NX 16GB NVMe SSD at C4

[  10.7130 ] Start flashing
[  10.7153 ] tegradevflash_v2 --pt flash.xml.bin --create
[  10.7167 ] Bootloader version 01.00.0000
[  10.7183 ] Erasing spi: 0 ......... [Done]
[ 177.7366 ] Writing partition secondary_gpt with gpt_secondary_3_0.bin [ 16896 bytes ]
[ 177.7369 ] [................................................] 100%

[ 177.9732 ] Erasing nvme: 4 ......... [Failed]
Error: Return value 8
Command tegradevflash_v2 --pt flash.xml.bin --create
Failed flashing generic.

Tried patching nv_enable_remote.sh with no success.

flash.sh logs:
flashsh-host-log.txt (79.6 KB)
flash-target-uart.txt (39.4 KB)

l4t_initrd_flash.sh fails also with the following logs :
flash-host-log.txt (272.2 KB)
flash-target-uart-log.txt (74.7 KB)

Thanks in advance

I’ve run into the error from the first post twice, once with the SDK manager trying to flash jetpack 6.0DP, and again later with a third-party script from Jetsonhacks to go back to 5.1.2. Both times the error was solved simply by inserting a microSD card, even though I continued to flash to the nvme already installed. Possibly coincidence but in a pinch it might be worth a shot if nothing else is working.

Hi,

If the echo on to usb2 power trick does not work, please try this patch to xudc driver which could be the potential official fix in next release. We are still reviewing it internally but mostly it won’t be changed.

diff --git a/drivers/usb/gadget/udc/tegra-xudc.c b/drivers/usb/gadget/udc/tegra-xudc.c
index dd89977..d7f55aa 100644
--- a/drivers/usb/gadget/udc/tegra-xudc.c
+++ b/drivers/usb/gadget/udc/tegra-xudc.c
@@ -3538,19 +3538,15 @@
 		}
 
 		/* Get USB3 phy */
-		usb3 = tegra_xusb_padctl_get_usb3_companion(xudc->padctl, i);
-		if (usb3 < 0)
-			continue;
-
-		snprintf(phy_name, sizeof(phy_name), "usb3-%d", usb3);
+		snprintf(phy_name, sizeof(phy_name), "usb3-%d", i);
 		xudc->usb3_phy[i] = devm_phy_optional_get(xudc->dev, phy_name);
 		if (IS_ERR(xudc->usb3_phy[i])) {
 			err = PTR_ERR(xudc->usb3_phy[i]);
 			dev_err_probe(xudc->dev, err,
-				      "failed to get usb3-%d PHY\n", usb3);
+				      "failed to get usb3-%d PHY\n", i);
 			goto clean_up;
 		} else if (xudc->usb3_phy[i])
-			dev_dbg(xudc->dev, "usb3-%d PHY registered", usb3);
+			dev_dbg(xudc->dev, "usb3-%d PHY registered", i);
 	}
 
 	return err;

Thanks for your advice.

Does that mean replacing Linux_for_Tegra/rootfs/usr/lib/modules/5.15.122-tegra/kernel/drivers/usb/gadget/udc/tegra-xudc.ko?
I tried that, but unfortunately the result was the same…

Are the fixes made so far to make the OTG port USB2-0 work?
Is it correct to understand that the reason why it cannot be installed using initrd is that the UDC settings on the Jetson side are not working as expected and are not visible from the HostPC?

Could you change the dev_dbg to dev_info and see if that log got printed?

Is it correct to understand that the reason why it cannot be installed using initrd is that the UDC settings on the Jetson side are not working as expected and are not visible from the HostPC?

Yes, your understanding to this issue is correct.

Thanks for your information.

I succeeded install R36.2.0 by l4t_initrd_flash.sh.
I can continue the installation by reconnect the USB cable, after USB Gadget was enabled.
It seems possible that the USB Gadget is operating in an incorrect USB device mode before it starts.

tegra-xudc.ko.tar.gz (330 KB)
succeeded_initrd.log (50.0 KB)
succeeded_capture_initrd_flash_usb_reconnect.txt (153.9 KB)
succeeded_hostpc_kernel.log (9.2 KB)

Details are below:
First, I prepared nv_enable_remote.sh with comments and sleep added to make it easier to see the progress.
nv_enable_remote.sh.txt (8.6 KB)
In particular, the process of searching for a UDC device seemed to be a waste of waiting time, so I changed the process to exit the loop once it is found, just like in R35.4.1.
This reduces the waiting time for ssh access.

for _ in $(seq 60); do
	echo "set_up_usb_device_mode: check UDC device"
-	udc_dev=3550000.usb
-	if [ ! -e "/sys/class/udc/${udc_dev}" ]; then
-		udc_dev=""
+	udc_dev_t186=3550000.usb
+	if [ -e "/sys/class/udc/${udc_dev_t186}" ]; then
+		udc_dev="${udc_dev_t186}"
		break
	fi
	sleep 1
done

Second, once “enable_remote_access()” completed, the USBGadget configuration looked fine to me.

bash-5.1# ip a
1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 48:b0:2d:ec:0c:84 brd ff:ff:ff:ff:ff:ff
3: usb0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether a2:d7:55:e6:88:52 brd ff:ff:ff:ff:ff:ff
    inet6 fc00:1:1::2/64 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 fe80::1/128 scope link tentative 
       valid_lft forever preferred_lft forever

At this time, a USB connection error message appeared on the host side before Jetson set the DeviceMode.
[25693.010687] usb usb4-port2: Cannot enable. Maybe the USB cable is bad?

Add /dev/nvme0n1
set_up_usb_device_mode: usb2 power on
set_up_usb_device_mode: link up
[    9.507981] usb0: HOST MAC 2a:c8:de:4d:56:fb
[    9.507986] usb0: MAC c6:ae:d2:dd:60:20
[    9.509612] tegra-xudc 3550000.usb: EP 0 (type: ctrl, dir: out) enabled
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
bash-5.1# 

<--- Reconnect USB cable here

[   16.595476] tegra-xudc 3550000.usb: EP 5 (type: intr, dir: in) enabled 

At this time, once I re-pointed the USB cable connected to OTG, the USB was recognized normally, RNDIS and MassStorage worked as expected, and the installation was completed.

Jan  6 18:40:49 um773l kernel: [25693.010687] usb usb4-port2: Cannot enable. Maybe the USB cable is bad?

<-- Reconnect USB cable here

Jan  6 18:41:12 um773l kernel: [25715.269457] usb 4-2: new SuperSpeed USB device number 9 using xhci_hcd
Jan  6 18:41:12 um773l kernel: [25715.290580] usb 4-2: New USB device found, idVendor=0955, idProduct=7020, bcdDevice= 0.02
Jan  6 18:41:12 um773l kernel: [25715.290588] usb 4-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jan  6 18:41:12 um773l kernel: [25715.290591] usb 4-2: Product: Linux for Tegra
Jan  6 18:41:12 um773l kernel: [25715.290594] usb 4-2: Manufacturer: NVIDIA
Jan  6 18:41:12 um773l kernel: [25715.290596] usb 4-2: SerialNumber: 1421623029227
Jan  6 18:41:12 um773l kernel: [25715.388878] rndis_host 4-2:1.0 usb0: register 'rndis_host' at usb-0000:34:00.4-2, RNDIS device, a2:04:ff:74:8f:76
Jan  6 18:41:12 um773l kernel: [25715.389573] cdc_acm 4-2:1.2: ttyACM0: USB ACM device
Jan  6 18:41:12 um773l kernel: [25715.390007] usb-storage 4-2:1.4: USB Mass Storage device detected
Jan  6 18:41:12 um773l kernel: [25715.390315] scsi host0: usb-storage 4-2:1.4
Jan  6 18:41:12 um773l kernel: [25715.410436] cdc_ncm 4-2:1.5: MAC-Address: 26:9a:a6:4a:8c:3e
Jan  6 18:41:12 um773l kernel: [25715.410733] cdc_ncm 4-2:1.5 usb1: register 'cdc_ncm' at usb-0000:34:00.4-2, CDC NCM, 26:9a:a6:4a:8c:3e
Jan  6 18:41:12 um773l kernel: [25715.419069] cdc_ncm 4-2:1.5 enx269aa64a8c3e: renamed from usb1
Jan  6 18:41:13 um773l kernel: [25716.406406] scsi 0:0:0:0: Direct-Access     Linux    File-Stor Gadget 0515 PQ: 0 ANSI: 2
Jan  6 18:41:13 um773l kernel: [25716.406965] sd 0:0:0:0: Attached scsi generic sg0 type 0
Jan  6 18:41:13 um773l kernel: [25716.407475] sd 0:0:0:0: Power-on or device reset occurred
Jan  6 18:41:13 um773l kernel: [25716.407753] sd 0:0:0:0: [sda] 32768 512-byte logical blocks: (16.8 MB/16.0 MiB)
Jan  6 18:41:13 um773l kernel: [25716.407881] sd 0:0:0:0: [sda] Write Protect is on
Jan  6 18:41:13 um773l kernel: [25716.407884] sd 0:0:0:0: [sda] Mode Sense: 0f 00 80 00
Jan  6 18:41:13 um773l kernel: [25716.408007] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Jan  6 18:41:13 um773l kernel: [25716.409083]  sda:
Jan  6 18:41:13 um773l kernel: [25716.409652] sd 0:0:0:0: [sda] Attached SCSI removable disk
Jan  6 18:43:33 um773l kernel: [25856.934448] usb 4-2: USB disconnect, device number 9
1 Like

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