dear WayneWWW:
do you use the latest img (https://developer.download.nvidia.cn/embedded/L4T/r32_Release_v6.1/Jeston_Nano/jetson-nano-jp46-sd-card-image.zip)?
I format My sdcard and download this image by Win32DiskImager.exe tool.
OK, I will use your suggestion to try again.
dear WayneWWW:
Do you add FDT /boot/tegra210-p3448-0000-p3449-0000-b00.dtb into extlinux.conf. and test the new kernel command? I used sdkmanager to update to laest version,it is the same issue as before.
tks
Yes, we added. But we didn’t change the content inside this device tree. Did you modify it?
dear WayneWWW:
no，I add only DFT /boot/tegra210-p3448-0000-p3449-0000-b00.dtb which is existing [jetson-nano-jp46-sd-card-image.
If it is convenient, Can you share your img to me?
tks
There is no special image. I just use the sdkmanager.
It is kind of weird. Maybe I missed some detail.
@linuxdev , do you see similar issue on your side?
I have not seen an issue, but I have not been “looking”. Also, I only have an early release Nano which is probably not the same model (the carrier board revision is from a non-production model).
For reference, R32.5.1 corresponds to SDKM 4.5.1. I am attempting to use the most recent SDKM, with “--archivedversions” argument to pick 4.5.1 (SDKM 1.6.0.8170), but this release is missing in archivedversions. I am thinking of installing the original SDKM 4.5.1 instead of using “--archivedversions”, but have not yet done so (waiting to see if 4.5.1 should be visible in --archivedversions of SDKM .16.0.8170). I am thinking of viewing the checksum of the device trees for comparison.
Perhaps most important, there would be a difference in the QSPI boot content depending on what the actual SD card model dev kit was flashed with, and if this differs from what the SD card was intended for, then an error would occur. The SD card content is not the only content during boot, and part of what interacts with the device tree is on the Nano itself. Have you flashed the Nano itself, or just SD card? Is your SD card image from the same release as used to flash the Nano? I’d like to be sure that this isn’t a simple case of mixing older and newer releases via a mismatch in QSPI memory versus SD card content.
@ccl033 May I ask you again that you also tried “sdkmanager” but not just flashing another sdcard image?
dear linuxdev：
what？do you mean we need update all of jetson nano boards by sdkmanager for using the DFT in extlinux。conf？
Jetson nano sd module has two boot components on the module.
One QSPI-NOR which has the bootloader sw, while another one is the SDCARD.
Keep replacing the sdcard image would only lead the sdcard part software (kernel,dtb) gets updated, but the content in QSPI-NOR is still the same. That is what linuxdev tried to tell.
@WayneWWW explained, but in addition to that information saying that yes, these need to have the actual board flashed too, keep in mind that the reason for this is that early boot content is still on the Jetson itself, and although this changes less often than the part on SD card, that the two must have compatible versions. Units which were never flashed will only work with SD cards designed for that earlier QSPI software. So to guarantee the SD card image can boot, yes, you do need to flash the actual Jetson with JetPack for the case of mismatched QSPI version software.
1 Like