Booting from SATA SSD on TX1 Dev Kit

Hi All,

I’ve followed the instructions for flashing the TX1 from an attached SATA SSD found in the documentation section here:

I’ve attached the SSD via SATA to the dev board and successfully flashed the target, but then the Terminal output states :

Make the target filesystem available to the device and reset the board to boot from external sda1.

What exactly needs to be done now?

Can I just ensure that the SSD automounts on reboot and then simply power cycle the TX1, or do I have to link the eMMC bootloader to the SSD somehow, or am I sidestepping the eMMC bootloader and booting from the SSD?
By “reset” the board does it require the reset button (rst) to be pressed?

The detailed instructions dry up at this point, so maybe something could be added to the next revision?

Question for extra credit…
Can I use the SSD, clone it and then use the image on other SSD’s for other TX1 units or do they all need to be set up one at a time ‘longhand’ as it were, i.e. following the same procedure I just have?

Thanks for any help!


It means that either the SATA drive on first partition was not formatted (such as ext4), or some other issue prevented the SATA drive from being found. Can you mount the SSD on a Linux host and see if it is able to mount the partition? If so, what is the output of “df -H -T /wherever/the/ssd/is/mounted”? If this does show up, does it look like the mount point has a Linux system on it?

FYI, if you get an image working, then clone is fine. You may need to use the tool though and not simply write the root partition if the image is from a different release than what is on the Jetson where the clone is going to.

Thanks for the response.

df on the disk from my ubuntu 16.04 host provides a filesystem of /dev/sda1 with ext4 format that automounts on the host at /media

Also looking through some other posts the next step that I thought of was that the extlinux.conf file should be altered but in the /boot directory there is only an /efi dir and no /extlinux dir. I’ll try to flash again and see if anything’s changed.

Re cloning, that’s good to know - I’ll probably end up setting them all up and flashing from the 16.04 host that I’m currently using.

What is the file system type of the /media mount? Is it ext4 (“df -T -H /media” while it is mounted)? The lack of extlinux dir implies you didn’t run the script (and should be done sudo). On a host you can specify an alternate location with the "-r " option, e.g., “sudo ./ /media”. I’m not where I can verify this, but that should be correct, though I suppose it might be the flash script itself which adds that directory. Either way you’d need the anyway.

Additional note I just thought about: The extlinux.conf (and the subdirectory) are not used on the SATA drive if you flashed to eMMC (which I recommend). Altering only the “root=” of eMMC to point at “/dev/sda1” leaves all boot loader operations on eMMC up until the point of handing off to the Linux kernel…it is at that moment the SATA drive becomes the root partition. It’s ok to not have files used by u-boot to be on eMMC instead of SATA. So your current setup may actually be correct, though you still need

Thanks for the quick response.

yep SSD is ext4 - both host and Tegra show this when mounted
Tried apply binaries from host onto ssd (but not yet from tegra to ssd booting from eMMC, which might work out better than the presently used method I guess?). Good tip about the alternate -r option… I might try that if I get time to play some more over the holidays. I have a sneaky suspicion that the apply binaries is writing to my host file system not the specified ssd…

Glad you recommend flashing the eMMC - as I figured that was a logical next step to try so had already done that and have then copied and sync’d the files created on my host as per the previously linked documentation from Nvidia to the ssd. I figured I could boot from the eMMC, add an alternate path for the ssd bootloader and test, so with that in mind I have added a section into extlinux.conf with label ssd as primary and pointing to rootfs on /dev/sda1 but I’m not sure how to check where the system is booting from; I suspect from the eMMC, as lsblk gives root mounted on the eMMC, and as you mentioned in your last post I would have guessed root would mount to the ssd if booted from there.

Do you know of a way of re-setting the eMMC and flashing the SSD as if it were the only onboard storage, ie instead of the eMMC and avoiding it completely, or are there files that must reside only on the eMMc due to the embedded nature of the build?

Thanks for the help!


Normally overlays onto the rootfs subdirectory. The "-r " is if you are using some sort of external media (such as an SSD or SD card).

So far as recommendations on where to flash to understand that there are basically three phases to boot. First the hardware starts up with Tegra-boot (t-boot), which then loads the u-boot binary; u-boot binary looks at environment and scripts (such as extlinux.conf) before handing off to the kernel for that last Linux stage. Should you have the boot loader binary and configuration environment on eMMC then you can point at any external or internal rootfs you want without having anything more than a rootfs on whichever partition is named. This is what happens if you flash to mmcblk0p1, the eMMC, then edit the eMMC extlinux.conf.

As soon as you flash to mmcblk1p1 (SD card) or anything other than mmcblk0p1 (eMMC) you start putting part of that boot loader content on another device. This means that device must be present to boot anything or you’re missing something in the u-boot stage. That external device suddenly contains more than just a rootfs. Suppose you want a different rootfs via just an extlinux.conf entry…you have to still have that same exact device connected or you are missing some of your environment. If you have only one SD card slot or only one SATA slot, then it is a bit inconvenient to put a second SD card or SATA device in…there just are not enough slots. Keep it all on eMMC and removing the normal external device leaves the original install as a kind of rescue option. It also means you can add whatever extlinux.conf entries you want naming different rootfs devices, and you just replace that device and it won’t care about anything other than having a correct Linux installation.