We are starting an Autonomous Vehicles class at my school. They purchased everything needed for me to gain some experience before the class starts next year and I am struggling mightly. I followed some of the tutorial videos on jetsonhacks.com and I need to undo some of the things. How can I get the Jetson TX1 to stop trying to boot to a USB drive? Also I try to flash the Jetson and there are errors. I am not sure because the host computer is on a secured wifi and the Jetson is on a guest wifi with no security. I really need some help. Anything would be appreciated.
This is long, but you’ll probably find this of use since you are preparing for a class based on the Jetson.
When the U-Boot boot loader runs it has a series of boot devices listed in environment variables, and it tries them one at a time until it succeeds. You need a serial console cable if you want to interactively explore the U-Boot command line…this would be very useful for what you are asking, plus serial console is a major benefit if you ever have a system issue (serial console is very simple and works even when much of the system is crashed and burning).
For info on serial console see:
During boot serial console will show boot loader info prior to ever reaching Linux kernel load. Very quickly in you will see “Hit any key to stop autoboot”…I think you have about 1 or 2 seconds to hit any key and go to an interactive prompt. If you then type “boot” boot will continue. Type “help” to see a list of commands. In particular, note the “printenv” command. Typically a serial console will allow you to log and save for later use, or just scroll back and see what all of the enviornment variables show.
In your case take note of “bootcmd”. This is the order of execution of macros when you run “boot”. In particular view what “distro_bootcmd” expands to. This reads (in a loop) environment variable “boot_targets”…this is the order of boot target check. The default is this:
boot_targets=mmc1 mmc0 usb0 pxe dhcp
The boot environment allows you to edit “boot_targets” and boot with this as a temporary change, or else to save environment and keep a change. This can remove USB boot target, though I doubt this is what you really want.
mmc1 is SD card, mmc0 is built in internal eMMC, pxe and dhcp are network boot protocols. The fact that it didn’t stop on mmc1 means you don’t have an SD card; so then mmc0 (eMMC) was texted and did not have a valid boot setup, and it went on to search for USB. Either your flash left out the sample rootfs or the sample rootfs was truncated (no “/boot/extlinux/extlinux.conf” was found)…reflashing should fix the issue, but you need to be careful about having enough disk space on the host and making sure the sample rootfs was correctly unpacked (if you do this on command line it implies using sudo). If manually flashing on command line the flash.sh script would also need to be run sudo.
In the driver package directory (if using JetPack then this is downloaded and unpacked automatically) there is directory “Linux_for_Tegra”. This is the logic for talking to a recovery mode Jetson. A subdirectory within this is is “rootfs”…this is the key to what actually gets put on your Jetson as a root partition. If flashing manually you would use sudo and unpack the sample rootfs there.
The parent to “rootfs” directory (the “Linux_for_Tegra” directory) has “apply_binaries.sh” in it. This must be run sudo as well (JetPack takes care of this if not doing manual command line install). The sample rootfs is purely Ubuntu, apply_binaries.sh adds/overlays NVIDIA-specific hardware accelerated access files on top of rootfs…this is when it goes from being purely Ubuntu to becoming “Linux for Tegra” (L4T). Once this is in place you can flash.
During flash a blank file the size of the entire file system is created. If you told the system to use 14GB on the Jetson root, then your host must have space to create this 14GB blank file (which then gets populated mainly with the rootfs directory plus boot edits). This is compressed (known as a sparse file) and adds requirements for about another 3GB of host disk space. This is finally sent to the Jetson. With all the temporary files and other things going on I’d suggest your host have about 25GB of free space before starting to flash. Your existing “raw” and “sparse” flash files are in “Linux_for_Tegra/bootloader/system.img” and “Linux_for_Tegra/bootloader/system.img.raw” (raw is uncompressed). These get deleted each time you flash so if they already exist then your disk space doesn’t need to be 25GB free.
Run “df -H -T” in the Linux_for_Tegra directory. It should be a native Linux file system type, e.g., ext4, and should have about 25GB free.
Some more recent host versions (perhaps Ubuntu 16.04, I’m not sure) also put some 64-bit extensions in the ext4 filesystem type which U-Boot does not understand (U-Boot is still 32-bit)…if this is the case then you need to do an edit, else all of the above steps done correctly will still cause the eMMC partition to not be readable. If you did everything right and flash seemed to work but it still looks for USB see this:
WiFi connection is not supported during flashing JetPack. You should connect your Jetson to the host PC via ethernet cable, not WiFi. You can connect the ethernet cable directly between the two NICs or you can connect them via router (however not with WiFi). After flashing successfully and allowing JetPack to complete the post-install steps, your USB behavior should be reset and back to normal.
Ohhh…I missed that :P WiFi!