Flashing fresh Jetson nano sd card DTB partition

We have a functional Jetson nano module(sd card) with L4T 32.4.1 based kernel, inserting its sd card into a brand new jetson module doesnt seem to update its dtb section according to DTB partition. However flashing the jetson module + sd card with flash script: ’ sudo ./flash.sh -r -k DTB jetson-nano-devkit mmcblk0p1’ after replacing kernel/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb doesnt seem to show any sign of module booting with the sd card.
Flash log uploaded:
boot_flash.log (16.0 KB)

I am unsure if bootloader needs to be updated on a fresh module, or if there are any steps setting up module for sd card. Please advice.
Thank you

Just some information related to the topic which might help…

SD card models have QSPI memory on the module itself. Boot content is in the QSPI for that model (or eMMC partition for the other model), and this must work with the particular SD card release version. You must flash the module itself in order to update that boot content (content not in the SD card or rootfs partition).

Device tree can be either from a partition or QSPI if not found in “/boot”. To be found in “/boot” the “/boot/extlinux/extlinux.conf” must name this. For naming of the device tree this is the “FDT” key/value pair (there is a different entry for naming the kernel Image file). If the FDT entry is found, then the partition is never used, and thus the flashed tree would be ignored since it goes to either the QSPI or a partition (the eMMC case).

Thank you, that certainly makes it a little more clear on jetson nano boot bringup. For updating the content on the QSPI memory (assuming that includes pre bootloader and device tree), what would the minimal step be before it could boot from sd card? Is there a certain flash script parameter for updating that, or would I have to go through the full flash everytime with an sd card.

Also, whats unclear is how would we determine which device tree it boots from as there are three potential sources (QSPI mem/ partition on sd card/ rootfs boot folder). Given FDT entry is not entered, I assume that would eliminate the boot folder dts file however the other two options don’t have a specific parameter to point to device tree source.

Any insight into this would be greatly appreciated, Thank you!

  1. Learn to dump the uart log first.

  2. If you use flash.sh the flash log will tell you which dtb is in use.

As mentioned by @WayneWWW , if customizing a device tree or some other part and want to know what to change (or what to debug for a dev kit), you’d start with the serial console log since it shows files and partitions being loaded, and then you’d also look at a command line flash log to see where it is getting the files you saw during boot. An example of flashing on command line and logging with the command you originally gave:

sudo ./flash.sh -r -k DTB jetson-nano-devkit mmcblk0p1 2>&1 | tee log_flash.txt

The above would produce “log_flash.txt”, and you could use this to track any installed content. Combine this with a serial console boot log and you would know not only how to track the files, but which files to replace or modify for your circumstance.

I believe the question was not about how to debug the device-tree content or about which files are being written to the device-tree storage, but how to determine which of the DTB partition vs. QSPI memory the device-tree is being read from at boot.

Is there something that can be configured to control whether the DTB partition vs. QSPI memory is preferred, or is there a fixed search-order (if so, what is it?), and what set of preconditions need to be met for a Nano to read its device-tree from the DTB partition instead of the QSPI memory?

Check the board config you use to flash the board. Inside of the content, search “xml” and you will see a layout file.

You could compare the difference of this file between the rel-32.5.1 and rel-32.4.x. And you will find out that DTB was loaded from sdcard before re-32.4.x. That is the main diff why sdcard does not contain DTB anymore.

The serial console boot log would probably provide clues to this since it logs even in boot stages prior to Linux ever starting.

Note that a QSPI source will always be used on an SD card model if and only if the extlinux.conf does not name one as a file in “/boot”; an eMMC one will always read from a partition if and only if the extlinux.conf does not name one. Well, I should say there is one exception: If security fuses are burned, then only eMMC device tree partition is read, and the SD card model does not support security fuses. Serial console log should reflect the source.

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