Hi,
Recently, we got some latest NX SoMs which are labelled 180-13668-DAAA-A03. We tried to flash them with JetPack 4.5 which is downloaded by SDK Manager. However, system got stuck with NVIDIA white logo on the HDMI screen when we used the flashcmd.txt to flash the NX SoMs.
We didn’t see this boot failure on the old NX SoMs which are labelled 180-13668-DAAA-A02. Please help check this issue. The attachment are the flashcmd.txt, boot and flash logs.
Here are the steps to reproduce the issue:
- Use SDK Manager to download Jetson OS and Jetson SDK Components but not flashing device
- Exit SDK Manager after it finishes the downloading process
- Enter JetPack 4.5 Linux_for_Tegra directory:
cd ~/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_XAVIER_NX/Linux_for_Tegra
- Do first flashing for generating flashcmd.txt
sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1
- Wait until the first flashing is done and make device enter Recovery Mode again
- Enter Linux_for_Tegra/bootloader directory
cd bootloader
- Do second flashing by using the generated flashcmd.txt
sudo bash flashcmd.txt
- Wait until the second flashing is done and this issue happens
error01_boot_white_nv_logo.zip (36.8 KB)
hello marble_hong,
though the flashing process is complete without failure.
could you please double confirm this issue only happened with performing flashcmd.txt?
~/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_XAVIER_NX/Linux_for_Tegra/bootloader (master) $ sudo bash flashcmd.txt
...
[ 409.7191 ]
[ 409.7192 ] Flashing completed
[ 409.7193 ] Coldbooting the device
[ 409.7209 ] tegrarcm_v2 --ismb2
[ 409.7247 ]
[ 409.7261 ] tegradevflash_v2 --reboot coldboot
had you connect a display monitor to NX platform,
did it shows up system configuration UIs and waiting for user inputs?
[ 9.698019] Please complete system configuration setup on desktop to proceed...
Hi marble_hong,
Why you need run twice flash commands?
sudo ./flash.sh jetson-xavier-nx-devkit-emmc mmcblk0p1
sudo bash flashcmd.txt
Can you using sdkmanger to flash your A03 module success?
Hi Carol,
We need to provide our customized system.img to our factory and customers. In our opinion, using flashcmd.txt which has the tegraflash.py process is the only way to flash board with system.img.
The steps I provided in Post #1 is fastest way to reproduce this issue. We have lots of internal work to do for customizing kernel, cboot and rootfs between Step 4 and Step 5. After the customization, we extract the rootfs as our customized system.img.
Flashing A03 module with JetPack 4.5 by sdkmanager is OK under our test. But we would not use sdkmanager in our factory, it takes too much time and cannot perform multiple devices flashing.
The odd thing we discovered is that flashcmd.txt is always OK until JetPack 4.5. A03 module flashed with JetPack 4.4.1 or JetPack 4.4 by flashcmd.txt is OK.
Hi marble_hong,
We will check flashcmd.txt issue internally.
If you are use on factory, maybe you can try Flashing from NFS, please reference detail from Documents.
You can also reference README on here:
$ ~/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_XAVIER_NX/Linux_for_Tegra/tools/kernel_flash/README.txt
Hi Carol,
Thank you for the NFS method. We will try it.
We found that the mass flashing method which follows:
~/nvidia/nvidia_sdk/JetPack_4.5_Linux_JETSON_XAVIER_NX/Linux_for_Tegra/README_MassFlash.txt also fails to enter Desktop with A03 module. It has the same error pattern which is HDMI display monitor is stuck on NVIDIA white logo after flashing.
Hi Carol,
After trying the NFS flash method with A03 module, we still saw the NVIDIA white logo stuck issue. It was OK with A02 module.
We still think the best way to flash our factory devices is using flashcmd.txt. If NVIDIA team has any update about this issue. Please let us know. This issue should happen in worldwide factories which adopt flashcmd.txt to flash their devices.
We are working on the fix for this issue. Will paste this once we confirmed it is resolved.
Hello marble_hong,
We have a workaround method to let A03 module get flashed by flashcmd.
Before you flash the device by using flashcmd, please copy the bpmp dtb from Linux_for_Tegra/bootloader/t186ref to Linux_for_Tegra/bootloader.
After this step, flash the board and it shall enter the desktop.
Hi Wayne,
Thank you for your help.
We think a better way based on your workaround would be disabling the TRIM_BPMP_DTB in p3668.conf.common for generating a flashcmd.txt without the option of trimming the BPMP dtb.
Because the trimming BPMP dtb work seems to be newly added in JetPack 4.5. Could you let us know if there is any side effect of NOT trimming the BPMP dtb? We may take it as our short term solution in our factory for products with A03 module.
No, there would be no side effect for A03 NX.
