Easiest way to install and run Jetpack from a USB disk

Soon I will be creating a video comparing my best budget ARM Linux devices: the Jetson Nano, the RPi 4 and an Amlogic based TV box, the X96 Air Q1000.

One of the aspects of the Nano that will be criticised, unless I am enlightened otherwise, is the difficulty involved in installing and running Jetpack from a USB disk. On both the RPi 4 and the X96 Air, I can simply dd the OS onto a USB disk, plug it in and it will boot, pretty much. You may have to edit one line in a boot config file.

Whilst I have used quicker methods to boot off a USB disk previously (which also required I still have my MicroSD inserted for the initial stage of the boot process) they were regarded as hacks and my current understanding is that this guide covers the steps required to do a proper USB installation of Jetpack:

That’s a significant amount of work to do for what must be a frequently desired config. It is not a good introduction to the platform.

Is there no quicker, easier method? Ideally NVIDIA would provide USB ready installation images, if only for those who have already done the necessary firmware update first.

I cannot answer this (I don’t have a USB disk to try to work with), but some information you might find of interest follows…

JetPack (and SDK Manager) is actually a front end. The software flashed is Ubuntu, and since it has NVIDIA direct hardware access drivers, it can also be referred to as “Linux for Tegra” (“L4T”).

There are roughly two categories of Jetsons: Those which run entirely on an SD card, versus those which have internal eMMC.

You will notice a lot of partitions, but only one of which is the root filesystem. Embedded systems do not have a BIOS, and as such, part of that content is equivalent to the CMOS BIOS, but entirely in software. The rest of those partitions are dedicated to boot (imagine if every desktop PC required flashing a custom BIOS too…life would get much more complicated in the PC world, but hardware would use less power and cost less).

With the SD card models all of this content is on the SD card.

With the eMMC (commercial) modules, some of that content which is sort of “equivalent to BIOS” must be on the QSPI internal storage (imagine if someone wanted to flash the BIOS of a PC to the USB device; to some extent this is what people ask for when wanting all content on an external device…this isn’t just the bootloader). Aside from doing things like bringing up power rails and clocks in the correct order, this also hands off to any bootloader stages, e.g., CBoot (which might in turn hand off to U-Boot). About the only way to set up this content on the eMMC model is via flashing in recovery mode.

SD card models are free to do a lot more so far as flexibility in boot device, but you might (not sure) still find some of that “equivalent to BIOS” content needing to be on the SD card (I have not checked…it depends on whether the internal module hardware knows to look at alternate boot devices, but I have no way to answer about this internal content which exists even without a flash).

Regardless, you will find no eMMC model can put content entirely on non-eMMC devices, and any change to any pointers of the first boot device probably has to be flashed in place. Again, I do not know what restrictions might be for a purely SD card model…maybe it can boot straight to the USB disk, but I don’t know.

Part of the reason for using flash software is that some content in the non-rootfs partition has to be signed. SD card models don’t have a burnable security fuse (a.k.a., a “key” which is normally NULL, but which can be burned to some secret key so only you can flash), eMMC models do. Even if the key is NULL (for cases where non-rootfs partitions are signed) the partitions still must be signed. So writing a partition (other than APP/rootfs) typically means using the flash software to generate the partitions.

Most of this came about due to needs for secure boot or trusted boot environments. Earlier L4T releases did not have that functionality, and thus no partitions were signed. The content installed via the JetPack 3.x or earlier (L4T R28.x or earlier) did not have this signing mechanism. Content from JetPack 4.x or newer (L4T R32.x or newer) is when this secure boot environment development really took off, and it has been one of the faster changing developments across each new release. It was already stated that there is a new release scheduled for roughly the end of July, and I couldn’t tell you what is in that next release, but there is likely a lot changing regarding making it easier to work with that boot environment. Perhaps this complication will improve in that release…will have to wait to see.

Sorry, as mentioned earlier, I do not test USB external boot devices, so I can’t be any more specific (I simply do not know).

In terms of an RPi, this device was designed and marketed from the start for hobbyists and those who want to experiment. Jetsons and Tegra development in general was, in the past, entirely intended for large commercial developers, with the devices originally intended to be only a reference design. Users were expected to learn from this in order to build their own carrier boards and software. The first GPU-based Tegra (the TK1) was so successful that instead of building custom boards for it, people began to use this directly (such as hobbyist, not just large commercial companies). Over the years I’ve seen what I think of as migrating more and more towards a directly usable solution for hobbyists, but the history and current development still seems to be somewhat geared towards commercial companies building their own hardware, and treating the dev kit models as a reference design. While I see each release a bit friendlier towards the average hobbyist I also see roots in providing a reference rather than a final end solution…it is evolving.

FYI, dev kits have a non-transferable warranty. eMMC models are intended for commercial use with resale and transfer of warranty, but don’t come with a carrier board.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.