I have successfully managed to get the initrd flash script to flash the NVMe drive of a Jetson Xavier NX and I would now like to flash SDK components from my host machine to the Jetson in a similar fashion to SDK manager. Does anybody know where the script that SDK manager uses for this is?
FYI, SDKM can have other installation content unchecked, and just add the optional content. For example, you can uncheck flash and uncheck install to host PC, but tell it to install CUDA to the Jetson. For this case the Jetson must be fully booted and not in recovery mode. It then just uses ssh for installation.
Optional content is not actually in the original flash image. The flash image is only the base content. The normal Ubuntu “apt” command works for installing from an Ubuntu remote repository, or the “dpkg” command works for local “.deb” file installation (and apt can work with a local file too).
What content are you considering? It is easy to copy files to a Jetson with scp from a host PC. Or to log in remotely from a PC to a Jetson (or even log in locally) and run apt-get commands.
Thank you for your response, I’m looking to flash an image with a custom kernel + dtb and then mimic the rest of what SDK manager can install (Jetson Runtime Components & SDK Components) via command line without having to redownload all the files on each Jetson I flash.
From what you’re suggesting and from my research so far, what I could do is download nvidia-jetpack to my host if I set the correct sources, copy those .deb files over with scp using the ip 192.168.55.1 and then just use dpkg to install them on the target machine. Is this the same thing that Nvidia are doing in SDKmanager?
I am going to describe some of the customization for the Jetson itself, since it is related. However, adding components to the host PC is simply a matter of running sdkmanager as a regular user (it’ll ask for your sudo password though) and unchecking other steps. It isn’t always obvious that things like flash or install of optional components to the Jetson itself can be unchecked. So just use sdkmanager to install to host PC after unchecking steps you don’t want. Everything else which follows describes the process of what gets put into a Jetson when flashing. Nothing more than this first paragraph is needed to add components to the host PC.
The official documents with each release describes how to add a kernel or device tree to the flash software should you want an actual flash to use a custom kernel and/or device tree from the very start. This is done on the host PC, but there are other possibilities as well. I’ll describe some of the install process so as to give you an idea of possibilities.
A Jetson normally has a partition with the device tree (although it is signed), and a partition with the kernel (which is also signed; if security fuses are not burned, then it is still signed, but the key is a NULL test key). If the “/boot” content named in the “/boot/extlinux/extlinux.conf” does not name a specific file in the “/boot” content for a device tree (the FDT entry, see extlinux.conf), then the partition version is used (the FDT entry has priority in most cases). If the “/boot” content named in extlinux.conf does not name a kernel (the LINUX entry), then the partition is used for the kernel. Thus, depending on configuration, the kernel Image file might be in a partition or a separate file in “/boot”; similar for device tree. The exception is that if security fuses are burned, then only signed partitions are allowed.
During a normal flash the “Linux_for_Tegra/rootfs/” content is the basis for creating the rootfs (APP label) partition. “Mostly” the “rootfs/” content on the host PC is an exact copy of what goes into the partition, but arguments passed to the flash software will modify parts of this related to boot.
Just before creating the actual partition binary image the kernel, device tree, and extlinux.conf are written into “rootfs/boot/”. The chosen kernel and device tree and extlinux.conf depend on the arguments passed to the flash software. As an example of a command line flash (this is direct use of the “driver package”, which is the actual flash software; JetPack/SDK Manager is just a GUI front end to that), depending on model (I’ll pretend it is an Xavier NX dev kit), a command line flash might look like this from the “Linux_for_Tegra/” directory of the host PC (which JetPack/SDKM would install…that directory is actually the “driver package”):
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk1p1
The jetson-xavier-nx-devkit specifies the hardware being flashed, while mmcblk1p1 specifies a pointer to where boot goes for rootfs. You’ll find in that same directory some “*.conf” files, including “jetson-xavier-nx-devkit.conf”, which are human readable, and which have specifications related to what kernel and device tree are copied into “rootfs/boot/” prior to creating a rootfs image. The mmcblk1p1 says boot is intended to use the SD card of a dev kit (if it were an eMMC model, then you’d use mmcblk0p1, and boot sequence would instead point to eMMC). Note that where boot points is actually two steps. The first part is a pointer of where to look for configuration (how to find the extlinux.conf file), and the second part is what edits to make to the extlinux.conf prior to copy into “rootfs/boot/extlinux/extlinux.conf” (edits might mirror other settings).
Note that if you were to use the above command to flash on command line that you could log the flash and examine directly what files are copied from where (but the official documentation also explains customization). If you wanted to install your own kernel, and if you were to replace the source of that copy, then every flash would use that kernel if you passed the same arguments to the flash software. Similar for the device tree file and and extlinux.conf file. An example to log that same command:
sudo ./flash.sh jetson-xavier-nx-devkit mmcblk1p1 2>&1 | tee log_flash.txt
Also, note that jetson-xavier-nx-devkit corresponds to jetson-xavier-nx-devkit.conf, and this in turn will refer to other files. Often they are just symbolic links to a file which refers to a specific Jetson module or a file which corresponds to a specific carrier board. The end product of .conf files included in this will be a combination of module and carrier board designations. For example, the file jetson-xavier-nx-devkit.conf is a symbolic link to “p3509-0000+p3668-0000-qspi-sd.conf”. This is convenient since if you were to copy the chain of .conf files to a customized copy of that file with a new name, then you could add your kernel and device tree specifications and then you’d get the kernel Image and device tree you want by specifying the custom target (less the “.conf” suffix of the file).
Do keep in mind that specifying the target of eMMC will directly populate eMMC on those models, but specifying other targets (such as an SD card on an SD card model) may require you to flash those separately (but the image created from the above would be valid).
Also, there is a file “Linux_for_Tegra/tools/kernel_flash/README_initrd_flash.txt” you should read for cases of flashing in certain cases of flashing to external devices (like an NVMe). You can think of an initrd as an adapter between the boot software and transfer of control to the correct device when you are not using eMMC (and not using the SD card of a dev kit SD card model).
Note that except for the “rootfs/boot/” content you see in the flash logs, all of the rest of the rootfs/ content is a verbatim copy of what goes into the Jetson. You could add a home directory and user and that would then exist at each flash (see the “tools/l4t_create_default_user.sh” script which does exactly this via the QEMU emulator). If you were to model your own script after the l4t_create_default_user.sh script, and edit this, you could do other things, e.g., use dpkg commands to add packages, or perhaps use apt-get to update, so on (the emulator is because the host PC is separate from the rootfs/ content, and that content is also a different architecture).
You would not be able to directly modify JetPack/SDK Manager to do any of this. The description above will allow you to modify the command line flash software and customize, or else to customize the content of the rootfs/APP partition.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.