Naively modify the extlinx.conf as following will not boot TX1 from USB drive:
TIMEOUT 30
DEFAULT usb
MENU TITLE p2371-2180 eMMC boot options
LABEL usb
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/sda1 rw rootwait
LABEL emmc
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait
And actually I see that my USB drive may not be connecting to TX1 on reboot for the fact that my drive has light on it and on reboot, it is not flashing at all.
Anyone could provide any assistance on this? Thanks!
I don’t actually have a USB drive I can wipe out at the moment to test, but I do have a drive such that I can determine it “should” work. Two things need to be kept in mind.
First, there must be a continuity of service for the USB driver when transitioning from U-Boot to Linux. USB must be available continuously, and must not be reset part way into boot. This means that the USB port must remain USB2 at all times, both before and after boot (U-Boot does not have a driver for USB3…if Linux resets from USB2 and becomes USB3 you will lose the drive as the new controller enumerates).
Second, the extlinux.conf you want to modify is the one on eMMC, not the one on the USB drive. Most of the time. If you flashed and named something other than mmcblk0p1 on the flash command line, then this changes…but this is probably not what you really want unless you’ve succeeded already and have tested (and only then would you want to disable eMMC with a flash target other than mmcblk0p1).
Do you have serial console? Without this you can’t work in the U-Boot command line.
Within U-Boot command line you will want to see what happens when you issue the command “usb start”. Once this succeeds you can continue with the “boot” command. Try with both USB ports…they use different controllers. If that port shows as USB3 during normal operation without the drive, then that port won’t work. If you connect the drive to the booted system and run “lsusb -t” for tree view you will see “480M” on the right side for devices in USB2 mode, and “5000M” for devices in USB3 mode. You can set it up so a USB3 port only uses USB2.
I see your point that it is safer to use USB2 port with USB2 drive as always.
And yes, I am editing the extlinux.conf on the eMMC.
Could you firstly give me any suggestions on how to retrieve the extlinx.conf to the original version every time I failed to boot successfully from my USB2 drive? I am guessing there is a way to edit the extlinux.conf on eMMC when the booting fails. I am asking about this because I absolutely don’t want to flash my TX1 over and over again, this takes a lot of time.
If you have serial console you should be able to add alternate entries without removing the original boot entry. For example, one of the first things I do when I get a new L4T version to flash is to save a clone of the old version, and then edit the new extlinux.conf to add an SD card boot version as a rescue disk.
Assuming you don’t have an alternate entry, is it correct to assume you have a serial console set up? If you interrupt boot early on in serial console you can get to the U-Boot command line. If you run command “printenv” you will see a number of “boot_” variables. The command to continue boot is just “boot”, and this expands a series of variables. I’m thinking editing variables will do what you want, but before I go into detail, what is your current setup? Did you leave the original kernel and device tree in place? What change did you make to extlinux.conf?
Some parts of extlinux.conf still work. What it comes down to is that part of the environment (and kernel boot arguments) are now in U-Boot and not directly in extlinux.conf. The “root=…” should be valid in extlinux.conf. If you want to see the final result of edits you have to check the content of “/proc/cmdline” after boot, or else catch it being echoed to serial console.
I do not currently have a USB drive I can wipe out to try with. If you have a serial console boot log though it might help (without serial console you won’t be able to select optional boot entries and will end up flashing to change boot if a boot config fails…with serial console you pick any entry, and go back to original simply by picking it). Did it still boot from eMMC? Or did USB boot fail by halting?
Thank you so much for your reply. I mean it after I editing /pro/cmdline on the TX2 and reboot, it simply does boot from the flash drive and on the screen the output says something like: “Waiting for /dev/sda”. That happens.
I am wondering whether I could find a step by step tutorial that I can follow, without using a serial console.
This is just probably something I’m not clear about, but FYI, “/proc/cmdline” is purely a reflection of how the kernel saw its command line during boot…it can’t be edited without a reboot creating a new cmdline. I suspect you meant you didn’t see the change you wanted in cmdline, or edited something to try to get that change.
A serial console should be considered mandatory for working on new boot configurations where testing is needed…at least if you want to preserve some of your own sanity. It’s so much simpler and quicker versus flashing.
Whenever U-Boot stops at “Waiting for /dev/” odds are high that “” either does not have the file system type it wants or something is interfering with reading that file system.
One easily corrected way this can happen without any fault from how you did the install is if your host PC uses 64-bit extensions to format the sda1 device. On your host look at file “/etc/mke2fs.conf”. In the ext4 section of this file see if either of these are present:
metadata_csum
64bit
If those are present, then you know why boot failed…Linux works great with those, but U-Boot does not. Do you see 64-bit extensions on your host PC?
I understand we are using flash.sh in JetPack, while Does that mean I have to put jetson-tx1 if I am booting from TX? What does mmcblk1p1 mean exactly?
mmcblk0 on a Jetson is the eMMC. mmcblk1 on a Jetson is the SD card. mmcblk1p1 is the first partition of the SD card.
The “mmcblk#” may change depending on how many flash devices you have, e.g., perhaps you are looking at the device on another host. On my PC host, due to my adapter, it is “/dev/sdg1” for the first partition…YMMV.