I’m trying to enable the TC358743 HDMI-to-CSI bridge driver on my NVIDIA Orin Nano Developer Kit running JetPack 6.2 (L4T R36.4.3, kernel 5.15.148-tegra).
Although the kernel source already includes the relevant files (drivers/media/i2c/tc358743.c, tc358743_regs.h, and include/media/i2c/tc358743.h), the default .config does not contain CONFIG_VIDEO_TC358743.
When I enable it manually using scripts/config --module CONFIG_VIDEO_TC358743, the option appears correctly in .config, but running make ARCH=arm64 olddefconfig removes it automatically. This means the option cannot persist through standard configuration regeneration.
I can compile the driver by manually adding obj-m += tc358743.o to the Makefile, but that approach bypasses Kconfig dependencies. Could you please advise why olddefconfig removes this option, which dependencies might be missing, and what the proper way is to enable this driver on JetPack 6.2?
I flashed the board and downloaded the kernel sources before running these commands.
The reason I followed this sequence is that I successfully enabled and built the TC358743 driver on JetPack 5.x using the same .config modification method, so I tried to apply the same approach here with JetPack 6.2.
Any insights on what changed in JetPack 6.x or how to properly enable this driver would be greatly appreciated.
Thank you for directing me to the Sensor Software Driver Programming guide.
I would like to clarify my setup and purpose: TC358743 is not a new sensor driver—it is already available in-tree in the JetPack 6.2 kernel sources (e.g. drivers/media/i2c/tc358743.c, tc358743_regs. h and include/media/i2c/tc358743.h) and the Kconfig symbol CONFIG_VIDEO_TC358743. My goal is not to write a new driver from scratch, but to properly enable the existing bridge/decoder driver on Orin (JP 6.2, L4T R36.4.3, kernel 5.15.148-tegra).
My observation is this: even if I manually set CONFIG_VIDEO_TC358743=m (or via scripts/config), then run make ARCH=arm64 olddefconfig, this option is deleted. In JP 5.x, the option could be persistent; in JP 6.x, the Media ancillary drivers → Video decoders submenu appears different/hidden, so the symbol cannot be permanently selected.
Can you advise on the correct way to keep the CONFIG_VIDEO_TC358743 option permanently enabled in JP 6.x?
Is there a recommended defconfig part (or NVIDIA’s preferred method) that enables the menu where TC358743 is located to be visible?
I also looked into this topic. When I run the commands below, I still cannot see the tc358743 driver in menuconfig.
$ cd /usr/src/kernel/kernel-jammy-src
$ sudo make ARCH=arm64 menuconfig
I could activate it directly from the .config file or menuconfig in jetpack 5.*. But I couldn’t find this configuration in Jetpack 6 either. I was not sure if editing it via the makefile is the correct method. So I asked. I’ll try it now.
patch nvidia/drivers/media/platform/tegra/camera/nvcsi/csi5_fops.c (mainly to set cil_config.mipi_clock_rate, cil_settletime, and lane polarity),
rebuild the kernel/modules, and
enable the bridge via DTB/DTBO. With that, /dev/video0/1 showed up and capture worked.
On JetPack 6.2 I only have the .ko right now. I noticed csi5_fops.c isn’t in the kernel tree anymore but exists under NVIDIA OOT on the host sources:
For JP6.2, is a device-tree overlay still required to make the TC358743 visible to the VI/NvCSI pipeline (i.e., create /dev/video*), assuming the module loads cleanly?
Are any edits to csi5_fops.c (or its JP6.2 equivalent) still necessary, or should all timing/polarity be supplied via DT now?
On JP5.x I hard-set e.g.:
cil_config.mipi_clock_rate = 74250; (74.25 MHz)
cil_config.t_hs_settle from DT
lane_polarity (sometimes forced to 6) If JP6.2 expects these strictly from DT, could you point to the correct DT properties (and binding docs) that replace those manual edits?
If a DT overlay is required on JP6.2, could someone share a minimal working DT/DTBO snippet for TC358743 (ports/endpoint, mclk, cil_settletime, lane_polarity, lane count, etc.)?
Do I need to rebuild and install the NVIDIA OOT camera stack (not only my tc358743.ko) so that the NvCSI/VI side matches, or is loading tc358743.ko
DT overlay sufficient?
Thanks a lot for any guidance or a reference DTS—much appreciated!
I am still having diffrent issue.
I build and boot a custom kernel on JetPack 6.2 (5.15.148-tegra) with CONFIG_DYNAMIC_DEBUG=y and a tc358743 bridge driver (=m). Everything is consistent and the module loads. As soon as I enable a DTBO through jetson-io.py, the next boot seems to use a different kernel where CONFIG_DYNAMIC_DEBUG is off, and I start getting many Unknown symbol __dynamic_* errors. This looks like Jetson-IO changes my boot entry in a way that boots a different Image. I used the tc358743.c file from this forum. I made minor changes to the dts file I also obtained from this forum. How can I keep my custom Image while using Jetson-IO overlays?
What I do (and it works before enabling the DTBO)
Build in-tree from /usr/src/kernel/kernel-jammy-src and install:
# .config (both trees synced): key options
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
CONFIG_DEBUG_PINCTRL=y
CONFIG_EXPERT=y
# CONFIG_MEDIA_HIDE_ANCILLARY_SUBDRV is not set
CONFIG_MEDIA_SUPPORT=y
CONFIG_MEDIA_CAMERA_SUPPORT=y
CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y
CONFIG_V4L2_FWNODE=y
# save this file and run $ sudo make olddefconfig
# After that I can see the TC358743 and change
CONFIG_VIDEO_TC358743=m
sudo make -j"$(nproc)" Image modules
sudo make modules_install
sudo cp -f arch/arm64/boot/Image /boot/Image
sudo depmod -a
sudo update-initramfs -u -k "$(uname -r)"
Reboot and verify I am indeed running this kernel (dynamic debug ON):
$ uname -r
5.15.148-tegra
$ zcat /proc/config.gz | egrep 'DYNAMIC_DEBUG|VIDEO_TC358743'
CONFIG_VIDEO_TC358743=m
# CONFIG_VIDEO_TC358743_CEC is not set
CONFIG_DYNAMIC_DEBUG=y
CONFIG_DYNAMIC_DEBUG_CORE=y
Load the module; no symbol/version errors at this point:
TIMEOUT 30
DEFAULT JetsonIO
MENU TITLE L4T boot options
LABEL primary
MENU LABEL primary kernel
LINUX /boot/Image
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=f0ad7f84-4b4f-4309-843d-8d700534fb5a rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0
LABEL JetsonIO
MENU LABEL Custom Header Config: <CSI Camera TC358743-HDMI>
LINUX /boot/Image
FDT /boot/dtb/kernel_tegra234-p3768-0000+p3767-0000-nv.dtb
INITRD /boot/initrd
APPEND ${cbootargs} root=PARTUUID=f0ad7f84-4b4f-4309-843d-8d700534fb5a rw rootwait rootfstype=ext4 mminit_loglevel=4 console=ttyTCU0,115200 firmware_class.path=/etc/firmware fbcon=map:0 nospectre_bhb video=efifb:off console=tty0
OVERLAYS /boot/tegra234-p3767-camera-p3768-tc358743.dtbo
After rebooting with the DTBO enabled, dynamic_debug suddenly appears OFF and a lot of drivers print unknown symbols:
$ zcat /proc/config.gz | egrep 'DYNAMIC_DEBUG|VIDEO_TC358743'
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DYNAMIC_DEBUG_CORE is not set
# lots of these in dmesg:
ipv6: Unknown symbol __dynamic_netdev_dbg (err -2)
ipv6: Unknown symbol __dynamic_pr_debug (err -2)
mc: Unknown symbol __dynamic_dev_dbg (err -2)
mc: Unknown symbol __dynamic_pr_debug (err -2)
...
This is exactly what happens when the kernel is built without dynamic debug but modules were built with it → symbol mismatch. However, prior to enabling the DTBO, I was running the custom image with dynamic_debug=. What could be the reason for this?
If needed I can attach:
The DT source I’m using: tegra234-p3767-camera-p3768-tc358743.dts
The bridge driver source I built as a module: tc358743.c
I saved Image that you said. I copied that image back to the boot partition and rebooted. But
$ date
Mon Oct 20 06:24:04 AM UTC 2025
$ uname -a
Linux jetson-nx 5.15.148-tegra #1 SMP PREEMPT Tue Jan 7 17:14:38 PST 2025 aarch64 aarch64 aarch64 GNU/Linux
$ ls -lah /boot/Image
-rw-r--r-- 1 root root 43M Oct 20 06:19 /boot/Image
I don’t understand why it’s booting from another image rather than the one under the boot image.
This is happening because of the dtbo file (overlay). I tested it with the monitor. I saw the following message on the monitor during the reboot. I think my dts file may be causing the error. I shared the file here. I couldn’t see any errors while compiling.
L4TLauncher: Attempting Direct Boot
L4T boot options:
0: primary kernel
1: Custom Header Config: <CSI-Camera tc358743-1001>
Press 0-1 to boot selection within 3.0 seconds.
Press any other key to boot default (Option: 1)
L4TLauncher: Unable to boot via extlinux: Device Error
L4TLauncher: Attempting Kernel Boot
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services...