I can’t answer this, but you might find the following of use.
Not everything on the Jetson is from a package. When installing the flash software on the host PC (manually), it starts by unpacking a purely Ubuntu source. When the command “sudo ./apply_binaries.sh
” is run, much is added to that in the form of NVIDIA-specific content. This is almost the exact content that gets flashed by generating a loopback image of the rootfs (and there is a lot more than just rootfs).
If you were then to flash on command line, without JetPack, then the command might be something like this:
sudo ./flash.sh jetson-nano-devkit mmcblk1p1
(for an SD card model)
sudo ./flash.sh jetson-nano-emmc mmcblk0p1
(for an eMMC model)
The last parameter is about where to store the rootfs. The parameter before this is actually a reference to a “.conf
” file (e.g., 'jetson-nano-devkit.conf
). This is a series of files which will include other files, and some are specific to the module, while others are specific to the carrier board.
A side-effect of picking a target, and going through the series of files included (starting with the .conf
file of the flash target) is that just prior to generating the image which will get flashed board-specific and boot-specific content will get copied into the rootfs.
Examples of content which is copied in just prior to image generation is the kernel Image
and device trees. Very closely related to this, the actual “boot/extlinux/extlinux.conf
”. This latter file specifies things like the kernel, initrd (if used), and device tree (the FDT
entry).
Normally the extlinux.conf
will state where to get the device tree, including its name, but there are exceptions. To talk about exceptions one has to know something about whether this is a dev kit or if this is an eMMC module on a third party carrier board.
For dev kits there is no eMMC. All of the content which boot and the equivalent of a BIOS goes into QSPI memory on the module itself. In the case of an eMMC model, this normally goes to partitions in the eMMC (remember that .conf
file? this specifies some of this).
Note that non-rootfs content also contains a device tree. When you specify a board target through that .conf
file there will be a device tree file named somewhere in the chain of included configuration. For an eMMC model there will be a device tree in both the /boot
and in a partition as binary content.
Everything placed in a non-rootfs partition of an eMMC model is signed before going into that partition. This is all binary content which can be read without understanding any filesystem type. If the content does not have a valid signature, then that content will be refused. However, a default eMMC model does not have the security fuses burned, which means the signature is a NULL signature. The QSPI content of an SD card dev kit model does not use this fuse mechanism, so talking about a signature is kind of pointless in QSPI, but know that QSPI also have the equivalent of the binary partitions of eMMC (but it is in QSPI memory, not eMMC).
Any time the extlinux.conf
sees the FDT
entry, then this is normally the highest priority, and that file will be used. Changed the extlinux.conf
? You just likely changed the FDT
entry. If that entry does not exist, or if the entry names something that is not valid, then device tree reverts to the partition or QSPI content, depending on model. The same is true for more parameters, e.g., the kernel Image
file is named in extlinux.conf
, and this is how a kernel is normally found; if no entry exists, or if the entry is invalid, then search reverts to the binary content of the partition or QSPI (if it exists). If the security fuses of an eMMC model are burned, then only the partition content is allowed even if extlinux.conf
names files that are otherwise valid.
Perhaps your extlinux.conf
changed, and only an update to the boot entry which is default is needed; the FDT
might just need to name a different file. Perhaps there is no entry, and boot has reverted to a binary partition. Perhaps this is an eMMC model and security fuses were burned, and you only changed content in the rootfs without updating binary partitions.
If you really want to see what is going on you must get a full serial console boot log. This log shows what goes on during boot stages as well as the content of the dmesg
from when the Linux kernel loads. You need to see what happens for device tree content before Linux ever starts (the bootloader is its own bare metal operating system and uses devices that are not plug-n-play, so the bootloader needs to know how to find those devices and what specifications/arguments to use). Knowing this wouldn’t change what is used, but you could understand where the device tree is initially loading from (device trees have many nodes, some might be added later on in boot).
Note that a normal flash uses default non-rootfs content. If you’ve cloned an eMMC Jetson, and you put your clone in to replace the generated content, and then flash to tell it to reuse the existing (cloned) image, all content is flashed, but the non-rootfs content is standardized (think of this flashing the BIOS…which a Jetson does not have…but that it is very rare that someone wants modified boot content). If that content is at least partially from a package, then your upgrade might have altered this. Boot content is possibly modified for a custom carrier board even if it is only in the device tree or the specification of which device tree to use.