TX1 Boot from USB

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX1
1

Hi,

I am trying to boot the Tegra X1 from USB, I have the USB drive in USB1 according to the Jetson board, I followed the instructions on the guide, basically:

But when the board is booting I get:

USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found

USB device 0: unknown device
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-tegra210
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
No ethernet found.

Then I ran:

Tegra210 (P2371-2180) # usb reset
resetting USB…
USB0: USB EHCI 1.10
scanning bus 0 for devices… 1 USB Device(s) found
scanning usb for storage devices… 0 Storage Device(s) found
scanning usb for ethernet devices… 0 Ethernet Device(s) found
Tegra210 (P2371-2180) # usb start
Tegra210 (P2371-2180) # usb dev 0

USB device 0: unknown device
Tegra210 (P2371-2180) # usb dev 1

USB device 1: unknown device
Tegra210 (P2371-2180) # usb dev 2

USB device 2: unknown device
Tegra210 (P2371-2180) # usb dev 3

USB device 3: unknown device

It will report 1 USB device even if the USB drive is not connected(likely an internal hub?), do you have an idea what could be wrong?

Thanks

2

So I suppose the problem is that the USB port is not enabled when uboot is running because it needs to load the firmware that is on the file system as mentioned in [1]. Is there any other way to do it?

[1] https://devtalk.nvidia.com/default/topic/916095/jetson-tx1/a-debian-experience/post/4804151/#4804151

3

I don’t have a real answer. What it comes down to is that while u-boot runs, u-boot must have built in ability to use the USB port. To read any hard drive on the port, u-boot must also support USB mass storage devices. Once a mass storage device class is available, the partition scheme must be supported within u-boot…think old style BIOS partitions or GPT partitions. Once a partition is readable via support directly in u-boot, then the ext4 file system must be readable to use extlinux.conf.

I believe u-boot has USB support prior to the kernel loading. U-boot obviously has the ability to read GPT partitions and to mount and read ext4 file systems. What I do not know is if mass storage class is supported within u-boot.

Once u-boot hands off to the kernel, the kernel has those same requirements. U-boot was responsible for placing the kernel image in memory, but now u-boot is gone and it is up to the kernel.

The kernel has to have USB support, the USB support must include mass storage class, the partition scheme must be supported, and ext4 file system type supported. The chicken-and-the-egg dilemma occurs if something in that chain of support for the kernel requires something on the media to be read which is not yet loaded. Non-module features of a kernel will always be there…thus if all of those features are built into the kernel as a non-module, then the kernel will have met all of those requirements. Should something be in the form of a module, and if that module is required for any other requirement prior to the module loading, then the chain of requirements is broken. The initrd is a way of making all of those modules available in a “fake” file system containing the required modules, and after the real file system loads, the initrd will be thrown away.

Should the support requirements for u-boot not be met, then u-boot will have to have its source adjusted. Should the requirements for the kernel not be met because of a chicken-and-the-egg dilemma, then an initrd will do the job.

Alternately, should the issue be a kernel module chicken-and-the-egg dilemma, the kernel can be recompiled with those features integrated directly into the kernel, versus as a module. An initrd is a way of avoiding modifying the kernel configuration and sticking with the original module layout. Beware that there are size limits to how much initrd and module space can exist, so keep these to the minimum that can be required.

The log files you posted tend to indicate that u-boot was the failure stage, and that u-boot has at least a minimal EHCI USB driver. It seems that USB mass storage class support does not exist in u-boot, else the device would have been visible.