Boot Error - Stuck on splash screen

Hi,
Sorry, I think you didn’t get the point.
You don’t need to check the working nano. Your log already told me the uboot version of the working nano.

What I wanted to ask is you have many failure modules, use the same method to add console=none and keep_bootcon to dump their log and share them here. I would like to see if all of them hit same situation.

Sorry, it takes few minutes to connect everything, wait for the log to dump, and copy the log from the serial console. These are the logs from the other two boards with the same issue, using the same SD card.

board2-longer_log.txt (147.9 KB)
board3-longer_log.txt (197.6 KB)

Could you clarify this step for me in that case?

From the NG board, please do not erase it. Just move the sdcard out from the board. Put it to your host. Check what is inside /boot and /boot/dtb folder on this sdcard.

I thought you were looking for the files from the image on the SD card. Otherwise, I don’t know how to retreive that information as the boards with issues don’t finish booting.

Hi,

There is nothing to check on your side now. I can guess out why this issue happened. Let me share the conclusion of this issue in few minutes later.

1 Like

The conclusion comes first.

→ This issue is not hardware problem. The board is fine. But to make it back to work, you have to flash it with sdkmanager.

Below is the reason why this issue can only be resolved by using sdkmanager or our official flash script.
It is long and not easy for beginner to understand.
I don’t know if you want to know about it or not.
If you do not, please just reflash the module with sdkmanager and it will be fine.

→ There is a QSPI memory on jetson nano sdcard module to store the bootloader software. After jetpack4.5.1/rel-32.5.1, all the bootloader and device tree are moving to this QSPI flash memory. Which means your sdcard image only provides the rootfs. Even dtb is not read from sdcard.
Since this issue is the mismatching dtb in use, which means something on the QSPI is corrupted. This means no matter what sdcard image you tried, it just does not matter to and cannot affect the boot process.

As for why the QSPI is corrupted, it needs to check with your end customers. I guess they accidentally flash jetson nano 2gb image to the board or accidentally put nano 2gb sdcard image to the board and triggered the bootloader update mechanism.

Please be aware that I used the term “flash” and “sdcard image” as 2 different methods because using sdcard image is never considered a true “flash” method to Jetson platforms.

1 Like

I see… that may have been something that they did. I thought something was off, when this message popped up:

Model: NVIDIA Jetson Nano 2GB Developer Kit
Board: NVIDIA P3541-0000
DRAM: 4 GiB

I’ll fix the boards we have and return them to the customer and relay the solution to them. Thanks for your help on this! Sorry, for the confusion earlier.

(Now, I just need to figure out why some of their boards are having that power issue, but I’ll see if I can get some log messages and create a new topic for that.)

1 Like

No problem. Please let me know if your customer has any feedback then.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.