i.MX6 MIPI-CSI2 OV5640 Camera testing on Mainline Linux

[Steve Longerbeam]

Hi Adam,

On 10/23/18 8:19 AM, Adam Ford wrote:
> On Mon, Oct 22, 2018 at 7:40 AM Fabio Estevam <festevam at gmail.com> wrote:
>> Hi Adam,
>>
>> On Mon, Oct 22, 2018 at 9:37 AM Adam Ford <aford173 at gmail.com> wrote:
>>
>>> Thank you!  This tutorial web site is exactly what I need.  The
>>> documentation page in Linux touched on the media-ctl links, but it
>>> didn't explain the syntax or the mapping.  This graphical
>>> interpretation really helps it make more sense.
>> Is capturing working well on your i.MX6 board now?
> Fabio,
>
> Unfortunately, no.  I built the rootfs based on Jagan's instructions
> at https://openedev.amarulasolutions.com/display/ODWIKI/i.CoreM6+1.5
>
> I tried building both the 4.15-RC6 kernel, a 4.19 kernel and a 4.14 LTS kernel.
>
> Using the suggested method of generating the graphical display of the
> pipeline options, I am able to enable various pipeline options
> connecting different /dev/videoX options tot he camera.  I have tried
> both the  suggested method above as well as the instructions found in
> Documentation/media/v4l-drivers/imx.rst for their respective kernels,
> and I have tried multiple options to capture through
> ipu1_csi1_capture, ipu2_csi1_capture, and ip1_ic_prepenc capture, and
> all yield a broken pipe.
>
> libv4l2: error turning on stream: Broken pipe
> ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could
> not read from resource.
> Additional debug info:
> gstv4l2bufferpool.c(1064): gst_v4l2_buffer_pool_poll ():
> /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
> poll error 1: Broken pipe (32)
>
> I can hear the camera click when I start gstreamer and click again
> when it stops trying to stream.
>
> dmesg indicates a broken pipe as well..
>
> [ 2419.851502] ipu2_csi1: pipeline start failed with -32
>
> might you have any suggestions?


This -EPIPE error might mean you have a mis-match of resolution, pixel 
format, or field type between one of the source->sink pad links. You can 
find out which pads have a mis-match by enabling dynamic debug in the 
kernel function __media_pipeline_start.

Also make sure you are attempting to stream from the correct /dev/videoN.

Steve