Dear friends,
We have developed many AI models and Apps using Jetson XavierNX platform.
When open a new XavierNX box, it takes hours to get started jetson xavierNX devkit, download a lot of software and tools through WIFI.
We want to save time and make a XavierNX system image with all the requiremnet software and tools, and download with “Etcher” tool.
Pls kindly help to show us how to make the XavierNX system image
Thx a lot!!!
Others will need to comment, but some information is probably needed before the true meaning of “making a system image” can be correctly asked.
Every computer has a series of clocks and power rails which must be started in some particular order. Then some sort of “hook” needs to be created to give outside software a chance to take over. On a PC this would be the function of a BIOS, but Jetsons don’t have a BIOS.
Once that hook starts, this is when bootloaders can run. Bootloaders are in fact an operating system, but instead of running init (or some master program) its job is to run another operating system and overwrite itself.
Because Jetsons don’t have a BIOS (they do have the BPMP, or Boot Power Management Processor) with the right hooks, they cannot self-flash like a PC can (Jetsons also cannot be “bricked” like a PC with a bad BIOS). All of what that BIOS does for a PC is done with various partitions (some visible, some not) during normal flash. So flash in essence implies a simultaneous CMOS BIOS flash and bootloader flash and the actual operating system partition.
The software which is part of the “BIOS” functions and bootloader functions and initial Linux kernel to be loaded must all be compatible. A BIOS would provide a standardized API for access (on older systems it would be the API for legacy BIOS disk access, but is UEFI instead on newer systems), but the software on most embedded systems is not so standardized. Once you get to JetPack 5.x+ there is finally a UEFI boot stage (thankfully, this is rather nice). All of the software leading up to that UEFI is still custom, but once UEFI itself is loaded, the newer software does present a standardized API.
If any release version of the pre-bootloader software is incompatible with any part of the actual bootloader, or if it is incompatible with the boot content within the actual Linux o/s startup, you can expect boot to fail.
When you clone the rootfs partition, you are truly making a copy of the operating system. Provided all of that other content is compatible, then this is the only thing you would need to restore for either backup and restore or new system install. But only if that other content is the right release.
Most people, when backing up their PC, don’t expect to have a copy of the BIOS as well. The reason it doesn’t matter so much with a PC is that all of the boot software for a PC can reasonably expect a standard “non-customized” boot API hook. So then the questions are: How do we back up the equivalent of the BIOS and bootloader content in addition to the rootfs? Is it needed?
Any time you perform a full “normal” flash you are installing the equivalent of BIOS, bootloader, and operating system. The operating system will (by default) be from the sample rootfs. You can perform a fully flash, but “reuse the existing rootfs image”, and all of that equivalent to a BIOS and boot content will be flashed in addition to using whatever rootfs is there. A full flash using the same release which created the cloned rootfs is how you back up everything.
Normally, all of that “other” (non-rootfs) content is standard unless you’ve made some modification. If you have your own carrier board, then you probably have to put in a modified device tree, but otherwise the content is probably the same. One would add the device tree to the flash software (of the same release which created the original cloned rootfs). Then you’d be set.
On eMMC models those partitions would be visible on the eMMC. On SD card models, this would be on QSPI memory of the module, and you wouldn’t normally see that (during boot though it is treated as partitions). You don’t normally have the ability to directly clone and then restore that content, although command line flash does offer a chance to flash specific partitions.
Note that the non-rootfs partitions have to be signed to be accepted for boot. The default is a NULL key, so most people don’t ever notice this signing. It is there though, and partition content intended for various binary flash content will be slightly larger than the actual content due to the signature. You couldn’t just directly flash a binary partition without it first having the signature added.
Incidentally, if security fuses are burned, then some content which had been allowed to be in “/boot” of the rootfs will be rejected, and only partitions with the custom security fuse key will be accepted.
Note that there is a “--no-flash” option which can be used in command line flash to not erase the signed content. In a normal flash the content is signed, flashed, and then deleted. You can use “--no-flash” to create partition content which can be installed via the dd command on a running system (provided the signing is valid).
If you really want to see what is going on, then you should peform a command line flash, but log it, and then look at the log to see what comes from where. Example to flash with log:
# Case 1, generate a default rootfs:
sudo ./flash.sh jetson-agx-xavier-devkit mmcblk0p1 2>&1 | tee log_flash.txt
# Case 2, reusing a "bootloader/system.img":
sudo ./flash.sh -r jetson-agx-xavier-devkit mmcblk0p1 2>&1 | tee log_flash.txt
The shorter answer: Clone the rootfs, and make sure you know which release was used in creating that clone. Then flash with that release and that clone. Etcher won’t do the job except for the SD card of SD card models (eMMC models with an SD card slot are different, and don’t expect Etcher to work for that case).
Also, the content which I’m describing as “equivalent to a BIOS” typically cannot be added except when the Jetson is in recovery mode. A recovery mode Jetson is a custom USB device, and is not mass storage. One needs a custom USB driver to access this. JetPack/SDKM is a GUI front end to the actual flash software, and the flash software is called the “driver package” when installing it manually on the host PC. This is the driver which understands recovery mode Jetsons (Etcher has no such understanding).
Please note that once you’ve flashed you don’t have to keep downloading for each release unless you’ve deleted it or moved on to a new release.
Thank you very much!!!
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.