Hi All,
I have recently received Jetson Nano and Xavier SD card modules (not the design kit).
I cannot see any SD card associate with them. Can you please confirm how si the SD card to be associated with these modules ?
thanks
Hi Siddharthm,
The picture you pasted are both eMMC modules, they do not have SD card slot on it.
You need to buy the carrier board to make them working, please find the suitable one from:
Thanks for the reply,
can you please elaborate on what do you mean that "buy the carrier board to make it working " ?
The entire system is Jetson module + carrier board.
The standalone module you bought is eMMC SKU for production purpose, there is no any SD card slot on it.
So do you have any carrier board on hand? If not, you need to buy one.
If yes, you need to check if any SD card slot on it.
One thought is that one of the least expensive routes would be to buy a full Jetson Nano development kit. The dev kit module would use SD card, but the eMMC Nano or NX modules could probably be used on that carrier board (you’d have to flash the right software…the SD card and eMMC software differs in places).
EDIT: You may want to post further questions in the correct forum. This is the 32-bit TK1 forum, which is now in maintenance only. The 64-bit NX and Nano each have their own forums.
thanks for the reply , I already have procured the SOM and also developed the carrier board without a SD card slot.
Is the in-built EMMC not sufficient? I hope external SD card is not mandatory ?
The development kit units with SD do not have internal storage…that content all goes to SD card.
The modules with eMMC do not need SD. Some people have larger projects, and end up mounting a second disk or SD, but for most people eMMC is plenty. Certainly if we are talking about basic projects you’d have plenty of eMMC, but if for example you develop directly on the Jetson you might be including not just the end program, but also source code and models; binaries might be large from debug symbols. Perhaps speed is an issue too, and eMMC is faster than SD, but eMMC is still slower than an SSD. You should check the specs on the particular module.
IS there any way to install Jetpack without using L4T os.My Xavier nx den’t have a SD card slot too ,and the ubantu 18 04 is specifed by our customer
@sddhrth.bhargava: Since this is the TK1 forum, I am answering in that respect. However you mention the NX, and this really should be moved to the NX forum if that is the case. The TK1 is 32-bit, and the NX is 64-bit. I will still explain here anyway since much of this applies to both the NX and TK1 (the terminology part, e.g., what “L4T” is won’t change regardless of it being an NX or a TK1). The disadvantage is that you may end up reading a lot more than you wanted before getting to the NX part (I start with 32-bit of the TK1).
Some terminology definitions will help. First, JetPack is just an installer tool, and installs only to a host PC, and never installs to a Jetson. The sample root filesystem being installed is Ubuntu, but Ubuntu needs extra drivers if it is to use hardware accelerated functions. When the drivers are added to the stock Ubuntu, it is then called “Linux for Tegra” (“L4T”).
So if you want to you can install stock Ubuntu, but many parts of your Jetson will no longer function. If you install L4T, then you are actually installing Ubuntu with the drivers needed for full functionality.
When a Jetson is in recovery mode it becomes a custom USB device. Recovery mode does not in itself change anything on the Jetson in any permanent way. However, as a custom USB device, a driver is needed by the system which the custom USB device plugs in to. That software is known as the “driver package” (a.k.a., you would be installing the custom mode device’s driver when you add the driver package to a host PC). The driver package is what actually performs the flash, and the content flashed is from the Ubuntu o/s with the custom drivers for direct hardware acceleration.
JetPack is a front end to the driver package, and does not perform the actual flash. The driver package works from any ordinary Linux PC, but the JetPack GUI front end requires an Ubuntu Linux host PC. The TK1 was outdated and no longer supported at some point (32-bit no longer has active development), but later on, when 64-bit was being developed, the “SDK Manager” was created. The SDKM was more or less a more capable JetPack, and in fact could be considered a smarter network wrapper around JetPack. The two names are more or less interchangeable, but in reality you will always deal with JetPack on 32-bit platforms, but will instead deal with SDKM on 64-bit platforms.
One reason why the host PC needs to be Linux is due to the tools required to generate a filesystem. For example, under Windows, in the past there was no Windows Subsystem for Linux (“WSL”). Even after this was invented, WSL has no ability to use “loopback”, and loopback is part of the requirement for working on an ext4 filesystem generated within a file. Loopback can cover files and make them appear to be hard drives or hard drive partitions. WSL cannot handle that. There may be other reasons why WSL cannot handle this, but loopback is probably the most important.
During the days when a TK1 (32-bit) was still actively developed it the LTS version was 14.04. At some point L4T started using Ubuntu 16.04, but this did not initially exist for a TK1. I’m not sure if the R21.x ever had Ubuntu 16.04, but it was right around the time 64-bit was taking hold that the transition to 16.04 occurred. I doubt any of the R21.x releases had 16.04 unless it was from an intentional modification. If you have L4T, then you can tell the customer that in fact he/she does have Ubuntu. To say “L4T” is to say “Ubuntu with the correct drivers which Ubuntu does not ship by default”.
Note that you can easily use the driver package on command line for flashing. However, I did not yet mention that once the system is flashed and running JetPack/SDKM can also be used to install the optional packages, e.g., CUDA. In these earlier releases there was no support for directly installing those optional packages without JetPack/SDKM. There are tricks you can use if you are interested, and those involve looking at the “repository.json” file JetPack uses for downloading files. Basically the trick is to know that the individual “.deb” files can be downloaded to the Jetson, and if they are installed in the correct order (or simultaneously in a single command), then this will do the same thing as JetPack/SDKM would have done over ssh.
32-bit has never used an Ubuntu 18.04 host so far as the GUI JetPack front end is concerned. Command line flash from 18.04 works well.
32-bit has never had Ubuntu 18.04 available to be flashed onto the Jetson. Development stopped on 32-bit officially supporting only Ubuntu 14.04. There are some posts on how to update a TK1 to 16.04, but unless you do this correctly (with a learning curve), then you will lose direct hardware access (e.g., the GPU will not be accessible for OpenGL/OpenGLES/CUDA work). If your reference to requiring the Ubuntu release to be 18.04 is for host PC, then you can work on command line; however, if the reference to requiring Ubuntu 18.04 is for the TK1, then you won’t be able to do so (you could perhaps get 18.04 to boot, but likely this would be a bit of a mess, and it is guaranteed you would lose direct hardware access to the GPU).
The NX is 64-bit and the L4T releases created for this are all Ubuntu 18.04. All of the L4T R32.x are Ubuntu 18.04, but they also have the direct hardware access drivers. The version of JetPack/SDKM which runs on a host PC is in fact intended to run on an Ubuntu 18.04 host PC.
There are two models of the NX. One requires the SD card and boots from this. This is the module which arrives with a development kit. The other model uses eMMC and does not use an SD card for boot; this version is the separately purchased NX module which requires the end user to already have a carrier board. The development kits with revision a02, and the carrier board for an a02, are incompatible with the modules using revision b01. However, unless you had a very early release dev kit, then your dev kit will have a b01 revision. The b01 carrier board is compatible with both the SD card dev module of that release, and is also compatible with the b01 module which arrives with only eMMC.
Different carrier boards require a different device tree unless the carrier board has the same layout as the reference design of the b01 carrier board the dev kit uses. Even so, an eMMC module will also have differences versus a dev kit module (that difference is accounted for simply by flashing with the right identifier).
If you are working on a commercial product, then you will need to use a custom carrier board (although this could be an exact match to the reference carrier board). The dev kit carrier board and module are not intended for commercial resale, and there is no transfer of warranty to a third party when the original purchaser sells to someone else. The eMMC module does have a transferrable warranty.
All of this long description therefore ends with “if you have an eMMC model, then you don’t need an SD card”. The result will be an L4T release which is Ubuntu 18.04 will be installed to the Jetson for current releases (14.04 for older 32-bit releases), and is intended to be flashed from an Ubuntu 18.04 host PC (an earlier host PC Ubuntu is required for 32-bit systems being flashed).
thanks