My apologies if the previous explanation was unclear.
Perhaps it would be best to describe the modules in terms of two sets of modules, call them set mA and set mB.
Set A consists of modules that were built (i.e. seated on their carrier boards and assembled in a finished product) several months ago, and were originally flashed with an older image (i0) prepared by our team which now has slightly outdated dependencies. Modules in set A were able to boot successfully when flashed with image i0. We used a module from set A flashed with image i0 as a basis for creating a new image i1 with updated dependencies. When a module from set A was flashed with image i1, it was able to boot successfully.
Set B consists of new modules coming off the assembly line, so to speak. These modules had not been flashed with any image prepared by our team until a few days ago when we first attempted to flash image i1. The logs you’re seeing were obtained by attaching a serial console to a module from set B that had been flashed with image i1. At the time of this writing, no module from set B has been able to successfully complete to boot process.
Hopefully the above should answer question 1. There has not been any change to the BOM between set A and set B. Modules from set A are seated on the same carrier board as modules from set B.
- What is the jetpack release in use here?
L4T 32.6.1 (JetPack 4.6)
- How did you “flash” your board? Where do you want you device boot from? The boot log seems indicating it is failing to load kernel from rootfs.
Before flashing, we prepared image i1, we copied that image into the
bootloader directory at the path
bootloader/system.img as recommended in the Flashing Support section of the documentation.
Before delving into an explanation of the process by which we flashed the module, it’s worth noting that the intent is for the module to boot from emmc.
Our first attempt used a mass flash blob constructed using image i1. We constructed the mass flash blob using the instructions found in the mass flash readme. We did not use the initrd method, but rather the legacy
nvmassflash.sh method. Using this method, we are able to successfully flash a module from set A. This module was able to boot. We also performed this method on a module from set B. Though the flash process completed successfully, the module from set B was not able to successfully boot.
Our next attempt to flash involved using the
flash.sh script with the existing image i1. In this attempt, we tried to flash the APP partition exclusively:
sudo ./flash.sh -r -k APP cti/xavier-nx/photon/base mmcblk0p1
For modules from set A, the flash was successful and the module was able to boot. For modules from set B, we achieved the same result as the previous attempt: i.e. successful flash, unable to boot.
Our third attempt to flash involved using the
flash.sh script with the existing image i1. In this attempt, we tried to flash all partitions:
sudo ./flash.sh -r cti/xavier-nx/photon/base mmcblk0p1
We did not attempt to flash modules from set A using this method. For modules from set B, we achieved achieved the same result as the previous two attempts: i.e. successful flash, unable to boot.
Hopefully this answers your questions––more than happy to provide any additional clarification as needed.