TX2i unable to boot, cannot enter recovery (ERROR: Highest Layer Module = 0x40)

I have a TX2i installed in a P2597 dev board (699-82597-0000-501 D), and have been using it successfully for a few months now.

I came in this morning, and saw on the serial console an endless loop of:

[0[0000.209] C> ERROR: Highest Layer Module = 0x40, Lowest Layer Module = 0x40,
Aux Info = 0x0, Reason = 0xd
[0[0000.228] C> ERROR: Highest Layer Module = 0x40, Lowest Layer Module = 0x40,
Aux Info = 0x0, Reason = 0xd
[0[0000.226] C> ERROR: Highest Layer Module = 0x40, Lowest Layer Module = 0x40,
Aux Info = 0x0, Reason = 0xd
[0[0000.207] C> ERROR: Highest Layer Module = 0x40, Lowest Layer Module = 0x40,
Aux Info = 0x0, Reason = 0xd

I tried rebooting it to recovery mode, but the connected host never sees the USB device appear, and the serial output is exactly the same as before. The serial output never varies except for the timestamp, which never seems to exceed 0000.228.

I also tried removing power, letting it sit for ~10 minutes, and powering it up, but there was no change.

Just to be clear, I have used recovery mode over USB to reflash this system in the past in this exact setup (same host computer, OS, USB cable, etc), but since this issue appeared, I have had no success in getting it to enter recovery mode (no USB device appears on my host system anymore).

It is more like a hardware issue if even recovery mode is not working.

Is there any other devkit carrier board can try?

I have a different revision of the same carrier board that I can test it in. I’ll try that on Monday.

If it fails the same way in the other carrier board I assume I should begin the RMA process for the chip, and if it works in the other carrier board, I’d instead by RMAing the carrier board.

I moved the TX2i onto another P2597 dev board (699-82597-0000-900 C), and it continues to fail the same way.

ok, please go ahead with RMA process.

The same thing happened with the replacement I was sent. The TX2i booted into recovery mode just fine, I flashed it with my system image (imaging process reported no failures - everything looked normal), and the system immediately produced the same error. And the chip can no longer be put into recovery mode.

This leads me to suspect there’s some property of my image that’s somehow interfering with the ability to boot into recovery, but I can’t imagine what. I’m using stock everything up to the U-Boot step, and for the Linux system, I’m building OpenEmbedded (warrior branch) with the meta-tegra layer.

Seeing as how I’ve now bricked two TX2i’s, I’m not inclined to experiment to identify exactly what’s causing this to happen. How should I proceed?

You might provide a serial console boot log. If U-Boot and prior stages were from the stock software, then you will be able to get a log right up to the point where the kernel is loaded.

So, it seems I was mistaken about being unable to put this second TX2i into recovery mode. I had assumed because it was giving the same output that it had failed in exactly the same way as the first time, which appears not to be the case.

As a result I have been able to track the issue down to one of partition sizes. If I set one of my partitions to a size of 2GB or larger, it seems to cause this issue. I’m trying to size a non-rootfs partition to 4GB, but I cannot get it to boot until I set it to < 2GB. Otherwise, after powerup I get serial debug console output endlessly looping the output I provided in my initial post. That is literally the only thing it outputs from the moment it’s powered on.

Is there anything special I need to do to have partitions >= 2GB?