TC358743 Driver For Jetpack 6.1 Seed Studio (Orin Nx Xavier CB) CAM0 CSI port Timeout

Products & Technology
1

Hello,

I’m using a Seeed Studio J4012 carrier board with a Jetson Orin NX module and a Toshiba TC358743 HDMI-to-CSI-2 bridge. I was able to port/enable the TC358743 driver on JetPack 6.1 (L4T r36.4, kernel 5.15.148-tegra), but I’m stuck with a persistent capture timeout only when using the CAM0 (CSI port 0) connector.

My main goal is: TC358743 on CAM0 CSI port working reliably.

Hardware / Software

  • Carrier board: Seeed Studio J4012

  • Module: Jetson Orin NX

  • JetPack: 6.1 (L4T r36.4)

  • Kernel: 5.15.148-tegra

  • Bridge: Toshiba TC358743 (HDMI input → MIPI CSI-2 output)

  • PHY / lanes: DPHY, 2 lanes

  • Format (from media graph): UYVY8_1X16, 1280x720p50 detected

What works vs what fails

CAM1 (Works)

When the bridge is connected/configured for CAM1, streaming works and the media graph is correct.

CAM1 media-ctl output (working):

  • tc358743 10-000f -> nvcsi -> vi-output -> /dev/video0

  • Links are enabled and stable.

  • I2C shows the device present on bus 10:

    • i2cdetect -y -r 10 shows UU at 0x0f

    • i2cdetect -y -r 9 shows no device

CAM0 (Fails with timeout)

When the bridge is connected/configured for CAM0, the media graph looks correct, I2C works, the driver enables streaming, but VI capture always times out.

CAM0 media-ctl output (failing):

  • tc358743 9-000f -> nvcsi -> vi-output -> /dev/video0

  • Format/dv.detect looks valid (1280x720p50 is detected in subdev capabilities/current).

  • I2C shows the device present on bus 9:

    • i2cdetect -y -r 9 shows UU at 0x0f

    • i2cdetect -y -r 10 shows no device

But capture fails repeatedly with:

  • tegra-camrtc-capture-vi ... uncorr_err: request timed out after 2500 ms

  • Then the driver resets the capture channel and retries, but it keeps timing out.

Current NVCSI / Timing Context

For CAM0 runs, NVCSI logs indicate configuration is applied and then capture times out:

  • === CSI5 SET CFG ENTER ... csi_port=0 lanes=2 ...

  • MIPI CLK MODE ... mipi_clock_rate=297000 kHz

  • I tried overriding lane polarity values in the CSI5 path:

    • Test 1: lane_polarity = 6 → timeout

    • Test 2: lane_polarity = 7 → timeout

  • (Next planned: lane swap / data lane order testing)

Changes I made trying to “force CAM0 only”

Because CAM1 was working but CAM0 was failing, I tried to simplify everything to CAM0-only:

  • Updated my DTS/DTBO to remove/ignore CAM1-related parts and map only CAM0.

  • Also modified some CSI/VI related code paths (e.g. csi5_fops.c / vi5_fops.c) to make debugging easier and focus on CAM0 only.

  • However, the issue remains: CAM0 always times out even though I2C and media graph look correct.

What I need help with

Since this is a Seeed Studio J4012 carrier, I suspect the issue might be related to:

  • CSI port mapping / connector mapping (CAM0 vs CAM1 routing)

  • Required Seeed overlay (dtbo) or camera framework expectations on JetPack 6.1

  • Any known J4012-specific CSI polarity/lane swap requirements for CAM0

  • Any JetPack 6.1 / r36.4 known issues with NVCSI/VI on one connector only

Could you please advise:

  1. What is the correct CSI port mapping for the physical CAM0 connector on J4012 (serial_a/serial_c, port-index mapping)?

  2. Are there recommended Seeed overlays/dtbo or reference device-tree examples for JetPack 6.1 when using custom CSI devices?

  3. Any known hardware routing differences on J4012 where CAM0 needs lane swap or different polarity compared to CAM1?

If needed, I can provide:

  • Full dmesg from CAM0 vs CAM1 attempts

  • Relevant running.dts sections (tegra-capture-vi, nvcsi@15a00000, TC358743 node)

  • media-ctl -p outputs (already included above)

Thanks in advance for any guidance. This seems like a J4012 CAM0-specific issue since CAM1 works reliably with the same TC358743 and HDMI source.

2

Actually I could not figure out one thing on my jetson:

I’m using a Jetson Orin NX on the Seeed carrier board (J4012) with JetPack 6.1, and I’m trying to understand the camera I2C mux mapping (cam_i2cmux).

On my system I see something that looks inconsistent compared to what I expected from other DTS examples:

  1. In one case, my device is under:
    /sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@1/@0f

But it appears on Linux as I2C bus 9:
readlink -f /sys/bus/i2c/devices/9-000f/of_node
→ /sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@1/

So in this case: i2c@1 → i2c-9.

  1. Also, when I connect the camera to the other connector (CAM1), it works and I see the device under:
    /sys/firmware/devicetree/base/bus@0/cam_i2cmux/i2c@0

And in that working case it appears on Linux as I2C bus 10 (device like 10-000f), so:
i2c@0 → i2c-10 (and streaming works).

My confusion: in most DTS/DTBO examples I found, people seem to imply i2c@0 is associated with i2c-9 (and i2c@1 with the other bus), but on my setup it looks swapped (i2c@0→10 and i2c@1→9), and only the “CAM1 case” works.

Is this mapping expected/normal on the J4012 carrier (JetPack 6.x), or does it suggest something wrong in my base DTB/overlay mapping?
Should we treat i2c@0/i2c@1 as the reliable way to identify CAM0 vs CAM1 (regardless of Linux bus numbers), or should the Linux bus numbers (i2c-9 / i2c-10) match a fixed connector?

If there is a standard mapping for J4012 (which connector corresponds to i2c@0 vs i2c@1 and which Linux bus number), could you please confirm it?

Thanks!

3

Hi there,

So , have you looked at this thread ?

I know it’s NOT your setup , but interesting the DTS or something must be misconfigured or borked by the upgrade.
wouldn’t be the first time. Hopefully the seeedineers can chime in with a fix if they have a good grasp on the tests you provide :+1:

HTH
GL :slight_smile: PJ :v:

4

Thank you for answering I will try from scratch (from flash with seeed studio resource) and then will share the result.