Jetson Xavier NX Boot Loop After Flash

[harris6ctq5]

Hello,

We seem to be having issues flashing new Jetson Xavier NX hardware.

We’ve validated that the flash process works on hardware that had already been flashed to, but when the same flash process is applied to a fresh module, the module does not finish booting.

Instead, if we plug in a monitor, we see an Nvidia splash screen for a brief moment, which then goes dark. Some seconds later, we see the same splash screen appear. This continues indefinitely.

We’ve attached a serial console to one of the modules that is experiencing this boot cycle after flash. The logs obtained are attached here (81.3 KB).

Some additional notes that may be of use:

The modules being flashed are seated on a ConnectTech Photon carrier board. We have followed the instructions to set up the proper board configuration files and were able to successfully flash an image onto an Xavier NX seated on the Photon board, however as I mentioned, this module had already been flashed previously.

The flash was performed in two different manners, both of which achieved the same result:

1. We used a mass flash blob that had been validated to work (though again, not on a fresh module.
2. We used the flash.sh script, both with and without specifying the APP partition.

Any ideas what might be causing the issue that we’re seeing?

Regards,
Harris

[WayneWWW]

Hi,

Sorry that I have to say actually it is hard to understand what was tried when there seems to be multiple modules and multiple carrier boards.

Thus I have some questions here

1. You told us the modules have been flashed. This is good. So what was changed here? Move from Photon board to CTI’s board?

2. What is the jetpack release in use here?

3. 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.

0009.040] I> ########## Fixed storage boot ##########
[0009.045] I> Loading kernel-bootctrl from partition
[0009.050] I> Loading partition kernel-bootctrl at 0xa4b70000 from device(0x1)
[0009.065] W> tegrabl_get_kernel_bootctrl: magic number(0x00000000) is invalid
[0009.065] W> tegrabl_get_kernel_bootctrl: use default dummy boot control data
[0009.071] I> Already published: 00010003
[0009.074] I> Look for boot partition
[0009.078] I> Fallback: assuming 0th partition is boot partition
[0009.083] I> Detect filesystem
[0009.111] I> Loading extlinux.conf ...

[harris6ctq5]

Hey Wayne,

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.

2. What is the jetpack release in use here?

L4T 32.6.1 (JetPack 4.6)

3. 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.

Regards,
Harris

[DaneLLL]

Hi,
Could you try latest Jetpack 4.6.2 or 4.6.3? Certain new Xavier NX modules are supported in later release. May not have been supported on 4.6.1.

[harris6ctq5]

Hey Dane,

We tried using Jetpack 4.6.2 along with its compatible BSP, but are still encountering the boot loop. See logs here (114.0 KB)

We’re going to attempt flashing the stock sample rootfs instead of the customized image we’ve been trying to flash up to this point. Will keep you in the loop as soon as we have more information to report.

Regards,
Harris

[WayneWWW]

Please directly upgrade to jp4.6.3. Jp4.6.2 has some cboot issue.