I read somewhere that the new update for the L4T should’ve made the CSI2 camera available on video0 for OpenCV work.
I can’t find where it said this, but is it true?
If not, how can I make the CSI2 port available as video0 for OpenCV capture? My goal here is to use it with a different CSI2 camera than the one given with the board.
Hi GinDiamond,
In the L4T Documentation, see the Video for Linux User Guide: [url]http://developer.nvidia.com/embedded/dlc/l4t-documentation-23-2[/url]
The kernel patch to enable it was posted here: [url]https://devtalk.nvidia.com/default/topic/920739/jetson-tx1/l4t-r23-2-for-jetson-tx1-released/post/4824232/#4824232[/url]
By default OpenCV tries V4L2 (/dev/video0) for video capture. However you can also pass gstreamer pipeline which can also use CSI2 camera using nvcamerasrc element, see here: [url]https://devtalk.nvidia.com/default/topic/925923/jetson-tx1/can-not-open-the-camera-on-tx1-via-opencv/post/4841289/#4841289[/url]
I know this is a really stupid question, but how do I apply the patch? It asks me which file to patch with the patch < command
The git am commands don’t work.
There are a couple different files it patches, like:
arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
arch/arm64/boot/dts/tegra210-platforms/tegra210-camera-e3326-a00.dtsi
arch/arm64/boot/dts/tegra210-platforms/tegra210-jetson-cv-camera-e3326-a00.dtsi
You can identify them by looking for the diff sections in the patch, which specify the files:
diff --git a/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts b/arch/arm64/boot/dts/tegra210-jetson-cv-base-p2597-2180-a00.dts
Do I just type in “patch file.patch”? Or do I have to point it to a specific file.
I am assuming that I can use this patch command on a running Tegra TX1 with the 23.2 release without reflashing it
The patch command usually gets run something like this (adjustments may be required):
# cd to base of source tree (where the patch is in the parent of that directory)
patch -p1 < ../the_patch.diff
In that command the content of “the_patch.diff” is redirected to “patch”, and file names have one top level directory name removed because of the “-p1”. If the file is not found, typically the “-p” is adjusted. The proper option is almost always “-p0” or “-p1”.
Variations are available for git to work directly with as well.
Thanks! This actually does make much more sense than what I was trying.
Unfortunately, I still don’t think I’m following right. Hear me out with this one.
What I do:
Copy the .patch file in the other thread and save it as 0001… .patch
Copy it to /usr/src/linux-headers…45c/
Open up the terminal
sudo su
cd to that directory I moved the .patch file to
rename .patch to .diff
type in: patch -p1 < 0001… .diff
It then says to specify what file to patch
Look in the linux-headers…45c directory
Realize that all the folders have no other files in them except more folders and makefiles that don’t work
What am I doing wrong?
The “-p” option usually handles the topic of “what file to patch”, but it could also mean your source code is far enough different that the file does not exist. Also, a diff can contain more than one diff which have been chained together into a single file, so part may work and part fail.
To find out, look at the top of the diff file (I’m assuming just one file to patch in the diff, but remember it could be multiple files chained together). There will be a file name which is a subset of that file’s full path, prefixed with notation such as “—” and “+++”. What are those for your specific case?
These paths indicate a “left” and “right” file name which was used in the original creation of the diff. Those paths could be completely different except for the tail of those paths, which might represent the patch author’s directory layout…but only the tail of those paths matter to you, as you are not on the author’s machine (or not likely to be). Each level of “-p” (such as “-p0”, then “-p1”, then “-p2”, then “-p3”, …) ignores a component of the path prefix. The goal is that from the location you run the patch command, that trailing part of those paths match the file name on your machine from the place you run the patch command.
So generally you will have the kernel source in full if you are working on drivers or configuration of the kernel, but linux-headers directory if you are only linking a user space application to kernel headers. It looks like the above patches require full kernel source, so you’d unpack the kernel source, cd there, make sure the diff file is available, and run patch from there (and you might need -p0, -p1, -p2 or similar adjusted).