Tom,
It’s fixed with a different terminal program (i.e. screen), see output above.
Ron
Ron,
Yes, it is being detected just fine. So what’s different? Did you remove all other USB devices?
Have you tried booting from it?
Please do a ‘ls usb 0’ after ‘usb start’ to see if U-Boot can see the rootfs on that drive. If so, try ‘ls usb 0 /boot’ so we can see what’s in /boot on the rootfs.
Tom
I’ve just reset the Jetson and at first the ‘usb start’ gave no storage devices but when I executed ‘usb reset’ at the U-Boot it found the storage device?!
This is what’s in the /boot:
Tegra210 (P3450-0000) # ls usb 0 /boot
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 4096 dtb
<DIR> 4096 extlinux
<DIR> 4096 grub
34338824 Image
7159844 initrd
1010 tegra210-jetson-tx1-p2597-2180-a01-devkit-adafruit-sph0645lm4h.dtbo
2760 tegra210-jetson-tx1-p2597-2180-a01-devkit-fe-pi-audio.dtbo
3149 tegra210-jetson-tx1-p2597-2180-a01-devkit-hdr40.dtbo
2036 tegra210-jetson-tx1-p2597-2180-a01-devkit-respeaker-4-mic-array.dtbo
488413 tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
488942 tegra210-jetson-tx1-p2597-2180-a02-devkit-24x7.dtb
242880 tegra210-p3448-0000-p3449-0000-a00.dtb
1018 tegra210-p3448-0000-p3449-0000-a01-adafruit-sph0645lm4h.dtbo
2768 tegra210-p3448-0000-p3449-0000-a01-fe-pi-audio.dtbo
3313 tegra210-p3448-0000-p3449-0000-a01-hdr40.dtbo
3249 tegra210-p3448-0000-p3449-0000-a01-mcp251x.dtbo
2044 tegra210-p3448-0000-p3449-0000-a01-respeaker-4-mic-array.dtbo
242840 tegra210-p3448-0000-p3449-0000-a01.dtb
1054 tegra210-p3448-0000-p3449-0000-a02-adafruit-sph0645lm4h.dtbo
2804 tegra210-p3448-0000-p3449-0000-a02-fe-pi-audio.dtbo
3349 tegra210-p3448-0000-p3449-0000-a02-hdr40.dtbo
3305 tegra210-p3448-0000-p3449-0000-a02-mcp251x.dtbo
2080 tegra210-p3448-0000-p3449-0000-a02-respeaker-4-mic-array.dtbo
243342 tegra210-p3448-0000-p3449-0000-a02.dtb
243342 tegra210-p3448-0000-p3449-0000-b00.dtb
243324 tegra210-p3448-0002-p3449-0000-a02.dtb
243320 tegra210-p3448-0002-p3449-0000-b00.dtb
1010 tegra210-p3448-0003-p3542-0000-adafruit-sph0645lm4h.dtbo
2760 tegra210-p3448-0003-p3542-0000-fe-pi-audio.dtbo
3305 tegra210-p3448-0003-p3542-0000-hdr40.dtbo
2036 tegra210-p3448-0003-p3542-0000-respeaker-4-mic-array.dtbo
267216 tegra210-p3448-0003-p3542-0000.dtb
I’m actually able to boot now from the USB Drive but apparently there is something wrong with the roots as it doesn’t bring up the normal initialisation process for the Jetson?! I’m going to recreate the rootfs by copying it from the working SD-card.
Tom,
I think there is timing issue, it takes some time before the USB storage gets detected (see U-Boot commands below):
Register HCSParams1: 9000124 NbrPorts: 9
Starting the controller
USB XHCI 1.00
scanning bus xusb@70090000 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Tegra210 (P3450-0000) # usb reset
resetting 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
USB XHCI 1.00
scanning bus xusb@70090000 for devices... 3 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Tegra210 (P3450-0000) # usb reset
resetting 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
USB XHCI 1.00
scanning bus xusb@70090000 for devices... 4 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Tegra210 (P3450-0000) #
Thanks, Ron. It may be that the T5 SSD needs init/spin-up time before it comes ready … just guessing. I’ll try mine out later.
What I do when I want to boot an external (USB, NVMe) device is I fully boot via SD/eMMC, then just copy that fully initialized/installed rootfs/OS over while on the target (I think our docs say to do it on the host using the BSP rootfs). That way it should behave the same as if you’d booted from SD/eMMC, although you have to remember to tell the kernel (via the APPEND line in extlinux.conf ON THE EXTERNAL DEVICE) where to find the rootfs via the ‘root=/dev/sda1’, etc. kernel arg. On a fresh copy of extlinux.conf from the SD/eMMC rootfs, it’ll say ‘root=/dev/mmcblk0p1’, etc., so that needs to change when you copy /boot/extlinux/extlinux.conf to the external USB drive. I do believe that’s documented in our L4T docs.
Note: If you want a longer boot delay (for the T5) on your Nano, you can change the bootdelay env variable in U-Boot, and save it for subsequent boots:
printenv bootdelay ← s/b 2
setenv bootdelay 10 ← or whatever works for you, in seconds
saveenv ← saves the new env out to QSPI, so U-Boot will pick it up on next boot
Tom
1 Like
As I said in a just-added comment, it’s probably due to init/spin-up (on an SSD?) time on the Samsung T5. Please try some other non-SSD/non-HDD USB drives (flash drives) and see if it’s detected the first time.
If I find my T5 doing the same thing (never saw it during my testing), I’ll file a bug to have the XHCI driver add in some more delay.
Thanks,
Tom
Tom, USB flash drives (aka thumb drives) are immediately detected, but my Samsung T5 as well as an old WD HDD are not detected after a cold restart (power on). If I reset the Jetson (J44) then they are detected (already powered on) but not always/consistently.
The Nano now boots from my Samsung SSD, but I have to reset the device once or twice to make the USB Drive being detected. I will increase the bootdelay to see if I get a stable boot process.
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
USB XHCI 1.00
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 192.168.1.175 (6 ms)
*** Warning: no boot file name; using 'C0A801AF.img'
Using eth_rtl8169 device
TFTP from server 192.168.1.254; our IP address is 192.168.1.175
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 192.168.1.254; our IP address is 192.168.1.175
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 192.168.1.254; our IP address is 192.168.1.175
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
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.confon USB device to boot from/dev/sda1instead of/dev/mmcblk1.
(I tried with de UUID instead of/dev/sdabut 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 https://developer.nvidia.com/rpi-imx477-support-nano-2gb 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
Hi,
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
ssvemail1987,
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.
Tom