Issue Generating .ko File for tc358743 Module on Jetson Xavier NX with L4T 32.6.1

Robotics & Edge Computing Jetson & Embedded Systems Jetson Xavier NX
, , ,
1

Hello,

I am encountering an issue while trying to generate a tc358743.ko file for Jetson Xavier NX platform running L4T 32.6.1 and i’m using JetPack 4.6 version. I have followed the instructions provided in this GitHub gist: GitHub Gist Link to integrate the tc358743 driver. Here are the steps I’ve taken:

  1. Copied the tc358743.c driver file to /nx/source/Linux_for_Tegra/source/public/kernel/kernel-4.9/drivers/media/i2c/.
  2. Copied the device tree file to /nx/source/Linux_for_Tegra/source/public/hardware/nvidia/platform/t19/jakku/kernel-dts/common/.
  3. Added #include "common/tegra194-xavier-tc358743.dtsi" to tegra194-p3668-all-p3509-0000.dts.
  4. Uncommented #include "tegra194-camera-jakku-rbpcv3-imx477.dtsi" and #include "tegra194-camera-jakku-rbpcv2-imx219.dtsi" in tegra194-p3509-0000-a00.dtsi.

However, I’m encountering errors during this process. I have attached a screenshot of the errors below.

I have also attempted the dynamic way, but the tc358743.ko file is still not being generated. It seems that the driver isn’t loading properly. I would greatly appreciate any guidance or suggestions to resolve this issue.

Thank you in advance.

Best regards,
Kamalesh.C

error image
error image720×1600 71.4 KB

3

Hi,
From the log, it looks lile the refclk pin is not correct, or the i2c communication does not work. You may inspect the device tree to make sure it fits hardware design. And inspect if i2c bus number and address are correct.

4

Hello DaneLLL,

I’ve been actively researching an error that I encountered while working with the TC358743 device tree integration. I came across this relevant forum thread: Device Tree for TC358743, where valuable insights were shared.

One suggestion that caught my attention was related to changing a line in the driver file. The recommendation was to replace “cam_clk” with “ref_clk” in the probe function. I followed this suggestion, ensuring my setup mirrored the described changes. Unfortunately, despite these efforts, the error persists. For reference, I’ve attached my device tree give below.

I look forward to any suggestions that can help me move forward.

DEVICE TREE:

include <dt-bindings/media/camera.h>
include <dt-bindings/gpio/tegra194-gpio.h>
include <dt-bindings/clock/tegra194-clock.h>

define CAM0_PWDN TEGRA194_MAIN_GPIO(P, 4)
define CAM1_PWDN TEGRA194_MAIN_GPIO(P, 5)
define CAM_I2C_MUX TEGRA194_AON_GPIO(CC, 3)

/{
host1x {
gpio: gpio@2200000{
#gpio-cells = <2>;
camera-control-output-low {
gpio-hog;
output-low;
gpios = < CAM0_PWDN 0 >;
label = “cam0-pwdn”;
};
};

    vi@15c10000  {
        num-channels = <1>;
        ports {
            #address-cells = <1>;
            #size-cells = <0>;
            tc358743_vi_port2: port@0 {
                status = "okay";
                reg = <0>;
                tc358743_vi_in0: endpoint {
                    status = "okay";
                    port-index = <0>;
                    csi-port = <0>;  /* CSI-C */
                    bus-width = <2>; /* Use CSI-CD*/
                    remote-endpoint = <&tc358743_csi_out0>;
                };
            };
        };
    };


        nvcsi@15a00000 {
                    num-channels = <1>;
                    #address-cells = <1>;
                    #size-cells = <0>;
                    channel@0 {
                            reg = <0>;
                            status = "okay";
                                    ports {
                                            #address-cells = <1>;
                                            #size-cells = <0>;
                                            port@0 {
                                                    status = "okay";
                                                    reg = <0>;
                                                    tc358743_csi_in0: endpoint@0 {
                                                            status = "okay";
                                                            port-index = <0>;
                                                            csi-port = <0>;
                                                            bus-width = <2>;
                                                            remote-endpoint = <&tc358743_out0>;
                                                            };
                                            };
                                            port@1 {
                                                    status = "okay";
                                                    reg = <1>;
                                                    tc358743_csi_out0: endpoint@1 {
                                                    status = "okay";
                                                    remote-endpoint = <&tc358743_vi_in0>;
                                            };
                                    };
                            };
                    };
    };
};

i2c@3180000 {  /* I2C_0, "adapter" 0 */
    status = "okay";
    #address-cells = <1>;
    #size-cells = <0>;
    tc358743@0f {
        status = "okay";
        compatible = "tc358743";
        reg = <0x0f>; /* (normal = address not shifted) */

        devnode ="video0";

        // Trying to make sense of these reference clocks
        //clocks = <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>, <&bpmp_clks TEGRA194_CLK_PLLP_OUT0>;
        clocks = <&bpmp_clks TEGRA194_CLK_EXTPERIPH1>;
        //clock-names = “extperiph1”, “pllp_grtba”;
        clock-names = "extperiph1";
        clock-frequency = <27000000>;
        mclk = "extperiph1";



        //mclk = "cam_mclk1";  // EDO commmented for modes

       // reset-gpios = <&gpio 151 0>; // EDO commented out to test

        reset-gpios = <&tegra_main_gpio CAM0_PWDN GPIO_ACTIVE_HIGH>;

        refclk_hz = <27000000>;  // refclk_hz -> regclk

        //interrupt-parent = <&gpio>;
        interrupt-parent = <&tegra_main_gpio>;

        interrupts = <TEGRA194_MAIN_GPIO(N, 1) GPIO_ACTIVE_HIGH>;


        /* Physical dimensions of sensor */
        physical_w = "4.713";
physical_h = "3.494";

        /* Sensor Model */
        sensor_model ="tc358743";

        ddc5v_delay = <2>;
        enable_hdcp = "false";
        lineinitcnt = <0xe80>;
        lptxtimecnt = <0x003>;
        tclk_headercnt = <0x1403>;
        tclk_trailcnt = <0x00>;
        ths_headercnt = <0x0103>;
        twakeup = <0x4882>;
        tclk_postcnt = <0x008>;
        ths_trailcnt = <0x02>;
        hstxvregcnt = <0>;


        ports {
            #address-cells = <1>;
            #size-cells = <0>;

            port@0 {
                reg = <0>;
                tc358743_out0: endpoint {
                    port-index = <0>; /* CSI B */
                    bus-width = <2>; /* Use CSI-B only */
                    data-lanes = <1 2>;
                    clock-lanes = <0>;
                    clock-noncontinuous;
                    link-frequencies = /bits/ 64 <297000000>;
                    remote-endpoint = <&tc358743_csi_in0>;
                };
            };
        };
    };
};

tcp: tegra-camera-platform {
        status = "okay";
            compatible = "nvidia, tegra-camera-platform";
            num_csi_lanes = <2>;
            max_lane_speed = <1500000>;
            min_bits_per_pixel = <16>;
            vi_peak_byte_per_pixel = <2>;
            vi_bw_margin_pct = <25>;
            max_pixel_rate = <430000>;  //408000  this is related to the capped VI's max BW  max_pixel_rate / 0.4 = capped VI BW  
            isp_peak_byte_per_pixel = <2>;
            isp_bw_margin_pct = <25>;

        /**
            * The general guideline for naming badge_info contains 3 parts, and is as follows,
            * The first part is the camera_board_id for the module; if the module is in a FFD
            * platform, then use the platform name for this part.
            * The second part contains the position of the module, ex. “rear” or “front”.
            * The third part contains the last 6 characters of a part number which is found
            * in the module's specsheet from the vender.
            */
            modules {
        module0 {
            status = "okay";
            badge = "tc358743_top_i2c0_cd";
            position = "top";
            orientation = "3";
            drivernode0 {
                status = "okay";
                /* Declare PCL support driver (classically known as guid)  */
                pcl_id = "v4l2_sensor";
                /* Driver's v4l2 device name */
                devname = "tc358743 2-000f";
                /* Declare the device-tree hierarchy to driver instance */
                proc-device-tree = "/proc/device-tree/i2c@3180000/tc358743@0f";
            };

        };
            };
    };

};

Best Regards,
Kamalesh.C

5

Hi ,

Is there any changes to do with this frequency and clock things ?

Best Regards,
Kamalesh.C

6

Hi,
You may try the commands to run VI, CSI, ISP blocks in maximum clock.
Jetson/l4t/Camera BringUp - eLinux.org

See if it helps the use-case.

7

Hello DaneLLL,

In my situation, no node creation has occurred thus far. Does this debugging command encompass the creation of the “video0” node and related functions? Will this be beneficial?

I’ve already verified the correctness of the I2C bus number and related settings.

Could you please advise on resolving the error message “failed to get refclk”?

Best Regards,
Kamalesh.C

8

Hi,
It looks like the device tree does not fit the actual hardware design so it reports the error. Do you use custom board or Xavier NX developer kit? If you connect the camera to Xavier NX developer kit, you can check device tree for Raspberry Pi camera v2. The camera is enabled in default releases.

9

Hello,

Yes, we are utilizing a custom carrier board. However, this is not a plug-and-play device, is it? In the absence of a camera connection, should the device node be generated automatically, or is there a requirement to connect a camera for this process?

Best Regards,
Kamalesh.C

10

Hi DaneLLL,
Is there any input to move forward ?

Best Regards,
Kamalesh

11

Hi,
If your device tree is good. The node /dev/videoX should be generate automatically.
For porting device tree and sensor driver, please refer to sensor driver programming guide

12

Hi DaneLLL,

I have a doubt regarding the information provided under the i2c node for the tc358743 bridge. Is this information specific to the camera or the bridge itself? The reason for my confusion is related to how we can adjust video settings, including format, resolution, and how the camera captures images, to meet our specific requirements.

What does this information pertain to exactly? Do we require sensor documentation to create the device tree?

Best Regards,
Kamalesh.C

13

Hi,
Please check this tutorial for developing sensor driver:
Jetson Embedded Platform (JEP) Develop a V4L2 Sensor Driver

If i2c communication fails, one possibility is bus number is not correct in device tree. Please check and ensure hardware design fits device tree.

14

Hi DaneLLL,

These all are the factors :-
physical_w, physical_h, Min_gain_val, Max_gain_val,csi_pixel_depth, Min and Max_exp_time. min_bits_per_pixel, max_lane_speed, vi_peak_byte_per_pixel, vi_bw_margin_pct, max_pixel_rate, isp_peak_byte_per_pixel, isp_bw_margin_pct.

I have gone through sensors document provided by the nvidia and Jetson Embedded Platform (JEP) Develop a V4L2 Sensor Driver. After reading that document I m being lil confused and clueless to calculate above factors so,Could you please help me know that how to calculate all these above factors. In order to calculate these factors what all information i should be collecting from datasheet.

What all informations to b considered from datasheet*.

Best Regards,
Kamalesh.C

15

Hi,
The setting is related to width, height, framerate, format. Please check with camera vendor for supported sensor modes and configured it in device tree. If the modes are put in device tree correctly, you should see the information by executing

$ v4l2-ctl -d /dev/videoX --list-formats-ext

16

Hi DaneLLL,

I would like to bring to your attention that this guide, located at https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3274/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/camera_sensor_prog.48.1.html#, is based on the sensor of imx185. Could you kindly provide the imx185 sensor programming guide? This guide will help me understand the parameters that need to be configured.

Best Regards,
Kamalesh

17

Hi DaneLLL,

I have another doubt regarding gpio calculation.
<&tegra_main_gpio ((2 * 8) + 5) 0>;
From this expression,
0 → gpio_output_low;
what about another two terms of calculation and tegra_main_gpio.

Could you please clarify this doubt ?

Best Regards,
Kamalesh.C

19

Hi kamalesh1,

You could refer to tegra194-gpio.h.

Do you mean PC.05?

and also gpio.h to get:

#define GPIO_ACTIVE_HIGH 0
#define GPIO_ACTIVE_LOW 1

It is an address point to main gpio.

20

Hi kevin,

Actually, In my device tree i gave tegra_main_gpio (Q,3) for reset pin. But, tracing as per the tegra194-gpio,h → tegra_main_gpio (16(Q)*8 + 3 (offset)), totally it comes 131. But, As per the carrier board it is 124 which is GPIO02(soc_gpio23).

these 131 and 124 should match, right ?
if yes means why it is not matching ?
No, means what is the meaning of 131 ?
124 is as per the pinmux right ?

Best Regards,
Kamalesh. C

21

No, the XXX of gpio-XXX under the following would not map to TEGRA194_MAIN_GPIO().

$ sudo cat /sys/kernel/debug/gpio

Please share the full dmesg and also the result of above command.

22

Hi Kevin,

Please find the attachment given below.
I am still having doubt in these topic. could you please elaborate this ?

log.txt (8.7 KB)

Is there any USB related issues in my dmesg ?

dmesg.txt (60.9 KB)

Best Regards,
Kamalesh.C