Jetson nano dtb issues

Hello Experts

I would like to ask two questions about DTS on Jetson platform.

  1. I updated the DTB partition by the flash.sh script, but the DTB files in the /boot (and /boot/dtb) folder on the file system were not updated.
    The flashed DTB file is actually working, but I want to know what the DTB file in /boot folder does. Is there any function like automatic recovery?
    I use this commend to flash dtb file # sudo ./flash.sh -r -k DTB jetson-nano-emmc mmcblk0p1.

2.I want to back up the DTB file from the board and decompile it into a DTS file, but the DTB file I dump is encrypted. Can I decrypt it? How to parse it into a DTS file?

log:

[ 0.7196 ] Reading partition
[ 0.7251 ] tegradevflash --read DTB /home/smthub/Rick/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_NANO/Linux_for_Tegra/signed/ip_86.dtb.encrypt
[ 0.7291 ] Cboot version 00.01.0000
[ 1.2473 ] Reading partition DTB in file /home/smthub/Rick/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_NANO/Linux_for_Tegra/signed/ip_86.dtb.encrypt
[ 1.2532 ] […] 100%
[ 1.5517 ]
root@smthub-NUC8i5BEK:~/Rick/nvidia_sdk/JetPack_4.4.1_Linux_JETSON_NANO/Linux_for_Tegra/signed# dtc -I dtb -O dts -o ip_86.dts ip_86.dtb.encrypt
FATAL ERROR: Blob has incorrect magic number

For your question 1, actually it is not in use. The “DTB” you flashed is a partition name. By default your device tree is read from this partition but not the /boot/dtb. That is why that command does not update /boot/dtb.

For your second question, you cannot convert a signed dtb back to dts. Please use one that is not encrypted.

FYI, the FDT key/value entry in “/boot/extlinux/extlinux.conf” is how you would actually use a device tree binary file in “/boot”. This entry is not there by default. If you were to add the FDT entry, then your Nano would switch to using this instead of the one in the partition (thus you would not require any flashing at all to add a tree if you’ve edited extlinux.conf).

Note that if you’ve burned security fuses, then only the signed partition version will be accepted, and then only if the keys used during flash are correct.

This is from a TX2, so maybe not entirely correct for your case, but here is an example entry with an FDT added:

LABEL primary
      MENU LABEL primary kernel
      FDT /boot/something.dtb
      LINUX /boot/Image
      APPEND ${cbootargs} root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4

Thanks for your detailed explanation.

I tested the FDT entry mode, it’s convenient for frequent validation of the device tree.
But when I used two versions of the DTS file(There are differences in node configuration), the kernel failed to boot.
To my confusion, both versions of DTB started properly when I updated the DTB partition with flash.sh script.

At first, I thought that the device tree used by bootloader (in RP1 partition) was different from that used by kernel(FDT entry) , which was caused by the conflict.
However, I see that flash script only updates the DTB partition, the RP1 partition is not updated.

sudo ./flash.sh -r -k DTB jetson-nano-emmc mmcblk0p1

Could you please help to explain why there is such a difference?

Here’s the error log of replace DTB by FDT:

U-Boot 2016.07-g7a7e3f476e (Oct 16 2020 - 12:23:42 -0700)

TEGRA210
Model: NVIDIA P3450-Porg
Board: NVIDIA P3450-PORG
DRAM:  4 GiB
MMC:   Tegra SD/MMC: 0, Tegra SD/MMC: 1
SF: Failed to get idcodes
*** Warning - spi_flash_probe() failed, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Card did not respond to voltage select!
** Bad device mmc 1 **
Hit any key to stop autoboot:  0 
Card did not respond to voltage select!
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:1...
Found /boot/extlinux/extlinux.conf
Retrieving file: /boot/extlinux/extlinux.conf
972 bytes read in 176 ms (4.9 KiB/s)
1:	primary kernel
Retrieving file: /boot/initrd
5487776 bytes read in 204 ms (25.7 MiB/s)
Retrieving file: /boot/Image
34332680 bytes read in 811 ms (40.4 MiB/s)
append: tegraid=21.1.2.0.0 ddr_die=4096M@2048M section=512M memtype=0 vpr_resize usb_port_owner_info=0 lane_owner_info=0 emc_max_dvfs=0 touch_id=0@63 video=tegrafb no_console_suspend=1 console=ttyS0,115200n8 debug_uartport=lsport,2 earlyprintk=uart8250-32bit,0x70006000 maxcpus=4 usbcore.old_scheme_first=1 lp0_vec=0x1000@0xff780000 core_edp_mv=1075 core_edp_ma=4000 tegra_fbmem=0x800000@0x92cb4000 is_hdmi_initialised=1  earlycon=uart8250,mmio32,0x70006000  root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1 quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 fbcon=map:0 net.ifnames=0 sdhci_tegra.en_boot_part_access=1 usbcore.usbfs_memory_mb=1000 dummy.numdummies=0 
Retrieving file: /boot/dtb/tegra210-p3448-0002-p3449-0000-b00.dtb
243260 bytes read in 71 ms (3.3 MiB/s)
## Flattened Device Tree blob at 80000000
   Booting using the fdt blob at 0x80000000
   reserving fdt memory region: addr=80000000 size=20000
   Using Device Tree in place at 0000000080000000, end 000000008003e63b
ERROR: DT property /psci/nvidia,system-lp0-disable missing in source; can't copy

at /dvs/git/dirty/git-master_linux/3rdparty/u-boot/arch/arm/mach-tegra/dt-edit.c:176/fdt_iter_copy_prop()

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.9.140-tegra (buildbrain@mobile-u64-4263) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #1 SMP PREEMPT Fri Oct 16 12:32:46 PDT 2020
[    0.000000] Boot CPU: AArch64 Processor [411fd071]
[    0.000000] OF: fdt:memory scan node memory@80000000, reg size 32,
[    0.000000] OF: fdt: - 80000000 ,  7ee00000
[    0.000000] OF: fdt: - 100000000 ,  7f200000
[    0.000000] Found tegra_fbmem: 00800000@92cb4000
[    0.000000] earlycon: uart8250 at MMIO32 0x0000000070006000 (options '')
[    0.000000] bootconsole [uart8250] enabled
[    0.621799] OF: /external-memory-controller@7001b000: could not find phandle
[    0.629115] ERROR: could not get clock /external-memory-controller@7001b000:emc(0)
[    0.637148] OF: /external-memory-controller@7001b000: could not find phandle
[    0.644435] ERROR: could not get clock /external-memory-controller@7001b000:emc_override(8)
[    0.653089] tegra210-emc 7001b000.external-memory-controller: Cannot find EMC override clock
[    0.661869] OF: /external-memory-controller@7001b000: could not find phandle
[    0.669155] ERROR: could not get clock /external-memory-controller@7001b000:pll_m(1)
[    0.677221] OF: /external-memory-controller@7001b000: could not find phandle
[    0.684504] ERROR: could not get clock /external-memory-controller@7001b000:pll_c(2)
[    0.692567] OF: /external-memory-controller@7001b000: could not find phandle
[    0.699849] ERROR: could not get clock /external-memory-controller@7001b000:pll_p(3)
[    0.707907] OF: /external-memory-controller@7001b000: could not find phandle
[    0.715178] ERROR: could not get clock /external-memory-controller@7001b000:clk_m(4)
[    0.723255] OF: /external-memory-controller@7001b000: could not find phandle
[    0.730534] ERROR: could not get clock /external-memory-controller@7001b000:pll_mb_ud(6)
[    0.738950] OF: /external-memory-controller@7001b000: could not find phandle
[    0.746229] ERROR: could not get clock /external-memory-controller@7001b000:pll_mb(5)
[    0.754372] OF: /external-memory-controller@7001b000: could not find phandle
[    0.761651] ERROR: could not get clock /external-memory-controller@7001b000:pll_p_ud(7)
[    0.769927] tegra210-emc 7001b000.external-memory-controller: Can not find EMC source clock
[    0.848679] OF: /thermal-zones/PLL-therm/cooling-maps/map-tegra-dram: could not find phandle
[    0.857426] missing cooling_device property
[    0.861759] failed to build thermal zone PLL-therm: -22

I didn’t see such issue when someone is using FDT to assign device tree.

It looks more like an issue that your current dts is not 100% same as the dtb when it is flashed to DTB partition.

The node /proc/device-tree on the device will show you how the device tree looks like. You can use it to compare the working and NG case.

I couldn’t tell you details, but wanted to add that sometimes earlier boot stages will use a partition-based tree, and that you might see different content for what is passed to the kernel versus what the earlier boot stages will see. Someone else would have to explain which partition device tree content goes where, and how one boot stage might edit before passing to the next boot stage.

1 Like

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