About eMMC: The Nano and NX format developer kits do not have eMMC. The SD card slot is on the module itself, and not on the carrier board. The full sized TX1 (or any of the full-sized models) have eMMC. Third party modules sold separately are all eMMC models, and none have an SD card slot on the module (any such slot is on the carrier board, and thus firmware and boot is quite different between the two models). SD card models don’t have obvious extra partitions, at least not with tools for looking at ordinary disk partitions. SD card models do have QSPI memory on the module itself, and this is where bootloaders and other “partition-like” content goes on those models. If I mention signing of a partition below, for SD card models, just assume I’m talking about content in QSPI memory.
Something which I am curious about (excerpt of above):
[0002.871] Loading kernel from LNX
...
[0003.205] Failed to validate boot-image
First, it is loading from a partition. Second, the partition being loaded appears to be incorrectly signed.
The reason I find this of interest is that this is not a bootloader issue at this point. There are two ways some content can be loaded: (A) from “/boot” if extlinux.conf specifies such content, and if the content can be found; or (B), from a partition (QSPI in SD card models) if either “A” fails for any reason, or if no extlinux.conf specifies this content. A shorter way of saying this is that valid /boot content takes priority over partition content, but some conditions revert to partition content. For whatever reason we are using partition content and the /boot content cannot be used. Sometimes the content in /boot simply isn’t specified, and sometimes something goes wrong (at this point it doesn’t matter why, but we know we are using partition content).
When a Jetson is flashed, and when those partitions are created (or QSPI if an SD card model), they are signed. The default is a NULL key signing, but it is still signed. In the case of eMMC models there is also a security fuse which can be burned (with a key), in which case the content being flashed to a partition is signed exactly like default content, except that it uses the key used to burn the security fuses (SD card models don’t have the ability to burn those fuses, they only have the NULL key signature).
What I am wondering about is this: Have you ever put anything in a partition with any method other than the flash in recovery mode via a host PC? For example, if dd was used, this won’t honor signing unless you know to use the signing tools first. We don’t have to worry about security fuses since dev kits which are SD card models don’t have fuses which can be burned (they are permanently set to use a NULL key), but the method of adding content to non-rootfs partitions (rootfs is the only unsigned partition) still matters. Either the content you have was not signed, or it was corrupted in some way.
Unless you have a reason for it you could try flashing the Nano without the SD card in it, and just replace all of the content other than the operating system (which is on rootfs, and this in turn is on the SD card of an SD card model dev kit).
If you have the flash software installed on the host PC, then you’ll have the “~/nvidia/nvidia_sdk/JetPack...version.../Linux_for_Tegra/” directory. Within that take a look at the .conf files:
ls -l *.conf
Notice that the common names starting with “jetson-” are symbolic links pointing at combinations of module and carrier board models. One of those is for a nano, and also has qspi in its name. A recovery mode Nano, probably with SD card removed might be flashed by naming that as the target board, and mmcblk1p1 as the location. Example, if you have file “jetson-nano-qspi.conf”:
sudo ./flash.sh jetson-nano-qspi mmcblk1p1
Do you really need to flash just the bootloader? Or are you just wanting to not lose the SD card content?
Incidentally, you could just clone the SD card and use a copy if the latter is the case.