Checking if device tree includes my modifications

Robotics & Edge Computing Jetson & Embedded Systems Jetson Nano
1

I’ve lately tried to create a driver and device tree entry for a camera sensor, and I’ve come to the point where it’s time to build the kernel and device tree to test it out. I’ve been following the guide at Building the Nvidia kernel to build the kernel and device tree and am aiming to register the device Using the Main Platform Device Tree File (since I’ve a devkit with an SD-card).

So I’ve succeeded in building the Image and modules and a number of dtb-files – but I am confused in how I can know that the “main” dtb-file has included my modifications.

It doesn’t help that I’m also confused regarding that multiple dtb-files have been built.

I’m assuming that I should replace

/boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

with its namesake at

$TEGRA_KERNEL_OUT/arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb

however, probing it like so (where ‘mlx’ is part of my device’s name):

dtc -I dtb $TEGRA_KERNEL_OUT/arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb | grep 'mlx'

returns nothing of interest.

Though doing the same with

dtc -I dtb $TEGRA_KERNEL_OUT/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dtb | grep 'mlx'

or (EDITED COMMAND)

dtc -I dtb $TEGRA_KERNEL_OUT/arch/arm64/boot/dts/tegra210-jetson-cv-p2597-2180-a00.dtb | grep 'mlx'

shows me my changes.

My understanding is that the device tree binary should be a single dtb-file; or at the very least that the “main” dtb-file would include other dtb-files – but I can’t see any reference to any other dtb-file in

/boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

So what am I missing, and how can I know that my changes will be included?

Thank you!

EDIT
I had copied the wrong command before

2

Don’t forget the “=” between “TEGRA_KERNEL_OUT” and the actual file path.

Note that this file will be ignored unless the “/boot/extlinux/extlinux.conf” names the path with the FDT key. If no such key exists in the boot entry, then the content would be read from the partition instead. If you flashed with your tree in place within the flash software, then I’d expect your tree to be correctly in the partition (or QSPI memory of an SD card model). Example entry:

FDT /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb
1 Like
3

Thank you for your rapid response @linuxdev!

$TEGRA_KERNEL_OUT

is already part of the path to my built dtb-files, I should’ve been clearer about that.

I haven’t gotten to the extlinux.conf yet (I’ve been reading your earlier replies in other threads regarding the device tree, and you have my thanks for those as well!) since I wanted to make sure that the device tree had my changes first. Do you know of any way to do that?

5

hello JohanPi,

please check this via system nodes, i.e./proc/device-tree/
for example, if you’re mounting an IMX185 camera sensor, system will load device tree blob with the following device tree settings.
$L4T_Sources/r32.6.1/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/tegra194-camera-imx185-a00.dtsi

	tegra-camera-platform {
		modules {
			module0 {
				badge = "imx185_bottom_liimx185";
				position = "bottom";

and…
you can login with root permission and check the nodes to confirm the property values.
for example,

$ sudo -i
$ cat /proc/device-tree/tegra-camera-platform/modules/module0/badge
2 Likes
6

Thank you for your reply @JerryChang!

So I followed @linuxdev 's note and added

FDT /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

to the entry in /boot/extlinux/extlinux.conf, and copied my newly built tegra210-p3448-0000-p3449-0000-b00.dtb there; followed by a reboot.

I then tried

sudo -i
cat /proc/device-tree/tegra-camera-platform/modules/module0/badge

however, that only produces porg_front_RBPCV2, which isn’t right.

I’ve also tried

ls /proc/device-tree/host1x/i2c@546c0000/

but I can’t find the device there.

Also

dtc -I fs /sys/firmware/devicetree/base | grep 'mlx75'

doesn’t produce anything related.

I’m guessing that the device needs to be connected to show up in anyway in /proc/device-tree/, but I’ve tried all of these with not having the device connected; having it connected and streaming to each of the camera connectors (not sure if that should matter either); as well as all of the above after changing the FDP line to

FDT /home/nano/kernel/kernel_out/arch/arm64/boot/dts/tegra210-p3448-0000-p3449-0000-b00.dtb

(the original path to the newly built tegra210-p3448-0000-p3449-0000-b00.dtb-file). But I find no difference.

Do I need to force a device-tree update or something like that after I’ve connected and started streaming from the device?

EDIT:
I checked the dmesg right after boot and the only device tree-related entries I find are

[    0.212257] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
[    0.212266] DTB Build time: Oct 16 2020 12:38:12
...
[    0.428774] DTS File Name: /dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts
[    0.428783] DTB Build time: Oct 16 2020 12:38:12

Though I’m not sure if that necessarily means that my new device tree hasn’t been loaded.

7

Can I verify if this is an SD card model, versus eMMC model? If and only if it is eMMC, have security fuses been burned? Mostly I expect you would be working with the SD card model and no security fuses burned. In that case the FDT entry should work.

You can reverse compile the binary tree (the “.dtb” file) and use an ordinary text editor to see if your changes made it in. Example:
dtc -I dtb -O dts -o reverse_compiled.dts /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb
…then examine reverse_compiled.dts. If changes are there, but not in “/proc/device-tree”, then your tree was not loaded (or else was edited).

8

hello JohanPi,

please disassembler your dtb binary file into text file for examination,
i.e. $ dtc -I dtb -O dts -o output.txt tegra210-p3448-0000-p3449-0000-b00.dtb

please also refer to Device Registration session, since you’re having your driver implementation.
you may consider disable plugin-manager and using the main platform device tree file to register your sensor driver.
thanks

9

Yes it is an SD card model. It is a devkit with two camera ports.

Checking the output from

dtc -I dtb -O dts -o reverse_compiled.dts /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

shows none of my changes (this is part of what made me post the topic in the first place).

I think a big part of my confusion comes from that building the kernel results in a large number of dtb-files in $TEGRA_KERNEL_OUT/arch/arm64/boot/dts/: 22 of them to be exact (and 12 dtbo-files, plus a _ddot_-directory with copies of all of them). And whereas tegra210-p3448-0000-p3449-0000-b00.dtb don’t show my changes, tegra210-jetson-cv-p2597-2180-a00.dtb as well as tegra210-jetson-cv-base-p2597-2180-a00.dtb do.

This makes sense to me as the tegra210-p3448-0000-p3449-0000-b00.dts from the porg directory does not seem to include anything from the jetson directory where for instance tegra210-jetson-cv-p2597-2180-a00.dts is.

So I’m assuming that at least tegra210-jetson-cv-p2597-2180-a00.dtb (since tegra210-jetson-cv-base-p2597-2180-a00.dts is included in its source) somehow should be added to or included in tegra210-p3448-0000-p3449-0000-b00.dtb but I have no idea how to do that. Is there a step where they are merged that I’m missing?

I’ve also tried to simply copy all 34 files (22 dtb and 12 dtbo) into /boot/dtb but that didn’t work of course.

@JerryChang, regarding device registration I have been working with the main platform device tree file-approach to the best of my ability, and have disabled the plugin-manager.

10

I don’t know which files are used where within kernel builds of a device tree. However, if you know what the tree change is, then you could just decompile “tegra210-p3448-0000-p3449-0000-b00.dtb”, edit the decompiled source, and then recompile. I would suggest using an altered name to prevent being overwritten, and then edit the “extlinux.conf” to match this altered name. Example decompile:

dtc -I dtb -O dts -o tegra210-p3448-0000-p3449-0000-b00_modified.dts /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb

Then edit the “modified” dts, followed by recompiling:

dtc -I dts -O dtb -o tegra210-p3448-0000-p3449-0000-b00_modified.dtb /where/ever/it/is/tegra210-p3448-0000-p3449-0000-b00_modified.dts

Then copy “tegra210-p3448-0000-p3449-0000-b00_modified.dtb” into “/boot/dts”, followed by either adding an alternative boot entry with this in “extlinux.conf”, or else editing the FDT tag to name the new file name. Then reboot.

As a note, when the kernel builds device trees, it looks at the list of included drivers and hardware support. If that results in finding a need for a device tree, then it inserts a subset of device tree content into a list of device tree items to combine. Then it produces the source and binary device tree made from that combination of “snippets”. If you’ve modified the snippet, then the final tree should also be modified (unless the snippet was something not enabled as a relevant feature).

11

hello JohanPi,

may I know which SKU it is? please also check this page for the comparison of A02 and B01.

you should also refer to flash messages, it’ll parse the board info and flash the device tree accordingly.
for example,

[ 260.8830 ] Writing partition DTB with tegra210-p3448-0000-p3449-0000-a02.dtb.encrypt
[ 260.9492 ] [................................................] 100%

for a quick try,
you may disassembler the dtb file into DTS file for edit the property values, and convert it into a new DTB file for testing,
for example,
$ dtc -I dtb -O dts -o temp.dts input.dtb
$ dtc -I dts -O dtb -o output.dtb temp.dts

12

I sort of followed your advice, but since I still see value in staying close to the “proper” way of doing things I took another approach.

Earlier I think I followed the examples in the documentation too closely, and stared myself blind at the ov5693 and imx185 examples; because I added my changes to the DTS and DTSI files, as well as my own files, in the same directories as the examples, i.e. <source>/hardware/nvidia/platform/t210/jetson/.... However, the relevant DTS tegra210-p3448-0000-p3449-0000-b00.dts in <source>/hardware/nvidia/platform/t210/porg/... of course does in fact not include anything from .../jetson/... – only from .../porg/... (I should’ve trusted my initial hunch about the lack of relevant inclusions from the beginning).

So I moved my files and altered the relevant includes in tegra210-porg-p3448-common.dtsi, and compiling the device tree now clearly shows my changes in tegra210-p3448-0000-p3449-0000-b00.dtb.

So, success! Thank you @linuxdev and @JerryChang for your help so far!

However, placing the new tegra210-p3448-0000-p3449-0000-b00.dtb in /boot/dtb/and providing the FDT /boot/dtb/tegra210-p3448-0000-p3449-0000-b00.dtb line in /boot/extlinux/extlinux.conf, does not alter the device tree after a reboot. It is most definitely the old device tree that is still getting loaded somehow.

@JerryChang, I have the B01 board.
Running

cat /proc/device-tree/nvidia,dtsfilename

gives

/dvs/git/dirty/git-master_linux/kernel/kernel-4.9/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t210/porg/kernel-dts/tegra210-p3448-0000-p3449-0000-b00.dts

so SKU should be 0000.

I’ve never got a definite answer if flashing was necessary or not for the devkit, and since I didn’t have a suitable host computer at hand and was confused about the dtb compilation I haven’t tried that yet. But I should get my hands at a host soon, so I’m going to try flashing next, unless there is something else I can try as well?

13

hello JohanPi,

you may flash the target to perform partition update for confirmation.
note, there’re two ways for device to load device tree blob binary, (1) via DTB partition, or (2) via file system (i.e. FDT entry);
and, the later approach to load by file system have higher priority then loading from DTB partition.

1 Like
14

A serial console full boot log should show some indication of which tree is being loaded, or if it fails, why. The initial boot content of an SD card model comes from the QSPI memory on the module, but the final device tree, if named in extlinux.conf should be the one loaded right as the kernel itself is loaded. A serial console log will show boot logs from prior to the Linux kernel loading (and any load of device tree), while other logs will only show from the moment the kernel is actually loaded.

Btw, if you want good logs, then remove the “quiet” from any configuration being used in “extlinux.conf”.

1 Like
15

While I was setting up my host computer and ordered a serial cable I decided to try again but with the latest available SD-card image – and that worked!

So in short: I made my changes in the (relevant) DT files, built the kernel, and edited /boot/extlinux/extlinux.conf to include a FDT entry pointing to the new DTB-file.

I still don’t know what the issue was before, and its not optimal that I need to start again from a new image, but I’m still happy. My best guess is that the issue came from that the initial setup of my old image was made on the older Nano devkit (the A02), and was then transferred to the current B01 board.

In any case, thank you @JerryChang and @linuxdev for your patience and support in this, I really appreciate it!

17

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