FDT error Jetson Tx2 with R28.2.1 package

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hi,

We are trying to update DTB in U-boot by including FDT entry inside extlinux.conf file but seeing below Error.

U-Boot 2016.07 (Jul 04 2018 - 09:55:39 +0000)

TEGRA186
Model: NVIDIA P2771-0000-500
DRAM: 7.8 GiB
MC: Tegra SD/MMC: 0, Tegra SD/MMC: 1
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@2490000
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:18…
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
386 bytes read in 10 ms (37.1 KiB/s)
Boot Options
1: primary Image
Enter choice: 1: primary Image
Retrieving file: /Image
reading /Image
21028984 bytes read in 2478 ms (8.1 MiB/s)
append: console=ttyS0,115200 memtype=0 video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x03100000 nvdumper_reserved=0x2772e0000 gpt tegrai4
Retrieving file: /tegra186-quill-p3310-1000-c03-00-base.dtb
reading /tegra186-quill-p3310-1000-c03-00-base.dtb
279208 bytes read in 51 ms (5.2 MiB/s)

Flattened Device Tree blob at 82200000

Booting using the fdt blob at 0x82200000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000082200000, end 00000000822472a7
WARNING: could not set reg FDT_ERR_NOSPACE.
ERROR: arch-specific fdt fixup failed

  • must RESET the board to recover.

FDT creation failed! hanging…### ERROR ### Please RESET the board ###

I even tried to update DTB using “fatload” command manually as below from u-boot, but still same error.

Tegra186 (P2771-0000-500) #
Tegra186 (P2771-0000-500) # fatload mmc 1:18 82200000 /pri/tegra186-quill-p3310-1000-c03-00-base.dtb
reading /pri/tegra186-quill-p3310-1000-c03-00-base.dtb
279208 bytes read in 55 ms (4.8 MiB/s)
Tegra186 (P2771-0000-500) # setenv fdt_addr 82200000
Tegra186 (P2771-0000-500) # saveenv
Saving Environment to MMC…
Writing to MMC(0)… done
Tegra186 (P2771-0000-500) # boot
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:18…
Found U-Boot script /boot.scr
reading /boot.scr
782 bytes read in 14 ms (53.7 KiB/s)

Executing script at 82400000

**** P-EdgeOS boot script ****
*** Load pri/sec specific variables ***
reading /pri/uEnv.txt
1604 bytes read in 18 ms (86.9 KiB/s)
*** Boot P-EdgeOS***
Saving Environment to MMC…
Writing to MMC(0)… done
Retrieving file: /pri/extlinux.conf
reading /pri/extlinux.conf
385 bytes read in 11 ms (34.2 KiB/s)
Boot Options
1: primary Image
Enter choice: 1: primary Image
Retrieving file: /pri/Image
reading /pri/Image
21028984 bytes read in 2474 ms (8.1 MiB/s)
append: root=/dev/mmcblk0p1 rw rootwait console=ttyS0,115200n8 console=tty0 OS=l4t fbcon=map:0 net.ifnames=0 memtype=0 video=tegrafb no_console_suspen8

Flattened Device Tree blob at 82200000

Booting using the fdt blob at 0x82200000
reserving fdt memory region: addr=80000000 size=10000
Using Device Tree in place at 0000000082200000, end 00000000822472a7
WARNING: could not set reg FDT_ERR_NOSPACE.
ERROR: arch-specific fdt fixup failed

  • must RESET the board to recover.

FDT creation failed! hanging…### ERROR ### Please RESET the board ###

I am seeing this behavior with latest R28.2.1(Jetpack_3.2.1) release. We were using above methods to update DTB with Jetpack3.0 release. Could any one suggest solution for this?

2

None of the current releases support the FDT entry in extlinux.conf. This needs to go into a partition, and in the most recent releases the tool will also sign the dtb. See:
https://elinux.org/Jetson/TX2_DTB

If you want to test if the DTB update actually occurred, then extract from the running Jetson and compare to what you expected:

dtc -I fs -O dts -o extracted.dts /proc/device-tree
3

Thanks for the response.

Yes c-boot is loading dtb from kernel-dtb partition.
We are looking for a mechanism to load our modified dtb(which will be available in boot partition) inside U-boot and update fdt_addr to the loaded location for kernel.

4

“flash.sh” from the driver package would do this. The URL in the previous post shows how, details differ depending on release.

5

Hi vinod.kumar,

Could you take a look at [url]https://devtalk.nvidia.com/default/topic/1035622/jetson-tx2/in-system-update-of-dtb-in-r28-2/post/5262418/#5262418[/url]?
Because current boot process, prior to u-boot, will modify device tree at runtime, this is the ways to update dtb with/without using flash commands.

6

Thanks for the details.

Our intention is not to use host interface to update DTB by using flash.sh/tegraflash.py scripts. we use sdcard image to flash eMMC of the board(in system update).We generate full sdcard image and update eMMC by “dd” ing sdcard_image to eMMC of board. So before writing new image to eMMC we would like to ensure functionality of new DTB and Kernel Image. Till R28.1 release through uboot scripts we changed “fdt_addr” to some RAM location and used FDT cmd option in “extlinux.conf” to load new DTB to RAM and boot with new DTB and kernel. If system boots successfully then one of the startup scripts updates eMMC with new sdcard image(dd) and reboots.

In R28.2.1 as FDT option is not supported, wondering is there any other methods where we can ensure new image functionality before doing in system update.

Currently we are booting by using old DTB(from DTB partition) + new kernel image combination and successful boot follows in system update. It is not desired mechanism, would like to know for any other better methods or solution for this.

Thanks.

7

FYI, as of R28.2 device trees are signed. In the L4T directory “Linux_for_Tegra/bootloader/” you will find the tegraflash.py script, which in turn uses a couple of other python scripts (one being compiled Cython), and in the end the binary executable “tegrasign_v2” is called to do the actual signing. Interesting in this case is that you can run:

./tegrasign_v2 --help

I’m not a python guy (I really should learn more), but it might be possible from observing a flash how to use this script by itself, followed by copy of the signed dtb via dd. I don’t know though, I have not tried. In a flash log it looks like this:

[   0.0337 ] tegrasign_v2 --key None --list rcm_list.xml --pubkeyhash pub_key.key
[   0.0371 ] Assuming zero filled SBK key

The trouble is that I have no idea what keys are used, nor what kind of hash is performed, so I couldn’t tell you how to emulate this without tegrasign_v2. And tegrasign_v2 is 32-bit PC, so it can only be used on a Linux desktop PC with 32-bit compatibility libraries.

If you really really need this you might perform a flash and edit flash.sh (or the tegraflash.py script) to log strace and ltrace during call of tegrasign_v2 to figure out which OpenSSL utilities are being used (and their arguments). If that information is known, then you could sign without depending on the driver package scripts.

8

Vinod,

I am in the same boat. used FDT dtb & kernel on sdcard on TX1. Now need to do the same on TX2 with latest greatest.
Any luck with DTB built into kernel?

9

Details depend on which release you have. More recent releases require using the flash tools to put any modified tree in place. The tree has become a partition instead of a file system device, and some content is also signed.