As a pure novice, it is the first time to contact the products of jetson series. How should I learn and understand the use and performance of jetson xaiver nx? Or are there any learning videos or materials you can learn?
Someone else can provide more information, but here I’ll try to say something useful (even if not complete).
First, every Jetson runs Linux. When you add NVIDIA drivers to Ubuntu, which is what gets flashed, it is then called “Linux for Tegra” (it is a Tegra SoC). You can find the L4T release on a Jetson with “head -n 1 /etc/nv_tegra_release”. You can then go to documentation for your specific release here:
https://developer.nvidia.com/linux-tegra
The Xavier can run the most recent L4T release R35.x.
JetPack is installer software which runs on a correct Ubuntu release of a desktop PC. This comes with SDK Manager. SDKM is a “smart” network layer on top of JetPack, and so you would run JetPack by running SDKM. Example, if your host PC has this installed (run only as a regular user):
sdkmanager
The JetPack/SDKM release tends to be tied to the L4T release. Most of the time specifying the JP release also specifies the L4T release, but JetPack can work with other releases (versus most recent) if started like this:
sdkmanager --archived-versions
Unfortunately, JetPack tends to require specific versions of Ubuntu on a host PC, depending on the L4T release it is flashing. I would advise Ubuntu 20.04 for installing L4T R35.x VMs have been known to work, but you will have a learning curve ahead of you if you choose to do so. Often the USB is lost, and it is up to the VM config (which NVIDIA has no knowledge of) to keep USB connected during the disconnect/reconnect which occurs during a flash.
A general documentation location is here, and you can select to pay attention to only Xavier or Xavier NX:
https://developer.nvidia.com/embedded/downloads
Just about anything you know and learn for Linux applies to a Jetson. L4T R35.x corresponds to Ubuntu 20.04, and so researching anything on Ubuntu 20.04 is likely very good information.
The GPU on desktop PCs will normally be a discrete GPU on the PCI bus (a “dGPU”). Jetsons have their GPU integrated directly to the memory controller (an “iGPU”). This means the Jetson shares memory between GPU and system, which in itself is not all that different to work with. However, detecting the iGPU is different when compared to a dGPU. You will often find software specifically tailored to the Jetson for anything AI or GPU/CUDA for this reason. If you use some of the example code, then you will find out how it detects. If you use code intended for a dGPU, then likely the software won’t know a GPU is present.
If you compile code, then this will be arm64/aarch64 architecture.
Most documentation for kernel compile is designed for cross compile on the host PC, but native compile works too if you have enough disk space. Official docs on actual installation of a kernel or kernel module tends to show how to modify the flash software and then flash. This is definitely not needed if your Jetson is already set up how you want it; there are simpler instructions you can ask about here if you want to install a new kernel and/or module (try to stick to kernel modules if you can, it will simplify your life if you need new drivers). Kernel source for a given L4T release is a package within another source package for that L4T release page.
Booting a Jetson is quite different compared to a PC. Any time you go to modify something in boot you should first research it or ask about it on these forums. It isn’t until Orin that you get to a mainline kernel (L4T R35.x and earlier have kernel source distributed by NVIDIA).
Just to reiterate, there is example code which you can optionally install via JetPack. Regarding how JetPack and flash works, Jetsons need to be in “recovery mode” to flash them. Recovery mode in and of itself does not modify a Jetson, but it does turn them into a custom USB device understood only by the custom USB driver, which is installed with JetPack/SDKM (the name of the component within this is appropriately named the “driver package”). When flash completes, the Jetson will then automatically reboot. It is at this point you will be asked to complete first boot setup by adding an admin account (default accounts are a legal issue with California, and so you don’t get default accounts anymore). Once login to that account is possible, JetPack will ask for that information and install optional content over ssh. This means (A) the Jetson is fully up and running, no longer in recovery mode, and (B) you can log in normally to the Jetson.
It isn’t obvious, but JetPack has options which can be enabled or disabled. Installing sample software for example, or CUDA, can be unchecked. You might want to uncheck installing software to the host PC during initial install, and then only later running JetPack to install optional content like examples. You just have to remember to uncheck the flashing step, and to keep the Jetson fully booted instead of in recovery mode.
The pins for recovery mode basically require shorting the recovery pin to ground. Then add power or reset power. This is like the shift key on a keyboard when entering a capital letter: You don’t need to hold it on for any significant time, just short the pin, power up or power cycle, and let go of the pin.
The flashing part of USB (the specific connector) is capable of emulating a network router when fully booted (but not when in recovery mode). Your host PC will often create a network route to the Jetson, and so you don’t necessarily have to have Ethernet connected for ssh. When this is up the Jetson has address 192.158.55.1, which is what JetPack uses as its default address. The host PC will have address 192.168.55.100. Either system can ping either address as a test.
Depending on hardware, there will be a serial console connection available. On some models it is a micro-USB connector, and on others it will literally be two pins plus ground. This is for a serial UART running a 3.3V level. You can look up a “USB serial UART” with the 3.3V level on Amazon or somewhere else, and your host PC can talk to the Jetson over this UART even when much of the system has crashed and burned. No monitor is needed for this, no network is needed, and this provides information even during boot stages before Linux ever loads. This is a cheap device, roughly a $10 to $20 range, and will save you much grief and effort if you have one of these available at all times. You might or might not need one, but I strongly suggest everyone have that serial USB UART cable.
Jetson modules have many pins with optional function. There is firmware which determines what function to use. Specifically, this is the device tree. You will see many mentions of this in various forum threads. If your Jetson is an NVIDIA development board, then the NVIDIA flash software is just what you need (including device tree). There are times you might end up editing a device tree to change the function of something, e.g., maybe the 40-pin header has some option you want to change.
If you have a Jetson module on a third party carrier board, then the only time Jetson flash software from NVIDIA will work is if the manufacturer states that this carrier board uses NVIDIA’s default flash software. In other cases you might be told to add a patch to the NVIDIA software, which is mostly a device tree edit. In some cases a third party carrier board manufacturer will have their own flash software (in which case it is mostly a rebranded NVIDIA flash software with edits to the device tree). If you have a third party carrier board, then the specific L4T release software might not be entirely correct, although differences are likely only the device tree and documentation.
You can find a lot of useful information from JetsonHacks:
https://jetsonhacks.com/
Also, you can go to YouTube and search for “nvidia jetson”.
I tend to install htop to monitor CPU:
sudo apt update
sudo apt-get install htop
There is a builtin application called tegrastats to see the GPU activity. Just run “tegrastats” on command line.
If you choose to boot to an external device, for example an NVMe or SSD, then you will need special flash instructions (remember how I said the boot chain is different and non-standard for Jetsons?). This is an initrd flash, which you can ask about on the forums. If you natively compile kernels, then you will need more space. It is easy to add external storage to some specific location, e.g., to “/usr/local” or to mount “/home” on it. The latter does not require special flashing procedures, but making an external boot device your rootfs does.
On the host PC, when you install JetPack/SDKM, you will have (in your regular user’s directory) “~/nvidia/nvidia_sdk/”. There will then be another subdirectory named for the release, e.g., something of the format “JetPack_...version...XAVIER.../”. Within that is the “Linux_for_Tegra/” directory. This directory is where you go to do almost everything “flash related” from the host PC. If you use JetPack by running sdkmanger, then you don’t need to worry about that. However, you will find a lot of times you need to know to go to “Linux_for_Tegra/”, and that is where you find it.
During flash the host PC will generate an entire “raw” partition for the Jetson’s rootfs. There will also be a “sparse” partition generated. The raw partition is the size of the entire partition. If it is a 50 GB partition, then your host PC will use 50 GB for that one file. The sparse version is the same as the raw version, but it does not contain empty space. If your raw partition has 3 GB of content, then the sparse partition will be close to 3 GB. As the raw partition size fills, the sparse size approaches the raw size.
You can do a lot of customization inside of “Linux_for_Tegra/rootfs/”. Other than some boot content this is the source of generating the image that gets flashed to the Jetson. You could for example use a method to complete first boot account setup into “rootfs/” and this user would always be there upon flash without going through that again. You can also update the Jetson, and then use tools like rsync to update the “rootfs/” of the install software; from then on each flash would have that update. This is why you need to know that the sparse image grows with content inside of the flash image. Just don’t expect to put a modified kernel or boot content directly into “rootfs/”; this content changes each flash and so you need to add such content in a different manner if you choose to do so (most people won’t do so unless they are a business mass flashing).
Incidentally, the GUI requires a monitor with actual HDMI or DisplayPort. VGA adapters tend to not work. HDMI and DisplayPort have a wired (the “DDC” wire) which provides monitor specs to the GPU for setting up the monitor, and VGA does not. There was a late effort in VGA that some do provide that data, but it is of a release version that Jetsons do not seem to be compatible with, and so even VGA adapters saying they are compatible with a DDC wire do not actually work (the original data is EDID, the current format is EDID2; rarely does anyone specifically call it EDID2, but this is in fact what we are speaking of if we are discussing monitors or debugging monitor failures). A desktop PC has the ability to work with monitors that don’t have EDID data; Jetsons do not. The best a Jetson can do if the EDID is invalid is to go to a default mode and hope the monitor understands it.
3 Likes
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.