What are the folder relations in updating DTB on host

Autonomous Machines Jetson & Embedded Systems Jetson TX2
#1

Still struggling the DTB update on the host with no luck. The make scripts shows no error, but apparently the newly created DTB contains no updating. Before going deeper to the folder structure, I’d like to ask a simple question, what is the easiest way to modify the configuration such that we can see the result from fdtdump?

For example, if I ran “make menuconfig”, would a change in “General setup —> Local version” be reflected in the fdtdump? If not, what would be the other harmless tags could be used to test the flow?

Next let’s dive into the issue of folders.

To my knowledge, the updating of DTB on the host involves following folders:

Download the latest kernel, unpack it to a folder. Call it "kernel folder"
Download and unpack the GCC tool-chain, copy the install to a folder. Call it "toolchain folder"
Create a folder for scripts output, call it "output folder"
Specify the JetPack flash folder, which is the location to copy the newly created DTB and flash to TX2. Call it "flash folder"
Define the directory where all the scripts are executed. Call it "execution folder"
Under the execution folder, define a "kernel/kernel-4.4" path. call it "sub-path folder"

An example of my definition for the folder environment can be found in

In my case, is the same as . I separate them here as they are different in concept.

Given the setup, I found at least two .config files.

<execution folder> / <sub-path folder> / .config
<output folder> / .config

In my environment, I can see that running “make menuconfig” will impact the configuration in “ / .config”. However, my “make dtbs” apparently does not take the data from there.

Thanks in advance for sharing the insight.

#2

Let me use an example to show the operation in my flow.

To make tegra18_defconfig, the pseudo command would be:
make -C O= ARCH=arm64 CROSS_COMPILE=/bin/aarch64-unknown-linux-gnu- tegra18_defconfig

After editing the configuration, my make dtbs would be something like:
make -C O= ARCH=arm64 CROSS_COMPILE=/bin/aarch64-unknown-linux-gnu- TEGRA_KERNEL_OUT= dtbs

For real example, please see What are the minimum lines of commands to update device tree from a host for TX2? - Jetson TX2 - NVIDIA Developer Forums

By the way, I have tried both
$ sudo make -C $KERNEL_SUB O=$KERNEL_DIR ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE tegra18_defconfig
and
$ sudo make -C $KERNEL_SUB O=$TEGRA_KERNEL_OUT ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE tegra18_defconfig

The end results are the same. No change in the content of DTB (after make dtbs, and viewed by fdtdump).

#3

What file (DTS file) are you changing/adding in the hope of seeing something in the DTB after the “make […] dtbs”?

#4

@david_evans_g, I enabled the IMX219 sensor. I intended to start with switching the camera to Sony, perhaps to test out other sensors down the road.

So I ran “make menuconfig” to enable the entry IMX219. I also tried alternative approach by editing the .config file directly. Those operations seem working fine. Then I ran “make dtbs” with the options that I set in the environment, no complaints. But I don’t think the DTB got updated. Something apparently went wrong in the flow, or the setting of environment. There was no error message.

By the way, I added a random string to the “local version”, hoping to distinguish the DTB revision. Could that screwed up the process?

#5

Here is a URL which may explain some of the DTB update:
[url]https://elinux.org/Jetson/TX2_DTB[/url]

#6

Finally get the IMX219 sensor working on TX2. I took the approach of compiling DTS and DTSI using make dtbs on host, and compiling the kernel using JetsonHacks’ scripts on TX2.

A key to success is to make sure having all the files in the right place. Put DTS/DTSI in the corresponding device tree directories on host, and put C code and header files in the corresponding driver directories on TX2. Plus, make sure to override the default drivers. Don’t use the default driver code, I learned the lesson in a hard way, at least for the operation of IMX219 sensor.

I believe that the DTS and DTSI should be compiled on TX2 directly. There got to be an equivalent process that allows to “make dtbs” on TX2, like I did on the host. I wanted to avoid flashing from a host computer but only found the description of compiling device tree on TX2 using DT compiler to reverse the DTB to the source. But that approach would only give you a flat DTS file. De-compiling DTB is useful for a quick fix, but it’s difficult to manage the process and maintain the record without the hierarchy structure and the ability to track the comments. Hope the senior guys in the community could come up with something better and easier.

I’ll follow up with a full description of what and where about the device tree and kernel drivers.

#7

To build DTB on host, you need to have three items ready

  1. Source of latest kernel (matches what you have on TX2)
  2. GCC toolchain
  3. Device tree source and inclusion (DTS and DTSI) files.

In my case, I was using Sony sensor as a test case. I want to build DTB for my customized Raspberry Pi connector and IMX219 camera on J22 CSI expansion connector.

My environment can be found in What are the minimum lines of commands to update device tree from a host for TX2? - Jetson TX2 - NVIDIA Developer Forums

The kernel source is placed under /home/myuserid/work/tx2.
It’s worth of notice that there are two sub-directories underneath
kernel
and
hardware

The GCC toolchain is placed under /home/myuserid/toolchain/install.

For IMX219, the device tree source files have to be placed as follows.

  1. put tegra186-quill-p3310-1000-a00-00-base.dts under
    /home/myuserid/work/tx2/hardware/nvidia
  2. Put tegra186-camera-imx219.dtsi under
    /home/myuserid/work/tx2/hardware/nvidia/platform/t18x/common/kernel-dts/t18x-common-modules/
  3. Put tegra186-quill-camera-imx219.dtsi under
    /home/myuserid/work/tx2/hardware/nvidia/platform/t18x/common/kernel-dts/t18x–common-platforms/

Follow the step of compiling and flashing the DTB to TX2, as described in What are the minimum lines of commands to update device tree from a host for TX2? - Jetson TX2 - NVIDIA Developer Forums

On Tx2, follow the instruction of JetsonHacks. Make sure to place the drivers in the kernel directory, relative the top level path to the kernel, of which in my case is
/usr/src/kernel/kernel-4.4/

Copy
imx219.h
v4l2-chip-ident.h
to
include/media/imx219.h
include/media/v4l2-chip-ident.h

Copy
imx219.c
imx219_mode_tbls.h
to
drivers/media/i2c/imx219.c
drivers/media/i2c/imx219_mode_tbls.h

Run JetsonJacks scripts, reboot the system. That should be it.

#8

@tmx3
I have several questions here.

  1. Any modification in “tegra186-quill-p3310-1000-a00-00-base.dts”?
  2. After I use make[…] dtbs, the newly created DTB should contain no updating?
  3. To flash the DTB, I should followed this link Jetson/TX2 DTB - eLinux.org
    , right?
#9

@kaosun
After running the make commands, you should get a new DTB. See https://devtalk.nvidia.com/default/topic/1025464/what-are-the-minimum-lines-of-commands-to-update-device-tree-from-a-host-for-tx2-/?offset=6#5228121
Them you need to copy the new DTB to the flash source directory, which is

~/jetpack/64_TX2/Linux_for_Tegra_tx2/kernel/dtb

where assume you have installed the JetPack under ~/jetpack .

After that, run the flash command as suggested by Jetson/TX2 DTB - eLinux.org from directory ~/jetpack/64_TX2/Linux_for_Tegra_tx2

cd ~/jetpack/64_TX2/Linux_for_Tegra_tx2
sudo ./flash.sh -r -k kernel-dtb jetson-tx2 mmcblk0p1

I don’t have the correct dts yet, still testing my hardware.

#10

@tmx3
I tried your newly commands.

$ cd $BUILD_TOP 
$ sudo make -C $KERNEL_SUB O=$TEGRA_KERNEL_OUT mrproper
$ sudo make -C $KERNEL_SUB O=$TEGRA_KERNEL_OUT ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE tegra18_defconfig
$sudo make -C $KERNEL_SUB O=$TEGRA_KERNEL_OUT ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE TEGRA_KERNEL_OUT=$TEGRA_KERNEL_OUT dtbs

I also put the DTS/DTSI file at correct location, Then I compared newly generated dts file with old one, there’s slight different here. Is there any modification in “menuconfig”?

yx@xps9550:~/Desktop/diff$ diff new.dts old.dts
10c10
< 	nvidia,dtsfilename = "arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts";
---
> 	nvidia,dtsfilename = "/dvs/git/dirty/git-master_linux/kernel/kernel-4.4/arch/arm64/boot/dts/../../../../../../hardware/nvidia/platform/t18x/quill/kernel-dts/tegra186-quill-p3310-1000-c03-00-base.dts";
13c13
< 	nvidia,dtbbuildtime = "Dec 21 2017", "13:37:50";
---
> 	nvidia,dtbbuildtime = "Jul 20 2017", "00:50:45";
#11

From R28.1, you would need to flash partition 15 on TX2 with your dtb in order to have it be taken into account.

You may save the old one with:

sudo dd if=/dev/mmcblk0p15 of=mmcblk0p15.bin bs=512

and flash the new one with something like:

sudo dd if=$TEGRA_KERNEL_OUT/arch/arm64/boot/dts/tegra186-quill-p3310-1000-c03-00-base.dtb of=/dev/mmcblk0p15 bs=512

[EDIT: These commands are to be issued from the TX2, assuming the kernel is natively built on TX2]

#12

@Honey_Patouceul
Flash partition-15 is done on TX2 target without a host, if I understand the method correctly. I never tried before, though I’d love to take the approach if applicable. I heard the limitation is that you can’t do it with DTSi. It supports a flat DTS only (again, I’m not 100% sure). Please share your insight if you know any methods to compile hierarchical DTS with DTSi on TX2.

#13

@kaosun, I remember I got similar problem before. Okay, check you .config file, and see if you find the line “CONFIG_VIDEO_IMX219=y”.
If you don’t find it, add the line and place it before CONFIG_VIDEO_IMX274.
If you see the line but different value, such as CONFIG_VIDEO_IMX219=m, change it to
CONFIG_VIDEO_IMX219=y

There could be more than one .config files, make sure you edit the right one.

Another tip. Make sure you run the make in the “top” directory, it’s the place where the kernel source is unpacked.

Hope it helps.

#14

If you build your kernel and dtbs, I think dtsi is supported. I did that natively on R28.1 (thanks to @Linuxdev for advices) for using a patched DT in order to use overlay2 with nvoverlaysink gstreamer plugin (https://devtalk.nvidia.com/default/topic/1024472/jetson-tx2/using-overlay-2-in-l4t-28-1-with-tx2/post/5213583/#5213583). Not 100% sure, but maybe you would just build the DT with make dtbs without having to build a different kernel (in my case original kernel and similar config native build were both working).

#15

@tmx3
Still struggling to get differently dts file.
I’m pretty sure, the .config has been update after make menuconfig and enable imx219
and I still have the same dts file as before

#16

Kernel build target “make dtbs” builds device tree binaries. Don’t forget any other options, e.g., “make O=$TEGRA_KERNEL_OUT…”…or whatever options you need.

#17

@kaosun, are you running your make command from the directory where you see “kernel” and “hardware” subdirectories?

Check the kernel directory has a “kernel-4.4” subdirectory under it.
Check the DTSi files are placed under the relative places under the “hardware” directory.

By the way, I need to edit my post What are the minimum lines of commands to update device tree from a host for TX2? - Jetson TX2 - NVIDIA Developer Forums and correct a mistake in step 6. It should be “sudo make -C $KERNEL_SUB O=$TEGRA_KERNEL_OUT ARCH=arm64 CROSS_COMPILE=$CROSS_COMPILE tegra18_defconfig”.

#18

It might be useful to emphasize that the above “make” command uses the “-C $KERNEL_SUB” option. This tells make to cd to that directory first…if “KERNEL_SUB” environment variable is not substituted with the path to the kernel source top level directory with the Makefile, then this will fail. To run without the “-C” option you’d have to cd to that kernel source directory before starting. Make sure your KERNEL_SUB is set correctly, or that you don’t use the “-C” option and start in the correct directory (I tend to favor the environment variable option since I write scripts for setting up environment and then things “just work” with the same generic command…it separates commands from per-build setup).

#19

@linux, you made a good point.

#20