This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Custom camera OMAP4460, is ducati source needed?

To my understanding, the ducati FW is responsible for handling any camera sensors, and I would assume that they also handles some (or most) data shuffling needed for HW encoding of video.

I'm just curious about what would be possible to do without access to the ducati source code.

Would it be possible to configure a custom sensor on the CSI2A interface which would pass that data through the hardware encoders with minimal CPU intervention (with things like white balance, gain adjustments etc handled by ourselves from kernel space)?

Or would everything be simplified a lot by meeting the right people, and signing the necessary agreements, so we would get access to the ducati source.

And by the way: While we are encoding video, we intend to use the other camera interface for other data (from a different data source), which we have to process by ourselves in the ARM cores (so we would have to set up one camera interface without an attached sensor as well).

BR
/Simon

  • Hi Simon,

    Could you please let us know which software release are you planning to use?

    One more thing you need to ensure is that whether the custom sensor you are using is already being supported in the corresponding Ducati SW release.

    Thanks & Best Regards,

    Venkat

  • We intend to start testing using firmware that might be available in 1-2 weeks time. It’s based on the GLP166 release (which might not have been released yet). It’s supposed to support a stereo system with OV5640 sensors (possibly with some patched kernel sources/patched ducati binary from the company that supplied us with our eval kit). It won’t do what we really want, but seemed to be the best starting point.

    We will have to make modifications: firstly, to encode only one sensor; Secondly, to support a different sensor (one of the sensors we are considering is the OV2722 sensor, which supposedly is similar to some other sensor supported on the OMAP5 platform).

    The video sensor would probably not be supported out of the box, and the custom data stream we want to transfer into the OMAP through the second MIPI port will definitely not be supported. When I looked at the /sys/kernel/debug/remoteproc/*-files on a previous TI gnu/Linux release, we didn’t see any probing for sensors at all (like we would see in recent ICS releases).

    Since almost anything from userspace can be processed and looped through the ducati subsystem, one could imagine that the ISP pipeline could be set up to generate strided NV12 output for our sensor using kernel drivers only, and that that buffer could manually be fed into the ducati encoder.

    But I can’t see how camera stabilization for instance could work at all if implemented only in the kernel, and I’m a bit worried that we might have to use more CPU or memory bandwidth if implementing everything without modifying the ducati sources. We've also seen a few attempts at patching the linux kernel to get sensor data output, but that have been done for older releases where hardware encoding wasn't available, and the project's I've seen havn't succeeded in porting it to 3.4-kernels, and some other attempts out there for recent kernels still lack strided NV12 output.

    BTW: We’ll meet some TI representatives soon, but before that, we’d like to get a feeling of what we can do, and what we would need from them if we decide to go with this platform.

    BR
    /Simon

  • To summarize

    1. Yes you need Ducati SW if you want to use features like AWB, AE, VSTAB

    2. You can connect a second camera  to either Ducati or A9 (using V4L2 driver). Recommended solution is to OMX interface via Ducati. Please note that on A9 you can use only a YUV sensor and support a limited feature set.