>>Q1
please works with t234, actually, you should refer to Orin NX’s device tree sources under $public_sources/kernel_src/hardware/nvidia/platform/t23x/p3768/ for development.
>>Q2
as you may know, it’s later include device tree (or, overlays) to update the status to enable the node.
here’s an example, $public_sources/kernel_src/hardware/nvidia/platform/t23x/p3768/kernel-dts/cvb/tegra234-p3768-camera-rbpcv3-imx477.dtsi
>>Q3
you’ll see a main device tree to include all camera device trees. $public_sources/kernel_src/hardware/nvidia/platform/t23x/p3768/kernel-dts/cvb/tegra234-p3768-0000-a0.dtsi
>>Q4
please refer to developer guide, To Create and Apply a DTB Overlay File.
you may see-also kernel implementation, it’s a configuration within $public_sources/kernel_src/kernel/nvidia/drivers/media/i2c/Makefile
Hi,
Thank you for your help.
First I wish to emphasize that this is my first experience with adding sensor/new device support , therefore I’m relying heavily on the dev guide and its examples. Since they are not suitable for t234 I’m asking you more questions to understand.
Q1:
On the one hand the camera developing guide refers to imx185 sensor as a base reference, while
on the other hand there is no imx185 device tree source file under $public_sources/kernel_src/hardware/nvidia/platform/t23x/p3768/
so what to do?
Q2-Q3:
I’m asking specifically regarding this string:
imx185_cam0: imx185_a@1a
1a is the I2C slave address
what is imx185_a ? just a name? or a specific node’s name?
what is imx185_cam0 ? just a name? or a specific node’s name? and where to put it?
I think my missing piece here is related to distinguish between two separate nodes of the same device:
one needs to be under the I2C node
other needs to be under the tegra-camera-platform node?
If so, the guide states how and where to put the tegra-camera-platform sub node but how I know where to put the I2C sub node?
It will be much helpful to get some elaboration here since I’m a little bit confused I think.
Q4:
To make sure I understand, the following line for example:
means that if i add: CONFIG_I2C_IOEXPANDER_SER_MAX9295=m/y in the defconfig file
than it will compile the suitable sources for max9295.o upon kernel build?
>>Q1
note, I’ve point-out t23x/p3768/ since you’re developing based-on Orin NX.
due to different camera connector, there’s no IMX185 device tree for Orin NX/Nano series.
so… please refer to IMX185 reference driver with Jetson AGX Orin series. (i.e. t23x/concord/)
for instance,
you may check below two device tree for reference.
(1) it’s device tree with IMX185 sensor specific settings. $public_sources/kernel_src/hardware/nvidia/platform/t23x/common/kernel-dts/t234-common-modules/tegra234-camera-imx185-a00.dtsi
(2) here’s camera control specific settings. $public_sources/kernel_src/hardware/nvidia/platform/t23x/concord/kernel-dts/cvb/tegra234-p3737-0000-camera-imx185-a00.dtsi
>>Q2, Q3
yes, that’s just an unique string. usually, we used CSI-port and I2C slave address to specify a camera node.
in this example, imx185_a@1a,
it means it’s IMX185 for using CSI port-A, which is under I2C at 0x1a.
>>Q4
yes, it’s just a variable,
you may use CONFIG_I2C_IOEXPANDER_SER_MAX9295=m to build as a module. (*.ko)
or, CONFIG_I2C_IOEXPANDER_SER_MAX9295=y to always build-in the driver with the kernel image.
Now:
I wish to locate the file containing “imx185_cam0” and modify this node to “my_new_sensor_cam0”. (it appears in a snapshot in the devguide)
My question is:
3.1. where to do it? where is this node should be and where is the reference.
From your answer I understand its related to the i2c tree. Do I copy & modify it (like in step 1) or just modify it and replace the node’s name from “imx185_cam0” to “my_new_sensor_cam0”
3.2. The confusing part is that in addition to “imx185_cam0” which is related to i2c (that i need to modify for my new sensor) there is additional node related to i2c but there is no “imx185_cam0” in it. The node is: i2c@3180000->tca9546@70->i2c@0->imx185_a@1a
why there are 2 different nodes related to i2c and how I modify both of them for my new sensor?
for example, in my new sensor .dtsi it will be: " i2c@3180000->tca9546@70->i2c@0->my_new_sensor@[i2c slave addr]" ?
Step 4: Create dt overlay as the devguide instructs and use the Jetson-IO tool
besides modify the node’s name to your my_new_sensor_cam0, please also refer to Port Binding section to update the port definition accordingly.
you may also have examination by… To verify the port binding result.
please check the reference drivers for development.
you may either check AGX Orin’s IMX185 sensor driver, or, you may check IMX219 or IMX477 on Orin NX/Nano.
that’s same as my explanations in previous comment #5.
there’re one device tree with sensor specific settings, the other device tree for camera control (and, Jetson board) specific settings.
Thank for your reply.
I have a question please regarding the DTB Overlay (the answer not appears in the dev guide)
I created two new files:
a) tegra234-camera-new-sensor.dtsi (sensor device tree)
b) tegra234-p3767-camera-new-sensor.dts (dt overlay)
(like the imx477 reference there is no include statement between them)
How I compile both files into one .dtbo? (I need to “attach” both files even tough there is no include between them)
For exmaple: dtc -O dtb -o new_sensor.dtbo -@ tegra234-p3767-camera-new-sensor.dts
it looks an incorrect commands.
please execute the following to convert the DTS into a new DTB file.
i.e. $ sudo dtc -I dts -O dtb -o new-output.dtb temp.dts
furthermore,
please check the configuration file /boot/extlinux/extlinux.conf
it’s FDT entry for device tree blob; OVERLAYS for device tree overlay.
please note that, You can specify FDT alone. You can specify FDT + OVERLAYS. You cannot do only OVERLAYS though.
Thanks for your answer.
I have additional questions by your permissions:
when I convert the dts to dtb, there is no connection between the .dtsi with all the sensor/csi/vi properties-values pairs and the .dts which contain the fragment property.
There is no include statement between them.
So how the compiler knows to take both the .dts which contains the fragment and overlay properties and the .dtsi which contain the sensor/csi/vi properties and combine them into one binary?
My sensor is actually a deserializer that generates pattern. using i2c tools like i2cdetect I saw that the sensor is on i2c bus num 9. Where in the .dtsi I mention this detail? (I wrote the slave address but didn’t write the I2C bus number)
>>Q1
please refer to developer guide, Building the Kernel.
you may try to build from sources, it’s a bad practice to use dtc utility to convert dtsi file into device tree blob.
Hi @JerryChang,
I apologise but I didn’t understand you.
I wish to get back to the start just to make sure we both aligned and save confusion.
My setup is: FPD Link III de-serializer which acts as a pattern generator connected to the Orin NX via 2x MIPI CSI.
I use the sensor programming guide. The problem is that its outdated. It doesn’t contains explanations nor examples for Jetsons based on t234 chips (like Orin family).
Right now I’m troubling with the device tree setup in order to get the expected Media-ctl output (verify the ports binding of the des->csi->vi)
What I did so far based on the programming guide and your answers:
a. Created a single .dtsi for my “new sensor” (fpd link des). I filled it based on the imx477 reference as you mentioned.
Add your .dtsi file to the camera configuration .dtsi file.
I don’t know what is the camera configuration .dtsi in my case (t234, orin nx, “new sensor”)
Compile the .dts file to generate a .dtbo file. Move the .dtbo file to flash_folder/kernel/dtb/ before flashing.
Here it states to compile the .dts created as overlay but it doesn’t say what to with my .dtsi for my new sensor (we have wo new files - .dtsi for my sensor and .dts for overlay)
So the instructions in this options are not cleared.
include “common/tegra194-p2822-camera-modules.dtsi”
With an #include statement specifying the .dtsi file for your new device.
4. Save and close the file.
As I said, the files mentioned here are not relevant for my case. In addition there is no plugin manager in systems using UEFI. So the question here is which file to edit.
What I did:
Edited tegra234-p3768-0000-a0.dtsi by removing the inclusions of imx477 and imx219 and adding inclusion for my .dtsi
built the kernel dtbs only (not the entire kernel from source but just the dtbs)
moved the final dtb to the target
The problem is that this solution didn’t work for me as well. It produces two problems:
The final generated dtb, for some reason, ignores the vi/csi nodes from my new_sensor.dtsi but takes other nodes from it.
The Media-Ctl output is not as expected.
So to conclude I’m stuck since I find it hard to “guess” the correct operations needed to build the proper device tree for my case. The devguide is outdated and its my first time developing new sensor driver.
Xavier and Orin series they’re sharing the same VI driver, you may still refer to developer guide even though it did not mentioned t23x.
and… it’s always suggest to check reference drivers for deployment.
I followed the dev-guide and the reference drivers.
I wrote my own .dtsi for the new device and a kernel module.
My module’s probe function is not executing (probably something wrong with my device registration/identification from the device tree)
I’m kinda stuck. Is it possible to get you help regarding this subject?
My setup is very simple:
FPD Link de-serializer → Orin NX
please refer to Device Registration section.
it’s suggest to work with [Using the Main Platform Device Tree File] for force system booting up with your customize module.