Jetson Orin NX Nvme flash error

[JinSH]

Hello, I have a question regarding Jetson Orin NX flash error.

Currently, 33 Jetson Orin NX (8GB) models are being purchased and set up for pilot project installation.

The carrier board is a custom (self-made) board,
and the file system is flashed on M.2 SSD.

The inquiry is as follows.
22 out of 33 have completed flashing and confirmed normal operation.

11 out of 33 are not flashed on the board.

All downloads and setting environments are the same.

Can you please check what the problem is?

Please check the error log message attached.

Jetson Serial log.
Serial_Message.txt (5.0 KB)

BSP Flash log
Download_Message.txt (213.0 KB)

[KevinFFF]

Hi JinSH,

@JinSH

11 out of 33 are not flashed on the board.

Do you mean that you hit the flash failed issue with these 11 modules?

E> SPI_FLASH: Invalid value device id: 8.
E> Failed to open qspi flash=0, err = 3c3c0902
E> Failed to initialize boot device
C> Applet storage init failed
C> Task 0x0 failed (err: 0x3c3c0902)
E> Top caller module: SPI_FLASH, error module: SPI_FLASH, reason: 0x02, aux_info: 0x09

From your serial console log, it seems the QSPI can not be recognized.

Do you have the devkit and put the module on that board and use SDK Manager to flash?

[JinSH]

Yes, that’s right.
Only 11 boards failed to flash.

I don’t have a DevKit…
But I have AverMedia’s carrier board, so I tried flashing it after connecting it to that board, but the symptoms were the same.

[KevinFFF]

For the custom carrier board, please use the custom BSP package and the instruction from your vendor to flash.

Could you share more flash failed log for us to check if they failed at the similar place?

[JinSH]

Currently, I have sent it to the domestic agency to check the module, so additional log dumps are not possible, so I am sending you the log contents that remained during the past test.

tegrarcm_v2 --chip 0x23 0 --ismb2applet

• There were cases where it stopped at the above command. If it stops at that command line, it stays at that command even after an hour.

The rest of the failure messages are the same as the contents attached to the log.

[KevinFFF]

@JinSH

There were cases where it stopped at the above command. If it stops at that command line, it stays at that command even after an hour.

We have to check the full flash to know more detailed information.

@JinSH

I have sent it to the domestic agency to check the module

Do you have only one module hit the flash issue?
Or you have only that module currently?

[JinSH]

There are a total of 11 modules that are experiencing problems.

[KevinFFF]

Could you share the full flash log for further check?

[JinSH]

Download_Message.txt (213.0 KB)

This is a flash log.

[KevinFFF]

Board ID() version() sku() revision()
Chip SKU() ramcode() fuselevel(fuselevel_production) board_FAB()

It seems not the expected result to me.
There’s no board information in flash log.
Since the board is not designed from you, please also ask the help from your vendor to check if EEPROM works as expected.

[JinSH]

Our carrier board does not have eeprom
We are flashing by modifying the eeprom read size of the tegra234-mb2-bct-misc-p3767-0000.dts file to 0x0

And there are other modules that flash normally on the same carrier board.

As mentioned above, 22 out of 33 units succeeded, and only 11 units failed.

Is there any other way to initialize the module??

[KevinFFF]

I would like to know if those 11 units can be flashed and boot up successfully on the devkit board.
But it seems you don’t have that to verify…

Do you fail at the same place for those failed modules?
Or have you tried to re-flash them again?