Hi, I’m thinking of buying a Jetson TX1 dev kit as a replacement for a Raspberry Pi 3, since I need more processing power for my visual odometry project. But, I see that the TX1 only has 16GB of storage, and I need more than that (for the OS, OpenCV and some other SDKs and libraries).
Can I connect a SSD to the TX1 and have it work as the primary hard drive, with the OS and and all the other libraries and packages that I need, installed on it? And just leave the 16GB eMMC storage empty? Is this complicated to do? Will it perhaps become inconvenient/cumbersome in some way, i. e. when installing new packages or so? What about the performance? Performance is quite important in my application, as I need to compute pose estimations of a stereo camera in real-time.
I’ve seen lots of posts about using SSDs as an external hard drive, but if someone could tell me whether or not it will be a problem to have a SSD as primary, that would be great!
Thanks.
I got it working…see [url]TX2 fails to boot without HDMI monitor with rootfs on SATA SSD - Jetson TX2 - NVIDIA Developer Forums.
It was not the ‘only primary drive’ as the early boot happens on MMC0, and kernel image is taken from there (u-boot in JetPack doesn’t support sata), but after Linux has booted, the rootfs is on the SSD.
As the title of the topic says, it fails to boot without a monitor, but it works fine so far with a monitor plugged in.
Some people name the external hard drive as rootfs (“/”). There are many partitions which are not part of the running system, but which are required for boot and must be on the eMMC (e.g., U-Boot itself, device tree, so on).
Installing to eMMC and then editing the boot configuration to redirect to a SATA drive is very easy to do (it’s a small edit in “/boot/extlinux/extlinux.conf” combined with a copy of the root file system over to the SATA drive). This has the advantage that you have a built in rescue system simply by choosing a different extlinux.conf entry via serial console at boot (you’d have a default entry, plus serial console can optionally pick other entries…the original eMMC system can stay there and be ignored simply by mounting SATA instead).
I don’t know if all SSDs can be used without an additional kernel module, e.g., some might need NVMe drivers if they are not detected as ordinary SATA and use a PCIe adapter. USB drives need to be kept in USB2 mode if they need to be detected by both U-Boot and Linux. You probably need to include more details (especially about the drive and how it will connect) because there are so many variations with different requirements.
I have not tried it yet, but I have considered putting only “/boot” (and the boot related partitions) in eMMC, and then having the rest supplied via lvm2 which I can move around and experiment with (my desktop system uses lvm for several partitions and makes a nice way to migrate from one release to another since I can dynamically increase/decrease what size partitions are). Early boot is different on an embedded system versus desktop Linux, but once Linux is in control there is very little difference between administration and setup of a desktop PC versus a Jetson.
I couldn’t tell you how good or bad performance would be this way…but the disk is almost always the slowest component even with a fast disk.
Note that during flash you name a flash target for the rootfs. The default and most common target is mmcblk0p1, the eMMC’s first partition. This is all you would need to boot to the SD card or a SATA drive if you do nothing more than edit extlinux.conf. You could name a boot target during flash of something like “/dev/sda1”, and the “/boot” files would be used from there instead of eMMC…but this still leaves many partitions on eMMC and removes the possibility of using the eMMC as a rescue system.