JetPack 4.5 Production Release with L4T 32.5

I’ve increased the bootdelay to 10 seconds but that doesn’t help for a boot from power on. The most successful approach is to reset (J44) the Nano once it hangs during boot (it’s actually trying BOOTP after it doesn’t find any boot device). A reset after power on appears to be the most reliable way, but this is of course not something you want. There must be something else that causes this behaviour in the USB driver stack?!

MMC: no card present
Card did not respond to voltage select!
starting USB...
Bus usb@7d000000: tegrausb: Invalid dr_mode 2 for host mode
probe failed, error -1
Bus xusb@70090000: 
Firmware size 124416
Firmware timestamp: 0x5da88fc3, Version: 50.25 release

Register HCSParams1: 9000124 NbrPorts: 9
Starting the controller
scanning bus xusb@70090000 for devices... 8 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: unknown device

Device 0: unknown device

Warning: eth_rtl8169 using MAC address from ROM
BOOTP broadcast 1
DHCP client bound to address (6 ms)
*** Warning: no boot file name; using 'C0A801AF.img'
Using eth_rtl8169 device
TFTP from server; our IP address is
Filename 'C0A801AF.img'.
Load address: 0x84000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-00-04-4b-e5-01-96
Using eth_rtl8169 device
TFTP from server; our IP address is
Filename 'pxelinux.cfg/01-00-04-4b-e5-01-96'.
Load address: 0x90100000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/C0A801AF
Using eth_rtl8169 device
TFTP from server; our IP address is
Filename 'pxelinux.cfg/C0A801AF'.
Load address: 0x90100000
Loading: T T T T T T T T T

The hard reset (J44) not always renders the desired result. Sometimes multiple resets are required, but I found that when I get to the U-Boot prompt and perform a ‘usb reset’ it immediately detects the USB drive. So maybe a strategy similar to the retries on BOOTP could be implemented to search for USB devices before handing it off to BOOTP?

Tom, I did some additional testing and the problem appears to be buried a little bit deeper (see postings in this thread). The real effective way is to execute ‘usb reset’ in U-Boot.

Thanks, Ron.

I have no problem with any of my USB devices during bootup on my Nano B00 and Nano2GB boards, even those that aren’t flash drives (T5, etc.). I’ll try to do some more testing.

Note that ‘usb reset’ is just ‘usb stop’ followed by ‘usb start’. ‘usb stop’ does do a ‘usb_stop_keyboard’. So please try testing w/nothing but the USB storage device plugged in to your Nano, let’s see if the mouse/keyboard might be causing delays/etc. that affect the storage device detection. I’ll test the same here.

This is the first time for our XHCI driver in T210 U-Boot, so while it went thru extensive QA before the R32.5 release, we’re probably still going to find some corner cases that will need WARs and/or updates to the driver stack in the next release. Thanks for helping with real-world testing!


Tom, no problem. I will do some additional testing later today and let you know the results.

I updated to L4T32.5 and JP4.5 without a problem but I have a question:

If I clone the SD-card and put it into another (older, e.g. rev. a2) development board, is the board updated automatically (bootloader? flash?) or do I have to do additional steps on each hardware device? What commands? The documentation is not easy to understand here… Thanks.

1 Like

Thanks, that worked.
What I did:

  • Create GPT partition table on USB device with only one ext4 partition with the label “APP” (the docs suggest so, but it’s probably not significant)
  • Clone the mounted and running system to the USB device (method suggested by the Arch Wiki):
    $ sudo e2image -ra -p /dev/mmcblk1 /dev/sda1 -f
  • Edit /boot/extlinux/extlinux.conf on USB device to boot from /dev/sda1 instead of /dev/mmcblk1.
    (I tried with de UUID instead of /dev/sda but it didn’t work, maybe I wrote it incorrectly).


I had that problem without a powered USB hub. Keyboard was the issue. Big honking model M clone.

We released a tar ball today containing support for IMX477 on Jetson Nano 2GB Developer Kit for JetPack 4.5. Please download the tar ball from and follow the README inside.

@Lars-EK , on the first boot during OEM-Config, the QSPI on your older rev a.2 will be automatically updated. But if you have cloned the SD_Card after making it boot (and hence finishing OEM-Config) on another Jetson Nano Develper Kit, then OEM-Config will not run again and hence QSPI wont be updated. So to update the QSPI you need to boot with a fresh SD Card image.

Thank you. But isn’t there a command to start this update / OEM-Config manually? To clone a fresh image only for the first boot for every device is a lot of overhead…

1 Like

Will the driver work when loading jetson from usb ssd. Or will still refer to mmcblk0p1.

After reboot with
LABEL primary
MENU LABEL primary kernel
LINUX /boot/arducam/Image
INITRD /boot/initrd
APPEND ${cbootargs} quiet root=/dev/sda1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0

FDT /boot/arducam/tegra210-p3448-0000-p3449-0000-b00-imx477.dtb


Those changes to extlinux.conf you list need to be made on the extlinux.conf on the USB ‘SSD’, not the SD rootfs. Looks like your terminal spew is saying that the kernel can’t find the rootfs on mmcblk0p1, which is SD-card. After cloning your SD-card rootfs to USB or NVME, you need to edit the extlinux.conf on that external media rootfs and change the root=/dev/mmcblk0p1 to /dev/, whether it’s /dev/sda1, or a PARTUUID, etc. That way the kernel can find the appropriate rootfs on boot.


No, it’s begining after install drivers imx477. This extlinux.conf from ssd usd kingston 60gb

Before install it booting good. Its screnn boot after adding FDT /boot/arducam/tegra210-p3448-0000-p3449-0000-b00-imx477.dtb

@WayneWWW should chime in here, but I believe the recently released IMX477 support package was meant to have the DTB flashed to the target in place of the current kernel/BL DTB, not loaded via U-Boot using FDT in extlinux.conf. That support (FDT load from disk) is in flux, as we’ve found that some recompiled/modified kernel DTBs can cause a phandle conflict with the internal DTB that CBoot/U-Boot have modified during HW probe, and possibly cause system instability. We’re looking into using DTB overlays (DTBO) as a possible solution. But for now, unless the changes are small and don’t involve phandle re-ordering by the DTC, I think loading of a kernel DTB via FDT in extlinux.conf should be de-emphasized until I can fix this in U-Boot.


1 Like

Note that I’d still like to see your entire boot log, @ssvemail1987. The kernel cmd line will show the root= arg, which if you are booting from USB s/b root=/dev/sda1, or the PARTUUID of your USB device.

Hmm, actually I would suggest @ssvemail1987 could file a separate topic for your own issue.

This thread seems has many kinds of topics. Maybe a separate one can help us focus on your issue.

Is there a simple guide on how to permanently switch over the boot from the SD card to an M.2 SSD inserted on the M.2 port of the Jetson Xavier NX?

I’ve been using the rootOnNVME hack from JetsonHacks for this up till now, but that still relies on the MicroSD card for it’s initial boot before it switches over to the M.2 SSD.

And as I experienced yesterday, updating to a new JetPack OTA with a system configured this way leads to a mess.

I had to reflash the SD card with the JetPack 4.5 image and go through the whole setup procedure again (including the rootOnNVME hack) to get back to my working setup.

There has to be a more stable way to do this though.

Any simple instructions out there to achieve this?

Hello, please tell has Python upgrade happen? Python still python 3.6.9?