Flashing device tree from L4T 32.5.1

igal.kroyter · August 31, 2021, 3:41pm

Hi,
Upon Device Tree (DT) modification and compilation the file was copied to a host and flashed successfully but when I tried to verify whether the DT is actually flashed I found that some fields which were expected to be modifed where not.

I am flashing the tegra186-quill-p3310-1000-c03-00-base.dtb file, which was positioned in the directory

/home/nvidia/HWImage/JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/kernel/dtb

the command to flash is

sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

and the command to see what actually was programmed is

sudo dtc -I fs -O dts -o my.dts /proc/device-tree

Regards.

JerryChang · September 1, 2021, 2:23am

hello igal.kroyter,

it looks correct commands to update device tree partition.
however, please see /boot/extlinux/extlinux.conf, it’ll load device tree via file system if you’re having FDT entry there.
thanks

igal.kroyter · September 1, 2021, 5:43am

Hi @JerryChang,
no FDT entry in the extlinux.conf file.

Is there anything else that might load an incorrect dtb file?

JerryChang · September 1, 2021, 6:10am

hello igal.kroyter,

please confirm kernel messages to check you’ve update the device tree blob correctly.
for example,
$ dmesg | grep DTS it shows the absolute path of your dtb binary, it shows the path of your local host machine if you building that by yourself.
in addition, $ dmesg | grep " DTB Build time" it could indicate the building time of this binary file.

igal.kroyter · September 1, 2021, 6:23am

hi @JerryChang ,

It looks like the wrong dtb file is loaded by the unit during boot:

nvidia@nvidia-desktop:~$ dmesg | grep DTS
[ 0.184410] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
[ 0.442127] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts
nvidia@nvidia-desktop:~$ dmesg | grep “DTB Build time”
[ 0.184426] DTB Build time: Jun 14 2021 11:44:16
[ 0.442155] DTB Build time: Jun 14 2021 11:44:16

BTW I’ve DTCed the following files and they resemble the file system DT (the current system’s DT, NOT mine):

/boot/dtb/kernel_tegra186-quill-p3310-1000-c03-00-base.dtb
/boot/tegra186-quill-p3310-1000-c03-00-base.dtb

Now I do not understand why the host indicated that the dtb file was successfully flashed - I’m 100% sure that the correct file (correct path) was utilized (encrypted, converted, etc.) on the host - **tegra186-quill-p3310-1000-c03-00-base.dtb
A file of the flashing log:flashing from host.txt (21.5 KB)

JerryChang · September 1, 2021, 6:43am

hello igal.kroyter,

by checking file path and build time isn’t quite efficient if you’d disassembler/resemble the binary.
you should look into disassembler file, there’re dtsfilename and dtbbuildtime, what’s parse by kernel side.

may I also know what’s your commands to disassembler/resemble the binary?
for your reference,
to disassembler the dtb file into text file ,$ dtc -I dtb -O dts -o temp.dts tegra.dtb
to convert the DTS into a new DTB, $ dtc -I dts -O dtb -o output.dtb temp.dts

igal.kroyter · September 1, 2021, 7:51am

hi, @JerryChang,

I disassamble the file-system DT per Flashing device tree from L4T 32.5.1, while a dtb file per your note.
Assemble/compile the device tree is applied in the kernel directory on the system (NOT host)

make dtbs

I am sure that my assembly is correct as I’ve diassembled the file both on the system and on the host (just to make sure that the correct file was copied to the correct directory on the host).

following are the fields that you asked, which were taken from the disassembled file:

/home/nvidia/HWImage/JetPack_4.5_Linux_JETSON_TX2/Linux_for_Tegra/kernel/dtb/tegra186-quill-p3310-1000-c03-00-base.dtb

nvidia,dtsfilename = “arch/arm64/boot/dts/…/…/…/…/…/…/hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts”;
…
nvidia,dtbbuildtime = “Aug 31 2021”, “17:05:44”;

Moreover, I’ve read the following links:
https://forums.developer.nvidia.com/t/flash-kernel-dtb-failed/144544/5
https://forums.developer.nvidia.com/t/flash-kernel-dtb-not-work/177836/22
https://forums.developer.nvidia.com/t/flashing-dtb-on-jetson-tx2-l4t-32-4-4/170479
https://forums.developer.nvidia.com/t/device-tree-doesnt-flash-on-tx2/167284
https://forums.developer.nvidia.com/t/how-to-update-dtb-of-tx2-without-flashing/148122
https://forums.developer.nvidia.com/t/how-to-use-uart0-as-normal-uart-port-on-r28-1/52790/20
None helped, though it got me thinking whether the DT is flashed to the correct partition, because I used the same command with the L4T 28.1 which worked in the past:

sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

Regards.

JerryChang · September 2, 2021, 6:55am

hello igal.kroyter,

there’s CBoot functionality to load device tree blob via file system.
so, could you please have another way to load your disassembler/resemble binary on the target,
you should modify /boot/extlinux/extlinux.conf and add FDT entry to point to your new dtb file.
here’s documentation for your reference, check CBoot session for details.
thanks

igal.kroyter · September 2, 2021, 11:33am

hi @JerryChang,

I have reinstalled the system and the SDK 4.5.1 with L4T 32.5.1 and the programming was successful.
Thanks for the support.

igal.kroyter · September 3, 2021, 12:53pm

@JerryChang, hi,

I have to reopen the issue, it looks like once I run

sudo apt-get install upgrade

The new installation which, actually, takes a long time evenually brings up a system which denies the flahisng to take affect. In preiovius tries just before installing a fresh installation via the SDK I’ve applied the upgrade just before trying to flash a DT. This got me to the conclusion that something in the upgrade affects the flashing process.

Again, after upgrading and rebooting, the host claims that the flash is OK but the actual DT in /proc/device-tree is not identical to the flashed dtb file just flashed.

BTW, I’ve tried to add the FDT to the /boot/extlinux/extlinux.conf file pointing to the dtb file and looked like it is loaded(the terminal displayed that it is ‘FDTing’) but after stating that the kernel is starting (in the terminal) the system got stucked.
I left the dtb file in the /boot directory and remove the FDT line, and then “my” dtb file was loaded. Moreover, I can see it affects on system behaviour. Is this the correct way from now on to “flash” device tree?

To sum up the above:

with FDT (in extlinux.conf file)- system get stucked
flashing after upgrading - does not load the flashed dtb file.
copying a dtb file to /boot directory seemed to work but after upgrading it does not work anymore.

Could you please advise?

JerryChang · September 6, 2021, 2:54am

hello igal.kroyter,

for your reference.
there’s JetPack-4.5.1 known bug related to FDT selection, please check Topic 180197, #14 for the backgrounds.
we’ve include the fixes to JetPack-4.6, and please moving to the latest release if possible.
thanks

igal.kroyter · September 6, 2021, 6:00am

@JerryChang hi,

I’ll try your suggestion, as currently we were required to utilize the L4T 4.5.1 version.

Though, my initial approach was to flash the device tree from a host. Is it officially not used anymore?

JerryChang · September 6, 2021, 6:39am

hello igal.kroyter,

would like to confirm what’s going-on after you upgrade the system.
may I know which version does sudo apt-get install upgrade moving your packages to?
could you please check the details logs and gather them for reference.
thanks

igal.kroyter · September 6, 2021, 7:08am

@JerryChang hi,

I hope that the following is suffice:

JerryChang · September 7, 2021, 1:29am

hello igal.kroyter,

could you please have a try to update the u-boot binary with the attachment, i.e. Topic180197_Jun17_u-boot.zip (268.2 KB)
please perform partition update to flash kernel partition to update uboot binary.
for example, $ sudo ./flash.sh -r -k kernel jetson-tx2 mmcblk0p1

igal.kroyter · September 7, 2021, 7:11am

@JerryChang hi,

could you please confirm whether the uboot.bin file should be copied to:

/home/nvidia/HWImage/JetPack_4.5.1_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/t186ref/p2771-0000/500 or

/home/nvidia/HWImage/JetPack_4.5.1_Linux_JETSON_TX2/Linux_for_Tegra/bootloader/t186ref/p2771-0000/000

and then the following command should be applied on the host machine?

sudo ./flash.sh -r -k kernel jetson-tx2 mmcblk0p1

Regards.

JerryChang · September 7, 2021, 7:18am

hello igal.kroyter,

please refer to your TX2 for the Uboot messages,
for example, it’s 500 for my reference platform.

U-Boot 2016.07-ge6da093be3 (Jun 25 2020 - 21:14:32 -0700)
TEGRA186
Model: NVIDIA P2771-0000-500

once you overwrite the uboot binary, please put your TX2 enter forced-recovery mode, and please execute that flash commands on your host machine to perform partition update.
you should also see the build time has update from the uboot logs if you’ve update it correctly.
thanks

igal.kroyter · September 7, 2021, 7:55am

hi @JerryChang,

Though I’ve applied the flahing command I could not fin any indication for utilizing the u-boot.bin file, is it OK?

another puzzeling thing is the fact that when I looked in the terminal loog for the Model I found that the unit’s model is: NVIDIA P3636-0001 where did it come from? I was using NVidia tools and have configured nothing specifical…

Please advise.

JerryChang · September 7, 2021, 8:21am

hello igal.kroyter,

you’re working with TX2 NX, right?
please modify the command-line to assign the correct platform for flashing.

igal.kroyter · September 7, 2021, 8:37am

hi @JerryChang,

it is a normal TX2. NOT TX2 NX.