Hi, I have made a “dummy driver” based on imx185 source code. The idea is to have a camera driver without i2c communication, so the driver probe is always ok. Then under user space I am able to send any i2c commands to the different cameras we have. This is only for testing and developing new camera modules.
So, I did that concept for the first version of the jetson nano module (only one CSI connector) and now I’m trying to port this from the jetpack 4.3 to the jetpack 4.5 and jetson nano with two CSI connectors.
The first version was all OK, but now I have a segmentation fault when I try to make a call to “v4l2_open” function.
If I run the test under valgrind I cann see this:
medios@mediosjn:~/v4l2libs/libv4l2$ valgrind ~/camtest
==16890== Memcheck, a memory error detector
==16890== Copyright (C) 2002-2017, and GNU GPL’d, by Julian Seward et al.
==16890== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16890== Command: /home/medios/camtest
==16890==
Opening in BLOCKING MODE
==16890== Invalid read of size 8
==16890== at 0x4FF7090: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF7F9B: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF68F7: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF66B7: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4891CCB: v4l2_plugin_init (in /usr/lib/aarch64-linux-gnu/tegra/libnvv4l2.so)
==16890== Address 0x0 is not stack’d, malloc’d or (recently) free’d
==16890==
==16890==
==16890== Process terminating with default action of signal 11 (SIGSEGV)
==16890== Access not within mapped region at address 0x0
==16890== at 0x4FF7090: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF7F9B: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF68F7: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4FF66B7: ??? (in /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so)
==16890== by 0x4891CCB: v4l2_plugin_init (in /usr/lib/aarch64-linux-gnu/tegra/libnvv4l2.so)
==16890== If you believe this happened as a result of a stack
==16890== overflow in your program’s main thread (unlikely but
==16890== possible), you can try to increase the size of the
==16890== main thread stack using the --main-stacksize= flag.
==16890== The main thread stack size used in this run was 8388608.
==16890==
==16890== HEAP SUMMARY:
==16890== in use at exit: 959,896 bytes in 1,201 blocks
==16890== total heap usage: 1,641 allocs, 440 frees, 1,398,238 bytes allocated
==16890==
==16890== LEAK SUMMARY:
==16890== definitely lost: 58 bytes in 1 blocks
==16890== indirectly lost: 0 bytes in 0 blocks
==16890== possibly lost: 312,223 bytes in 37 blocks
==16890== still reachable: 647,615 bytes in 1,163 blocks
==16890== of which reachable via heuristic:
==16890== newarray : 4,736 bytes in 28 blocks
==16890== multipleinheritance: 1,184 bytes in 1 blocks
==16890== suppressed: 0 bytes in 0 blocks
==16890== Rerun with --leak-check=full to see details of leaked memory
==16890==
==16890== For counts of detected and suppressed errors, rerun with: -v
==16890== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
But I can not debug inside the init function of libv4l2_nvargus.so file because I’m not able to find the source code.
Maybe it is not released?
I’m not sure how I can continue to debug. Some Idea?
I’ve made the driver and it works. As I said with the jetpack 4.3 I have no problems. With 4.5 I it works through opencv: cv2.VideoCapture(0), and it also works with gstreamer. The problem is that as I have different sensors, one of them is RAW12, so I need to go through v4l2 directly. If I build the example “camera_unit_sample” it breaks on v4l2_open function. I am testing with a sample build that only is calling to the open function and it breaks with the segmentation fault problem. I have plugged a USB webcam, then I see a new /dev/video2 device, and I have the same problem with the webcam. This is why I suspect that maybe the problem is not in my driver, but of course it could be.
It always works also with v4l2-ctl. These are the working calls:
it looks you’re using v4l2 standard control to access video0 with different pixel format types.
is your sensor output different pixel format for different sensor modes? had you also check the raw files for confirmation?
thanks
Yes, different modes really means different sensors and different pixel format types. I have a board with a ds90ub954 deserializer always plugged into the jetson, and then different camera modules with different sensors that I can connect to this board through an FPDLinkIII connection.
I can test the driver with only one mode and one camera to see if it woks, but as I said before, this concept works well with the jetpack4.3. I am only upgrading to 4.5 because it would be nice to have the latest features. Anyway I will try.
I’m sorry, maybe I’m not explaining well, but this command works well. And RG12 and 1280x1080 are the right pixel format and resolution. If I execute the command I have the right raw capture from the sensor (in all the modes).
The problem is when inside a program I call the function v4l2_open(“/dev/video0”).
The open is before any setting, and I’m getting a segmentation fault.
Maybe I’m missing something.
One difference with the first call is that it outputs the message “Opening in BLOCKING MODE” before the segmentation fault, so it seems the flag O_NONBLOCK has no effect.
In jetpack 4.5. ‘open’ returns different formats than ‘v4l2_open’.
In my case, ‘open’ returns the format provided in device tree while ‘v4l2_open’ only provides ISP output format and does not even list the raw camera format. Flags passed to v4l_open are ignored and I am therefore also unable to open more than one stream simultaneously using gthe new v4l argus pipeline.
besides the bug fixes,
we have also complete internal verification by including some code refinement.
you may download the pre-built binary for JetPack-4.5 / l4t-r32.5,
i.e. Topic168303_Apr21_libv4l2_nvargus.zip (101.1 KB)
it has include the fixes to make driver to get the media bus info.
you may replace /usr/lib/aarch64-linux-gnu/tegra/libv4l2_nvargus.so with the attachment,
please also perform a warm-reboot for confirmation.
thanks
Unfortunately, that did not change anything in my tests. It appears that the returned formats depend on the combination of either ‘ioct’ or ‘v4l2_ioctl’ and the use of ‘V4L2_BUF_TYPE_VIDEO_CAPTURE’ or ‘V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE’
I would expect ‘V4L2_BUF_TYPE_VIDEO_CAPTURE’ and ‘V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE’ to return different formats dependeing on whether you would want to use single plane or multiplane capturing, but not ‘ioct’ or ‘v4l2_ioctl’
Here are my results when using the 4 possible combinations for a RAW10 RGGB camera and the following function to list formats (please change type and ioctl function accordingly)
I tried to open rtsp streaming using gstreamer command and control aelock using v4l2 api (or argusv4l2 api), and I don’t want this to block the streaming, which means the NONBLOCK flag need to work.