Hello,
I have bought a jetson nano and wonder if the chipset TC358743 (b101 from auvidia HDMI to CSI-2 bridge) is supported? if not, is it possible to activate at kernel build / patch?
Someone who has tried this? all help is appreciated.
Best Regards
Hi rndbit,
I can’t answer that due to we don’t have the board, and never ran any test yet.
Please contact with Auvidea support to get more information.
Thanks
hello rndbit,
since you would like to have implementation of HDMI to CSI-2 bridge driver.
suggest you also check below kernel source for reference,
thanks
$TOP/kernel_src/kernel/nvidia/drivers/media/i2c/tc358840.c
Hi rndbit,
As you said B101-15pins and 2 lanes, is compatible with the CSI port for the EVM kit nano board. We have tested the tc358743 module in nano, we developed a driver. In the next wiki page you can find more about the resolutions supported and the tests we have done so far. Also we are capturing with UYVY color format.
Thanks alot, will try it out
Best regards
I follow this guide but get stuck on “Downloading Kernel sources” - JETPACK=~/JetPack-L4T-4.2
Is this tutorial updated? as I understand it, is this already on the nano image?
All help is welcome.
Thanks
Any premade image existing? I would love to try out this but I cannot really get it working. If anyone can help out with some image with this installed I would be thankful.
Thanks
Hi rndbit,
I order to have the tc358743 working you need to apply some of our patches to the kernel sources. The guide you are following is just to compile the clean kernel sources that NVIDIA provides.
Regards,
Hi ACervantes
I’m also interested in using the B101-Board with the Jetson Nano. Is the driver you developed for the tc358743 available open source? Is there a guideline how to apply your patches to the kernel sources?
thanks
It’s not open source, they sell it onsite: https://shop.ridgerun.com/products/toshiba-tc358743-v4l2-driver-for-nvidia-jetson
It’s just 25 times the price of jetson ;)
Hi,
RidgeRun can create any V4L2 driver that you need, you can read more about our services in our wiki:
[url]https://developer.ridgerun.com/wiki/index.php?title=V4L2_driver_for_camera_sensor_or_capture_chip[/url]
[url]https://developer.ridgerun.com/wiki/index.php?title=V4L2_drivers_available_for_Jetson_SoCs[/url]
I’m also interested in using the TC358743 chip on the Jetson Nano. I’m currently testing with an Auvidea B101. I am aware of Ridgerun’s services, but for the time being I’d like to understand the drivers myself. Currently I’m having trouble with the clock (or at least I think I do), it looks like it needs at least a 26 MHz clock and so far the most I can supply it with is 24 MHz.
I’ve modified the device tree file from https://devtalk.nvidia.com/default/topic/1011640/jetson-tx2/tc358743-on-tx2/post/5229417/#5229417 to get the right i2c bus on the developer board’s CSI port. I’ve also modified the tc358743 driver to not error out when given a 24 MHz clock, since as far as I know that’s the fastest the CSI clock will go.
Here’s a snippet of the dtsi file I altered, I also changed the clock source from the original.
i2c@546c0000 { /* I2C_PM, "adapter" 6 */
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
tc358743_b@0f {
clocks = <&tegra_car TEGRA210_CLK_CLK_OUT_3>;
clock-names = "clk_out_3";
clock-frequency = <24000000>;
mclk_khz=<24000>;
status = "okay";
compatible = "tc358743";
reg = <0x0f>; /* shifted by 2 */
mclk = "clk_out_3";
reset-gpios = <&gpio 152 0>;
refclk_hz = <24000000>;
/* Physical dimensions of sensor */
physical_w = "4.713";
physical_h = "3.494";
/* Sensor Model */
sensor_model ="tc358743";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tc358743_out0: endpoint {
csi-port = <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_vi_in0>;
};
};
};
};
};
};
Here’s the output of v4l2-ctl --log-status:
[ 49.619533] vi 54080000.vi: ================= START STATUS =================
[ 49.620308] tc358743 6-000f: -----Chip status-----
[ 49.620562] tc358743 6-000f: Chip ID: 0x00
[ 49.620814] tc358743 6-000f: Chip revision: 0x00
[ 49.620817] tc358743 6-000f: Reset: IR: 0, CEC: 0, CSI TX: 0, HDMI: 0
[ 49.620820] tc358743 6-000f: Sleep mode: on
[ 49.620823] tc358743 6-000f: Cable detected (+5V power): yes
[ 49.621064] tc358743 6-000f: DDC lines enabled: no
[ 49.621295] tc358743 6-000f: Hotplug enabled: no
[ 49.621580] tc358743 6-000f: CEC enabled: no
[ 49.621583] tc358743 6-000f: -----Signal status-----
[ 49.621585] tc358743 6-000f: TMDS signal detected: no
[ 49.621587] tc358743 6-000f: Stable sync signal: no
[ 49.621590] tc358743 6-000f: PHY PLL locked: yes
[ 49.621592] tc358743 6-000f: PHY DE detected: no
[ 49.622028] tc358743 6-000f: No video detected
[ 49.622033] tc358743 6-000f: Configured format: 0x0p0.0 (0x0)
[ 49.622036] tc358743 6-000f: horizontal: fp = 0, -sync = 0, bp = 0
[ 49.622039] tc358743 6-000f: vertical: fp = 0, -sync = 0, bp = 0
[ 49.622041] tc358743 6-000f: pixelclock: 0
[ 49.622044] tc358743 6-000f: flags (0x0):
[ 49.622046] tc358743 6-000f: standards (0x0):
[ 49.622048] tc358743 6-000f: -----CSI-TX status-----
[ 49.622051] tc358743 6-000f: Lanes needed: 0
[ 49.622370] tc358743 6-000f: Lanes in use: 3
[ 49.622626] tc358743 6-000f: Waiting for particular sync signal: yes
[ 49.622881] tc358743 6-000f: Transmit mode: no
[ 49.623136] tc358743 6-000f: Receive mode: yes
[ 49.623392] tc358743 6-000f: Stopped: yes
[ 49.623394] tc358743 6-000f: Color space: Unsupported
[ 49.623625] tc358743 6-000f: -----DVI-D status-----
[ 49.623628] tc358743 6-000f: HDCP encrypted content: no
[ 49.623630] tc358743 6-000f: Input color space: RGB full range
[ 49.623860] vi 54080000.vi: ================== END STATUS ==================
I can see some i2c traffic from the chip, but there’s no other activity other than status checks when I try to play a video. The post from https://devtalk.nvidia.com/default/topic/1011640/jetson-tx2/tc358743-on-tx2/post/5229417/#5229417 mentions declaring the EDID, which I haven’t figured out how to do yet since I don’t know if it’s critical at this point or not. I know the clock is likely an issue.
I’ve seen references to clk_set_parent(refclk, parent) from https://devtalk.nvidia.com/default/topic/1037888/jetson-tx2/cam2_mclk-weird-behaviour/ which I don’t know if that would make it possible to set a faster CSI clock on the Nano, or if I have to wait for a custom carrier board with a proper external clock.
hello andrew.pease,
please refer to Sensor Software Driver Programming Guide for the mclk property description.
by default the mclk using extperiph1 as input clock, the maximum frequency for extperiph1 is 24 MHz.
if a frequency greater than 24 MHz is required, please use an external clock source.
thanks
I appreciate the prompt reply, and am sorry it’s taken me months to get back to this. Using an external clock source is the answer I expected so I moved on to other things. Now that I’m closer to needing to actually use an external clock source, I’m wondering about the details.
If I’m supplying a 26 MHz clock to the CSI connector on a custom carrier board, do I need to feed that clock back into the Nano module on the corresponding CAMx_MCLK line? Do I need to shut off the Nano’s MCLK in a dtsi file somehow?
hello andrew.pease,
you may specify the mclk property in your sensor device tree,
also, extperiph1 using PLL clock sources and divided to target frequency,
thanks
Thanks for the quick reply again. I’m not very familiar with the device tree so it looks like I’ve got some research to do.
I forgot to post my kernel change from before: https://github.com/torvalds/linux/blob/0f137416247fe92c0779a9ab49e912a7006869e8/drivers/media/i2c/tc358743.c#L1955
/*
* The PLL input clock is obtained by dividing refclk by pll_prd.
* It must be between 6 MHz and 40 MHz, lower frequency is better.
*/
switch (state->pdata.refclk_hz) {
case 26000000:
case 27000000:
case 42000000:
state->pdata.pll_prd = state->pdata.refclk_hz / 6000000;
break;
default:
dev_err(dev, "unsupported refclk rate: %u Hz\n",
state->pdata.refclk_hz);
goto disable_clk;
}
I changed to
/*
* The PLL input clock is obtained by dividing refclk by pll_prd.
* It must be between 6 MHz and 40 MHz, lower frequency is better.
*/
switch (state->pdata.refclk_hz) {
case 24000000:
case 26000000:
case 27000000:
case 42000000:
state->pdata.pll_prd = state->pdata.refclk_hz / 6000000;
break;
default:
dev_err(dev, "unsupported refclk rate: %u Hz\n",
state->pdata.refclk_hz);
goto disable_clk;
}
which allows the driver to at least initialize and load, but I couldn’t get anything to connect on the HDMI side. Now it might be that my remaining problem is with the EDID, which is easy to discover with a bit of testing of different inputs.
I’ll post again if I discover anything useful.
Have you made any progress since December? I’m venturing into this as well and would love any head start I can get.
I’m afraid not. We ended up going with Ridgerun’s solution, so I can’t offer more guidance on this particular driver. I know it’s not an answer for hobbyists or smaller startups, so hopefully someone else will keep working on the public version. There certainly seems to be a decent number of people interested in it.
Hi Andrew, with Ridgerun’s solution do you need an external clock or does it work with the Jetson Nano dev board as-is? I’m asking to know whether it’s worth pursuing getting the tc358743 working with the Jetson Nano on my own.
It works with the first revision Nano dev board I have as-is, I was rather impressed. I recommend emailing Ridgerun if you have any questions before purchase, they were very responsive for us. You’ll want to be sure you’re getting exactly what you want.