I’m trying to understand JetPack. What I would like to do is start from the l4t-base container and then assemble JetPack layer by layer. However, I can’t find or at least recognize the individual pieces anywhere. I’m willing to work from source but can’t find that either. My goal is to build more up-to-date containers than I can find anywhere else.
Hi Whichway,
JetPack SDK includes samples, documentation, and developer tools for both host computer and developer kit, we didn’t provide any source, and no plan to do.
Customers need to use it directly to do the device installation and develop environment setup.
For the flash part you just need the L4T “driver package” and “sample root filesystem”. If you flash through JetPack/SDKM, then it downloads and runs this for you. All other parts of JetPack/SDKM are designed around downloading and installing of optional content.
What exactly does “flash” mean here? I’ve never gotten it to work. For the development kit, does it actually write flash memory somewhere? I’ve only managed to boot from SD card.
sigh
Ok, now I’m trying the1.2.0.6738 version of SDKManager which this page
says works for any Jetson developer kit, using my Jetson Nano as target this time. (I’d rather not start from scratch again with my Xavier NX.) The SDKManager correctly detected my device, but won’t let me choose a target operating system despite listing all the JetPack 4.4 packages. This sort of thing keeps happening to me, which is why I abandoned SDKManager before.
Hi @Whichway,
If you are trying to use a personalized image where you can setup each piece of software and tools you need. I would recommend you give a try to meta-tegra layer. Which is a meta layer for Yocto.
You can find useful information here:
https://developer.ridgerun.com/wiki/index.php?title=Yocto_Support_for_NVIDIA_Jetson_Platforms
Regards,
Fabian
www.ridgerun.com
Flash is a subset of what JetPack/SDK Manager does. When flash is performed, this means the eMMC is erased and new content added. Many partitions will be added for boot, plus a root filesystem.
If you look at this list of releases of JetPack/SDKM you will find it also refers to the L4T release on the right side of each release (you have to go there, log in, then go there again):
https://developer.nvidia.com/embedded/jetpack-archive
If you then go to the L4T release belonging to that JetPack/SDKM release, then this is what is really being used to perform the flash step. Here is a list of various L4T releases:
https://developer.nvidia.com/linux-tegra
If you were to perform a flash manually, without using JetPack/SDKM, then you would download the driver package and unpack it as a regular user. This would produce a “Linux_for_Tegra/” subdirectory. Within that is a “rootfs/” subdirectory, and so you’d have “Linux_for_Tegra/rootfs/”. Mostly the “rootfs/” would be empty until you downloaded and unpacked the sample rootfs for the L4T release into the “rootfs/” directory (using sudo this time). This sample rootfs is purely Ubuntu and has no NVIDIA-specific drivers, and thus you’d complete setup by going to the “Linux_for_Tegra/” directory and running the command “sudo ./apply_binaries.sh”. With that in place you never have to set up for flash again and can flash as many times as you want from command line.
An actual flash requires the Jetson to be in recovery mode and connected to the host PC via the correct USB cable. Some of the flash commands change depending on whether this is an microSD card model versus eMMC model. Here is an example I used with a microSD version:
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk0p1
…which deletes everything already present, and adds boot partitions plus the rootfs after editing for boot content (basically it is the content of the “rootfs/”, except some boot options are edited). This is a complete flash.
Note that if you use a VM you can expect USB to not function correctly, it is the nature of a VM to not correctly handle USB when it disconnects and reconnects.
You could flash this way, and later run SDKM after unchecking flash in order to add optional packages. These always use ssh on a fully installed system and do not get added during flash. The system reboots after a flash, you finish the first boot account setup, and then you can add optional packages.