Orin Nano and tc358743 capture issue

Was missing an r, when i replaced the TC358743 driver in the JetPack to rebuild, but since i managed to build it and also the device tree dtb using all the info in this thread, so thanks for all the help.

I think it fails now due to the lane polarity so next is the csi5_fops.c.

I am kind of new to this world can you point me to more info how to replace the kernel image once i compile it with the csi5_fops.c changes?

Guy38,

When you make changes to csi5_fops.c and re-run
make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=$CROSS_COMPILE -j8 Image

It will create a new Image file - mine is at:

~/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/images/arch/arm64/boot/Image

I copy the Image file to my Orin and as root, copy over the existing Image file at /boot/Image. I would suggest you back up the working one, just in case.

Hi @anomad

First of all thanks a lot I am now able to use it and capture.

Works for both 1920x1080x30 and 1280x720x50

the only odd thing is that for some reason when it boots up i don’t see the /dev/video0. it comes up after is run sudo modprobe tc358743

and than i can use
gst-launch-1.0 v4l2src device=/dev/video0 ! ‘video/x-raw,format=UYVY,width=1280,height=720,framerate=50/1’ ! nvvidconv ! video/x-raw ! xvimagesink sync=0
or
gst-launch-1.0 v4l2src device=/dev/video0 ! ‘video/x-raw,format=UYVY,width=1920,height=1080,framerate=30/1’ ! nvvidconv ! video/x-raw ! xvimagesink sync=0

any idea how to make it work without the sudo modprobe tc358743 ?

Hello Guy38 - good to hear you got it working! I’ve only done 1280x720x60 - could not get 1920x1080x60 working yet. I’ll see if I can capture the same resolutions you did.

To have the tc358743 probe at start, I used menuconfig :

cd ~/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/sources/kernel/kernel-5.10
make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=$CROSS_COMPILE -j8 mrproper          	: or clean or distclean - removes .config file..
make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=$CROSS_COMPILE -j8 tegra_defconfig		: this builds the .config module, run after mrproper
make ARCH=arm64 O=$KERNEL_OUT CROSS_COMPILE=$CROSS_COMPILE -j8 menuconfig		: set tc358743 here 

. get to Device Drivers > Multimedia support > Media ancillary drivers > Video decoders    in menuconfig

D	Device Drivers 
u	Multimedia support
eeee	Media ancillary drivers
v	Video decoders
t	TC358743		: set to 'M' 

Which basically edits (creates?) the file
~/nvidia/nvidia_sdk/JetPack_5.1.2_Linux_JETSON_ORIN_NANO_TARGETS/Linux_for_Tegra/images/.config

Uncomment and set the entry to =m:

# CONFIG_VIDEO_SAA7110 is not set
# CONFIG_VIDEO_SAA711X is not set
CONFIG_VIDEO_TC358743=m
# CONFIG_VIDEO_TC358743_CEC is not set
# CONFIG_VIDEO_TVP514X is not set

The recompile Image and copy it to your Orin

I had the same done by editing the \Linux_for_Tegra\source\public\kernel\kernel-5.10\arch\arm64\configs\defconfig
I added CONFIG_VIDEO_TC358743=m
but i may not have cleaned before recompile … I’ll try this way now…

as for the 1920x1080 note that i am able to get 30fps. at 60fps it gets very bad … I’ll add a screenshot later.

Hi

Not sure yet why but the Image built this way broke my DP output, If i connect with the uart console i can see the system boots up, but i have no desktop to work with, I’ll try to roll back the image… it was all done under WSL2 and worked ok.

screenshot needs to wait :(

Ok

Flashed to a usb and managed to restore an other Image that i built with the nvbuild.sh, got back to the desktop and can capture again:

Any idea why it would break the DP output?

"as for the 1920x1080 note that i am able to get 30fps. at 60fps it gets very bad "

We discovered we could see 720p50, 720p60, 1080p25, and 1080p30 with this setup since they are all two lane and use the same pixel clock (74250000). However, it could not capture 1024x768p60, which requires a slightly lower pixel clock, so that doesn’t work on the Orin (yet?)

1080p60 needs four lanes which still fails with green screen.

No idea how any of these changes would affect your DP (display port video out, correct?) - we use HDMI on our custom board.

Correct DP out, it is the orin nano devkit with DP out. i’ll try to figure it out later… at least i got some progress thanks to you :)… cheers.

Hey @guy38, were you able to make a capture of the 1080p60 output? I see in your screenshot you are doing 1080p30. I am working with @anomad and we have not been able to capture anything at 1080p60 yet. We just get a green screen and dmesg says we have reached the time-out.

If you are at least getting garbled output, we want to see what we might have different.

Are you forcing a clock value in the csi5_fops? are you always setting to 74250000 for mipi_clock_rate_hz?

Are you changing the settle time?

Thanks!
Rick

I have it working as well now, and have the same functionality. 720p and 1080p (with exception of 1080p60) work. None of my basic attempts to get 1080p60 working have succeeded. Theoretically this should be able to work, since it functions on a Xavier NX.

I noticed @enc0der has a couple other threads related to this. The information that’s currently in them hasn’t helped me get it working though.

Orin Nano Dev board 8G, tc358743, 4-lane, CSI1 (J21), 1080p60, not working - Jetson & Embedded Systems / Jetson Orin Nano - NVIDIA Developer Forums

CAPTURE_CSI_STREAM_SET_CONFIG_REQ clarification - Jetson & Embedded Systems / Jetson Orin Nano - NVIDIA Developer Forums

@anomad and I have dug through so much code and we still haven’t figured out why it’s not working. Other people seem to be having the same problem as well. Given I believe there are people that have successfully used 4-lane with other sources, that leads me to believe that something is wrong in the tc358743 driver. Although I have spent A LOT of time going through it and just cannot seem to figure out why it’s not working.

The only thing I can get working is 2-lane at exactly 594bps per each lane.

I’m not sure if it’s useful, but on a Xavier NX with JetPack 4.6.4 I can get 1080p60 working with this driver and device tree: Jetson Nx Xavier TC358743 device tree + driver · GitHub. However, when I tried the porting the driver that @akvadak66 posted back to JetPack 4.6.4, I could not get 1080p60 video to work.

There might be some useful information in that, but the driver is a bit messy. It also doesn’t seem to work with 720p video.

This is the first time we’ve used a four lane board with a four lane sensor. That said, on our previous board I was able to get 2 and 1 lane working. On the Orin dev board, I can only get 2 lane working. 1 or 4 does not work. I also tried to get 1024x768 working which uses 2 lanes (I forget the framerate) and that didn’t work either.

The ONLY things I get running use 2 lanes and exactly 594Mbps per lane. Something feels hardcoded.

Another slight issue I’ve seen is that this driver doesn’t appear to work with 720p input resolutions unless the framerate is 50 Hz. If I connect a Windows PC and attempt to select 720p60, Windows will instead report an active signal mode of 1080p with a desktop resolution of 720p. Forcing the display adapter settings to 720p60 results in a green screen on the other end. However, a GStreamer pipeline that requests a video format of 720p will still work if the input is 1080p.

Here’s another bit of info that may or may not be useful. That Xavier driver I mentioned a couple posts up will overwrite the calculated value of state->pdata.pll_fbd from 88 to a static value of 176. If I set that back to 88, then 1080p60 no longer works, but 720p60 does. A quick hack I threw together sets the value of pll_fbd to 88 or 176 inside tc358743_set_fmt based on the specified format. It’s ugly, but it did get both 1080p60 and 720p60 working on the Xavier NX.

So we are running 720p60 on our setup. I don’t believe we’ve tried 720p50 yet. @anomad add that to the list to try, haha.

That’s interesting on state->data.pll_fbd. I’m assuming you’ve taken a look at that on the Orin side? To see what the value is and/or try different values?

My mistake, the Orin driver actually does function correctly with 720p60 as well. However, 720p30 does have the behavior I described.

I tried changing the value of pll_fbd on the Orin, but anything I tried gave me the same uncorr_err and NULL VI channel errors.

I’m not sure if any of those register configurations are the source of the problem or not, but it seems like they might have something to do with it since it fixed at least one format on the Xavier. I did find a reference to some of these commented out values on the driver in a mailing thread here [PATCH 3/3] [media] tc358743: Add support for 972Mbit/s link freq. - Dave Stevenson (kernel.org).

Yeah, I think we really have two problems we are trying to solve, and what you are talking about her is likely the second on we are focused on as well.

  1. For 1080p60 the lanes (4 of them) use the exact same speed as 720p60 (2 lanes) which mean that timing SHOULD stay the same. But, I guess a check here would be to see how some of the PLL values are being generated. Maybe there is a math error somewhere.

  2. I would imagine other timings might be necessary for different resolutions. For the Jetson Nano, I don’t remember doing anything special to capture 480p to the link frequency. I had changed the code to dynamically switch the internal lane count (since it only needed one) and it worked. That code in the latest driver is different, so I’ve not gotten back to there yet.

Basically, again, I figure 1080p60 should be the easiest to get working. I am going to dig into the driver more.

@JerryChang

I want to circle back to this message ( Orin Nano and tc358743 capture issue - #62 by anomad ) regarding csi5_fops.c

Can you explain what cil_config.mipi_clock_rate is and how it should be calculated?

Looking at ./sources/kernel/nvidia/include/soc/tegra/camrtc-capture.h does not reveal much…

        /** Number of data lanes used (0-4) */
        uint8_t num_lanes;
        /** LP bypass mode (boolean) */
        uint8_t lp_bypass_mode;
        /** Set MIPI THS-SETTLE timing (LP clock cycles with SoC default clock rate) */
        uint8_t t_hs_settle;
        /** Set MIPI TCLK-SETTLE timing (LP clock cycles with SoC default clock rate) */
        uint8_t t_clk_settle;
        /** @deprecated  */
        uint32_t cil_clock_rate CAMRTC_DEPRECATED;
        /** MIPI clock rate for D-Phy. Symbol rate for C-Phy [kHz] */
        uint32_t mipi_clock_rate;
        /** Reserved */
        uint32_t pad32__;
} CAPTURE_IVC_ALIGN;

When mipi_clock_rate was not hard coded in the code, it printed a value of 102000 which I ultimately discovered is being set in

sources/kernel/nvidia/include/media/vi2_registers.h:#define TEGRA_CLOCK_CSI_PORT_MAX 102000000

So, it doesn’t appear csi5_fops.c is doing anything to calculate mipi_clock_rate.

Why is the default value less than the 148500000 it would have to be for 1080p60 capture ?

hello anomad,

for of all, you’ve point-out VI-2 registers, which are not used by Orin series. (Orin using VI-5)

assume you’re using normal DPHY sensor.
it’s converting from device tree’s pix_clk_hz property settings as MIPI clock rate for rce-fw.
you may dig into the kernel driver, $public_sources/kernel_src/kernel/nvidia/drivers/media/platform/tegra/camera/sensor_common.c

58  static int sensor_common_parse_signal_props(
...
139  	/* Convert pixel rate to lane data rate */
140  	rate = rate * depth / signal->num_lanes;
141  
142  	if (signal->phy_mode == CSI_PHY_MODE_DPHY) {
143  		/* MIPI clock rate */
144  		signal->mipi_clock.val = rate / 2;

note, the clock has divide by 2 since data is sent on both rising/falling edges of clock.