Xavier NX eMMC (P3668-0001): ALIASCHECKER 0x1c / Return value 8 on ALL BSPs (R32.7.0, R35.5.0, R35.6.4 SDKM) AND on cold boot from existing QSPI bootc

iam.zero.57 · July 18, 2026, 5:35am

Hi,

I have a Jetson Xavier NX 8GB eMMC production module that previously worked
normally, and now fails DRAM initialization at the exact same point through
every possible path. Before going to RMA I would like to confirm whether any
recovery path exists, and what ALIASCHECKER reason 0x1c / aux_info 0x06
specifically indicates.

Module

P3668-0001 (699-13668-0001-301), Rev G.0, 8GB, eMMC
EEPROM reads consistently: Board ID 3668, FAB 301, SKU 0001, Rev G.0
Chip: T194, SKU 0xde, minor rev 2, BootROM rev 0xf, RAMCODE 1
ECID: 0x88021911644571431400000006018180

Carrier / host

Carrier for flashing: Waveshare JETSON-IO-BASE-A (P3509-compatible),
powered by its specified 5V/4A barrel adapter
Host: Ubuntu 18.04, AMD, native (no VM)
Recovery USB (0955:7e19) enumerates reliably; BootROM RCM, MB1 applet,
MB2 applet all run; EEPROM/chip_info dump succeeds every time

History

The module previously ran Linux normally (most recently kernel
5.10.120-tegra reached userspace on this carrier).
Since then, every flash attempt fails, and now cold boot fails too.

Failure signature (identical in every case)

Host side always:
Sending bct_bootrom [100%] → OK
Sending bct_mb1 [100%] → OK
Sending bct_mem [100%]
Error: Return value 8
Command tegrarcm_v2 --download bct_bootrom br_bct_BR.bct
–download bct_mb1 mb1_bct_MB1_sigheader.bct.encrypt
–download bct_mem mem_rcm_sigheader.bct.encrypt

Device UART always:
E> FAILED: Thermal config
E> FAILED: MEMIO rail config
E> Task 50 failed (err: 0x7979061c)
E> Top caller module: ALIASCHECKER, error module: ALIASCHECKER,
reason: 0x1c, aux_info: 0x06

What I have tried (all fail identically at bct_mem)

Clean stock R32.7.0 tree (fresh download, fresh directory, no
modified cfg/DTB, no env overrides): Return value 8
Clean stock R35.5.0 tree (same conditions): Return value 8
SDK Manager JetPack 5.1.6 (R35.6.4), full auto-detect
(nv-auto-config selected jetson-xavier-nx-devkit-emmc from EEPROM,
passed --ramcode 1 automatically): Return value 8
Re-running the saved flashcmd.txt directly (which used default
ramcode 0): Return value 8 — so both RAMCODE 1 and 0 fail
flash.sh was always run alone in a fresh recovery session (no manual
tegrarcm/EEPROM reads consumed the RCM session beforehand)

Cold boot result (no host involved)

With no recovery jumper, the existing QSPI bootchain (MB1
1.5.1.9-t194-41334769-73a9b7ef, BCT from QSPI: “Qspi flash params
source = brbct”) — i.e. the exact bits that used to boot this module
successfully — now fails with the same error and auto-resets to
recovery:

[0000.203] E> FAILED: Thermal config
[0000.211] E> FAILED: MEMIO rail config
[0000.220] E> Task 50 failed (err: 0x7979061c)
[0000.224] E> Top caller module: ALIASCHECKER, error module:
            ALIASCHECKER, reason: 0x1c, aux_info: 0x06
[0000.263] I> Reset to recovery mode

So the same failure occurs with four different BCT sources (R32.7.0,
R35.5.0, R35.6.4, and the old QSPI-stored BCT that previously worked),
two different MB1 generations, both RAMCODE values, manual flash.sh and
SDK Manager auto-detect, and with no host/USB involvement at all in the
cold boot case.

I have seen topic 285769 where the same signature on Xavier NX led to an
RMA verdict after 32.7.4 and 35.5 both failed.

Questions

What exactly does ALIASCHECKER reason 0x1c with aux_info 0x06 mean at
MB1 level? Which check fails (address alias probe? rank/row mapping?)
Given that BootROM/MB1/MB2/EEPROM all work and only DRAM init fails,
is there ANY software/firmware-level recovery path for this state, or
is this conclusively a module memory subsystem failure requiring RMA?
Is there any additional diagnostic you would like me to run to
confirm either way?

Attached: host flash logs for attemps,

SDKM_logs_JetPack_5.1.6_Linux_for_Jetson_Xavier_NX_2026-07-17_19-49-23.zip (614.8 KB)

and the
full cold-boot UART capture.

Thank you.

The cold boot UART log is below:

[0000.082] I> Qspi initialized successfully
[0000.086] I> Active Boot chain : 0
[0000.089] I> Boot-device: QSPI
[0000.092] I> Qspi flash params source = brbct
[0000.098] W> MB1_PLATFORM_CONFIG: device prod data is empty in MB1 BCT.
[0000.106] I> Temperature = 24000
[0000.109] W> Skipping boost for clk: BPMP_CPU_NIC
[0000.113] W> Skipping boost for clk: BPMP_APB
[0000.117] W> Skipping boost for clk: AXI_CBB
[0000.121] W> Skipping boost for clk: AON_CPU_NIC
[0000.125] W> Skipping boost for clk: CAN1
[0000.129] W> Skipping boost for clk: CAN2
[0000.133] I> Boot-device: QSPI
[0000.136] I> Boot-device: QSPI
[0000.139] I> Qspi flash params source = mb1bct
[0000.143] I> Qspi using bpmp-dma
[0000.146] I> Qspi clock source : pllc_out0
[0000.150] I> Qspi reinitialized
[0000.153] I> Qspi flash params source = mb1bct
[0000.158] I> ECC region[0]: Start:0x0, End:0x0
[0000.162] I> ECC region[1]: Start:0x0, End:0x0
[0000.166] I> ECC region[2]: Start:0x0, End:0x0
[0000.171] I> ECC region[3]: Start:0x0, End:0x0
[0000.175] I> ECC region[4]: Start:0x0, End:0x0
[0000.179] I> Non-ECC region[0]: Start:0x80000000, End:0x100000000
[0000.185] I> Non-ECC region[1]: Start:0x0, End:0x0
[0000.189] I> Non-ECC region[2]: Start:0x0, End:0x0
[0000.194] I> Non-ECC region[3]: Start:0x0, End:0x0
[0000.198] I> Non-ECC region[4]: Start:0x0, End:0x0
[0000.203] E> FAILED: Thermal config
[0000.211] E> FAILED: MEMIO rail config
[0000.220] E> Task 50 failed (err: 0x7979061c)
[0000.224] E> Top caller module: ALIASCHECKER, error module: ALIASCHECKER, reason: 0x1c, aux_info: 0x06
[0000.233] I> MB1(1.5.1.9-t194-41334769-73a9b7ef) BIT boot status dump :
0000000000011111111110111111111111111111111100111110000000000000000000000000000000000000000000000000000000000000000000000000000011011000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
[0000.263] I> Reset to recovery mode

DavidDDD · July 20, 2026, 4:16am

Hi,

Do you have another SOM to do the cross check?

Thanks

iam.zero.57 · July 21, 2026, 2:27am

Hi David,

Unfortunately, I do not have another Xavier NX SOM available for cross-checking.

However, I have tested this same SOM on two carrier boards.

Waveshare JETSON-IO-BASE-A

USB recovery mode is detected successfully.
EEPROM, board information, QSPI, and eMMC partition information can be read successfully.
Flashing consistently fails during the memory BCT stage with:
- Task 0x4d failed
- Top caller module: MB1_MSS
- reason: 0x1c
- aux_info: 0x01

Seeed Studio J202

This is a newly purchased J202 carrier board for cross-checking.
Unfortunately, the host PC does not detect the Xavier NX SOM in USB recovery mode at all.
No NVIDIA USB device (0955:7e19) appears in lsusb.
I have followed the official J202 recovery procedure (FC REC to GND, USB Type-C device port, power cycle), but the module is still not detected.

One important point is that this same Xavier NX SOM previously worked correctly on another J202 carrier board.
It successfully booted Linux, and I used it to develop an F1TENTH vehicle.
The system was fully operational, including installing the software environment, building the F1TENTH stack, and running the platform.

After the failure occurred, I tested multiple JetPack/L4T versions, including R32.7.x, R35.4.1, R35.5, and R35.6.4.
On the Waveshare carrier board, every version consistently fails during DRAM initialization with the same MB1_MSS error.

Since I do not currently have another Xavier NX SOM, could you please advise whether there is another diagnostic method to distinguish between:

a Xavier NX SOM hardware failure,
a memory BCT compatibility issue, or
another possible root cause?

Also, could you please clarify the internal meaning of:

MB1_MSS reason: 0x1c
aux_info: 0x01

Based on the current logs, do you think this behavior is more consistent with a hardware failure of the SOM?