Updates to 3.0.35 non-Android kernel

[John Weber]

Here is a list of commits to the non-Android kernel that we have been
using for Yocto. Special thanks to Stephan Rafin for his help and
collaboration, and especially for fixing the wand_reserve function.

In general, the commits can be lumped as follows:
- Lots of of useful bits that we pulled from the Wandboard Android
kernel (at repo.or.cz). These should have been included as part
of the initial port.
- Fixes to the Wandboard board init code for MIPI CSI and the
wand_reserve() function which reserves memory for the GPU.
- Fixing numerous style and formatting problems with board-wand.c and
baseboard-wand.c identified by scripts/checkpatch.pl

Git clone URL:
https://github.com/johnweber/linux.git
branch: wandboard_imx_3.0.35_4.0.0

View on Github:
https://github.com/johnweber/linux/tree/wandboard_imx_3.0.35_4.0.0

Regards,
John

commit 929768aaf8c9161b2729c11c0b96012547bdc4eb
Author: John Weber <rjohn...@gmail.com>

wandboard: modify mipi-csi to ipu mux setting

commit e5099d323a8a37fc4b1a52b7b15069ad762b3565
Author: Stephan Rafin <stepha...@laposte.net>

wandboard: Fix wand_reserve function for any wandboard version
(cherry picked from commit f77f22601e4f4bcbf3e14a48266a4fe3fa56e6e0)

commit cf7575098a67ec2fc611da026be7876c67c24f7c
Author: John Weber <rjohn...@gmail.com>

wandboard: fix #ifdef to include line continuation

commit 7aa1e33743db4f9439bfe0b704aee3b2e227f02a
Author: John Weber <rjohn...@gmail.com>

wandboard: Fix checkpatch errors and warnings

commit 84dd53aa0ef86e156ef535f57205e8ba02c1c2cc
Author: wolfgar <stepha...@laposte.net>

wandboard: Remove hundreds of checkpatch errors warnings

commit 3b41d63c372de55d70c814543b52cd45b6d6ab38
Author: John Weber <rjohn...@gmail.com>

wandboard: fix mipi-csi exclusion and reorg

commit c81dfc952ee31a43c1d0a7d993687985ef7cf9ec
Author: wolfgar <stepha...@laposte.net>

Adapt video memory limit according to wandboard version
(cherry picked from commit 11a509c6d0958741af52fd85661c08975d1e271d)

commit 15bb848908719c50d97c50f17855a36e96327485
Author: wolfgar <stepha...@laposte.net>

Fix compilation when mipi-csi option is disabled

commit 3c7a46f4b41d1adacbffe22bb4b4114d1cf9b098
Author: wolfgar <stepha...@laposte.net>

Fix uninitialized variables warnings

commit 8087f87d462b63c6977bf8d9cd3a5ea1fce748b3
Author: wolfgar <stepha...@laposte.net>

Use 2GiB constant as memory limit for GPU
(cherry picked from commit 1c1fd4c1721b3c778a583c41daaf6eaef86fc2f4)

commit b460a16de73ac6576cd7a80b0d0099f8afed29d0
Author: wolfgar <stepha...@laposte.net>

Fix build when spdif support is not enabled
(cherry picked from commit 65bdd402ba6967518794f3379339fb0a469a976c)

commit 6613cc898309fdd2099cc9bca75d011cb1cb20cb
Author: wolfgar <stepha...@laposte.net>

Enable to reserve GPU Memory in higher memory to avoid to shrink DMA zone
(cherry picked from commit 26c6d7b49f9d59d43ec166a97eb2cb8d519d1441)

commit 0c7ccfa705f55c74475029169d43519416dd913d
Author: Tapani <tap...@vmail.me>

Set iMX6DQ/DL max speed back to 1GHz

commit 6d2bd43769a751452bd79515e844b4250b1d39b8
Author: Tapani <tap...@vmail.me>

Fix signal type for AUO 97G070 LVDS panel

commit 554bfeda0e15ba0a2680be9e04fa8f732b99208e
Author: Tapani <tap...@vmail.me>

Add support for AUO 97G070 LVDS panel
(cherry picked from commit 81a8ff3743ae3dd21b5a0225f1ecf6bc798cbad4)

commit 022f696a4d5b462916b76b68dc9e95406a36205c
Author: Tapani <tap...@vmail.me>

Don't touch iMX6 SATA clock on other than iMX6Q.

commit 4ce987a0b12eebadc87b88f036ffe09af3f058c4
Author: jean charles mammana <x@x>

kernel header missing during installation

commit 194d4c94a821fced74bf563fb817a8eb73a948e1
Author: Tapani <tap...@vmail.me>

Revert "ENGR00225875-2 i.MX6Q/Solo Sabreauto Bluetooth H4 fix uart rx
timeouts."

commit c01ebb6ca08326a7d2309efc68329f4147c6d5e5
Author: Ni Wade <w...@nvidia.com>

brcmfmac: Handling the interrupt in ISR directly for non-OOB

commit 29c8561c8d6d248f2b6726384815a136c2fbd859
Author: David Jander <david@xxxxxxxxxxx>

[RFC PATCH] i2c-imx.c: Add support for I2C bus fault recovery

commit 5ff30ca8128bb3840350e5902ac68246fbc2aa21
Author: Tapani <tap...@vmail.me>

Fix compile break in arch/arm/plat-mxc/dvfs_core.c when SMP is configured
without CPU_FREQ

commit f21764444c5515ca62b54928ea9dbffaa300cf2d
Author: Tapani <tap...@vmail.me>

Fix compile break when OTG is used as gadget peripheral controller
(cherry picked from commit 59d6b4294f5f43c75a9cf4b3cc12bca9bf122e24)

commit d6f27944e212b1d4e80032c9fcbe09ce6d8ea890
Author: Tapani <tap...@vmail.me>

sound/soc/imx: Make SGTL5000 selectable for any machine

commit 17a9192f88b06174911736bfe78d0698fd0cbd33
Author: Tapani <tap...@vmail.me>

Fix compile break when sound is compiled as modules: ssi and esai were both
compiled into the same module
and both contain a module_init().

commit 5b6342ebde5ebf2647645fd10dfdecbac661d8b9
Author: Tapani <tap...@vmail.me>

Enable headphone jack by default on sgtl5000.

commit 99322e8377fbcb7435ecfab6e42b6c949fa4e88d
Author: Tapani <tap...@vmail.me>

Revert "ENGR00171026 SGTL5000: remove mono support"

[Dave McMordie]

Any chance MIPI CSI capture has been tested and works with this kernel?  I see a bunch of fixes related to this, but I am not clear on whether it is fully working or not.

I am new to Wandboard (and also Linux) and I am bewildered by the numerous kernels, none of which seem to be definitive (IFAICT):

1. LTIB (Freescale official, but apparently they are moving to Yocto?)
2. Yocto
   
3. Robert Nelson's scripts/kernel which incorporate LTIB and other fixes
4. Whatever shipped with the Wandboard Ubuntu image (missing MIPI capture, doesn't work with HDMI->DVI)
5. This kernel (looks to incorporate Yocto wandboard support)

Which of these and/or other options do you recommend as the best choice for reliable, comprehensive hw support on the Wandboard?

[John Weber]

Hi Dave -

Yep. You ask a good question. It would be nice to coalesce around a specific
kernel, but there are different requirements. What do you want to do with
Wandboard?

For kernels, there are at least three options now, and probably more:

1) The default kernel for Wandboard which is maintained by Wandboard.org. This
is based on the Freescale Android kernel tree (3.0.35). This is the one that
ends up in the Android and Ubuntu images available for download on the
Wandboard.org site.

2) The mainline kernel (3.11+), for which Wandboard support is being worked on
by members of this group and others. This kernel does not support GPU/VPU as
far as I know, but has support for most of the other peripherals. One nice
thing that I've seen is that mainline includes the ability for the Broadcom
BCM4329 to work as an access point, which is not supported in the 3.0.35 kernel
I'm maintaining or the orignal Wandboard kernel.

3) The kernel that I'm currently maintaining with the help of others such as
Stephan Rafin. This is based on the Freescale 3.0.35_4.0.0 kernel and we work
to closely track it. This is the default kernel used in the wandboard machines
in Yocto. I also believe that this is the kernel Stephan is using in his XMBC
images. We invite anyone to submit patches for this, but otherwise we're just
working on it, incorporating fixes for the things we are doing with it, and
trying to stay on top of changes to the FSL kernel as we go.

On 8/5/13 10:04 PM, Dave McMordie wrote:
> Any chance MIPI CSI capture has been tested and works with this kernel? I see a
> bunch of fixes related to this, but I am not clear on whether it is fully
> working or not.

I have a working prototype of a 5MP camera using MIPI-CSI on Wandboard, so it
works. The commits to the kernel concerning MIPI are all about getting that
working. As far as I know, these have not been pulled into any of the other
kernels. I'm looking into ways of making this module available to the mass
market.

>
> I am new to Wandboard (and also Linux) and I am bewildered by the numerous
> kernels, none of which seem to be definitive (IFAICT):
>

> 1. LTIB (Freescale official, but apparently they are moving to Yocto?)
> 2. Yocto
> 3. Robert Nelson's scripts/kernel which incorporate LTIB and other fixes
> 4. Whatever shipped with the Wandboard Ubuntu image (missing MIPI capture,

> doesn't work with HDMI->DVI)

> 5. This kernel (looks to incorporate Yocto wandboard support)

[Dave McMordie]

Thanks for your response John.

Yep.  You ask a good question.  It would be nice to coalesce around a specific
kernel, but there are different requirements.   What do you want to do with
Wandboard?

I have just designed an OV5647 MIPI camera board (as part of a computer vision product we're developing)  and was tearing my hair out trying to hack board_wand from Robert Nelson's distribution to make MIPI input work.  So this is a relief.  I will probably have to make some changes to support the OV5647, but the advantage of this camera is that it supports a global shutter.

 

For kernels, there are at least three options now, and probably more:

1) The default kernel for Wandboard which is maintained by Wandboard.org.  This
is based on the Freescale Android kernel tree (3.0.35).  This is the one that
ends up in the Android and Ubuntu images available for download on the
Wandboard.org site.

2) The mainline kernel (3.11+), for which Wandboard support is being worked on
by members of this group and others.  This kernel does not support GPU/VPU as
far as I know, but has support for most of the other peripherals.  One nice
thing that I've seen is that mainline includes the ability for the Broadcom
BCM4329 to work as an access point, which is not supported in the 3.0.35 kernel
I'm maintaining or the orignal Wandboard kernel.

3) The kernel that I'm currently maintaining with the help of others such as
Stephan Rafin.  This is based on the Freescale 3.0.35_4.0.0 kernel and we work
to closely track it.  This is the default kernel used in the wandboard machines
in Yocto.  I also believe that this is the kernel Stephan is using in his XMBC
images.  We invite anyone to submit patches for this, but otherwise we're just
working on it, incorporating fixes for the things we are doing with it, and
trying to stay on top of changes to the FSL kernel as we go.

You leave out the Robert Nelson kernel.  Any sense of how it fits in?  It seems to pull changes from Freescale and other places, so I am curious how much support it offers relative to the other options. 

 

On 8/5/13 10:04 PM, Dave McMordie wrote:
> Any chance MIPI CSI capture has been tested and works with this kernel?  I see a
> bunch of fixes related to this, but I am not clear on whether it is fully
> working or not.

I have a working prototype of a 5MP camera using MIPI-CSI on Wandboard, so it
works.  The commits to the kernel concerning MIPI are all about getting that
working. As far as I know, these have not been pulled into any of the other
kernels.  I'm looking into ways of making this module available to the mass
market.

I would love to buy one of these as a reference design when it is available.

Any tips for adding new camera support using this kernel?  For example, do I need to modify the I2C address of the camera in board_wand.c?  And obviously a new driver with the correct register settings for the camera must be loaded.

[Robert Nelson]

My 'v3.0.x-wand' branch is entirely based on the original wandboard kernel fork:

http://repo.or.cz/w/wandboard.git/shortlog/refs/heads/wandboard

plus a few native build patches required for the various deb distro's..

But do not get too attached to it, as maintaining bsp kernel forks
does not interest me, only mainline does. At this point on v3.11-rc4
+ what's heading for v3.12-rc0, we already have implemented...

usb/wifi/video on the Dual + sata on the Quad (the solo is still left out..)

So other then the solo, my v3.0.x-wand branch is on strick maintenance
mode that this point..

Regards

--
Robert Nelson
http://www.rcn-ee.com/

[John Weber]

Robert,

> But do not get too attached to it, as maintaining bsp kernel forks
> does not interest me, only mainline does. At this point on v3.11-rc4
> + what's heading for v3.12-rc0, we already have implemented...
>
> usb/wifi/video on the Dual + sata on the Quad (the solo is still left out..)
>

When you mention video above, does that mean VPU support?

John

[Otavio Salvador]

I think he means HDMI support.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://projetos.ossystems.com.br
Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750

[Robert Nelson]

On Tue, Aug 6, 2013 at 8:15 AM, Otavio Salvador <ota...@ossystems.com.br> wrote:
> On Tue, Aug 6, 2013 at 10:08 AM, John Weber <rjohn...@gmail.com> wrote:
>>> But do not get too attached to it, as maintaining bsp kernel forks
>>> does not interest me, only mainline does. At this point on v3.11-rc4
>>> + what's heading for v3.12-rc0, we already have implemented...
>>>
>>> usb/wifi/video on the Dual + sata on the Quad (the solo is still left
>>> out..)
>>>
>>
>> When you mention video above, does that mean VPU support?
>
> I think he means HDMI support.

'video' out on the hdmi port, using the 'imx-drm' kms kernel driver:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/imx-drm

Regards,

[John Weber]

Hi Dave -

>
> I have just designed an OV5647 MIPI camera board (as part of a computer vision
> product we're developing) and was tearing my hair out trying to hack board_wand
> from Robert Nelson's distribution to make MIPI input work. So this is a relief.
> I will probably have to make some changes to support the OV5647, but the
> advantage of this camera is that it supports a global shutter.
>
>

Global shutter would be great. Looking at the brief online, but appears that
the camera is a raw image sensor, so no YCrCb output. Because the i.MX6 doesn't
have an image pipe, it would need to use CPU for demosaicking and then
colorspace conversion (although I think the IPU might have colorspace conversion
built-in).

You shouldn't have to do much hacking on board-wand.c to get the MIPI interface
working. The main thing you'll need to be concerned about is the sensor driver
itself, since I'm guessing that the OV5647 does not have the same register
set/programming model as the OV5640.

John

[Dave McMordie]

Great, thanks.  Kernel is building now; I may start another thread once I have results either working or not.

I've put together a small grid to reflect my incomplete understanding of the kernel comparison.  Please feel free to edit/correct so that others have a better reference on this:

Kernel dist	Notes	VPU	HDMI	Wifi	Video capture	Sound	SATA	Source
Freescale LTIB	Limited wandboard support	?	?	?	?	?	?
Robert Nelson	No new dev—> mainline	Y	Y	Y	N	Y	Y	http://eewiki.net/display/linuxonarm/Wandboard
Yocto  (John Weber)		Y	Y	Y	Y	Y	?	https://github.com/johnweber/linux.git
Wandboard official		Y	N	Y	N	Y	?	http://repo.or.cz/w/wandboard.git/shortlog/refs/heads/wandboard
Mainline Linux		Y	?	Y	Y	Y	Y	https://github.com/Freescale/linux-mainline

[Robert Nelson]

There's no difference between mine (Robert Nelson) and the Wandboard official as far as "features" as it's the exact same source (plus a few debian fixes).. Thus there is no point to differentiate them...

Your mainline kernel link should be:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/

+

https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=shortlog;h=refs/heads/for-next

Till v3.12-rc1 gets tagged...

Regards,

[Dave McMordie]

Some questions about the MIPI support.  

1) I noticed mxc_mipi_csi2.ko is not built by the wandboard_defconfig target.  I assume I should enable this and rebuild-- is that correct?

2) My sensor is at I2C address 0x6C.  I noticed that in board_wand.c the address listed on line 635 is 0x3C (half the value of the I2C address for the OV5640/OV5642.  I guess I need to change this to 0x36 (half my address).  Is this correct, and can you shed any light on the half thing?

3) Not sure of the startup procedure, or how you get images.  Here's what I am doing (not sure it is right at all):

Load drivers manually:

insmod /lib/modules/`uname -r`/drivers/mxc/mipi/mxc_mipi_csi2.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/camera_sensor_clock.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_bg_overlay_sdc.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_fg_overlay_sdc.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_prp_enc.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_csi_enc.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_still.ko

insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/mxc_v4l2_capture.ko

dmesg -c

Next I load my driver:

insmod ov5647_mipi.ko

Then I check that the device nodes have appeared (in my case video1, since there is a UVC device on video0).

Next I run VLC and try to load /dev/video1 as a V4L2 device.

What steps do you do to load the camera and capture?

Best,

Dave

[John Weber]

Hi Dave,

Sata should work on my kernel.� I haven't personally tested though.

Freescale LTIB is not a kernel.� I would take it off this list.

Wandboard official HDMI works, but there is some question about EDID/DDC and the use of HDMI to DVI converters.� The EDID/DDC question pervades all the kernels, as far as I know.� SATA probably works there as well, but I don't use this kernel.

I don't know of anyone doing Video capture in Mainline, but it shouldn't be an issue.� The main problem there is the backend drivers for sensors and using the VPU/IPU.

This looks like the start of a useful wiki page for wiki.wandboard.org.� A lot more columns need to be added.

Kernel dist

Notes

VPU

HDMI

Wifi

Video capture

Sound

SATA

Source

Linux 3.0.35� (John Weber)	Non Android/Linux use Used in Yocto and XMBC	Y	Y (EDID?)	Y	Y	Y	Should work, needs comment	https://github.com/johnweber/linux.git Branch: wandboard_imx_3.0.35_3.0.0
Android 3.0.35 (Wandboard official)	Android use ideally	Y	Y (EDID?)	Y	N	Y	Should work, needs comment	http://repo.or.cz/w/wandboard.git/shortlog/refs/heads/wandboard�
Mainline Linux	The bleeding edge	N	Y (EDID?)	Y	N	Y	Y

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ + https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=shortlog;h=refs/heads/for-next

John

On 8/6/13 8:32 AM, Dave McMordie wrote:

Great, thanks. �Kernel is building now; I may start another thread once I have results either working or not.

I've put together a small grid to reflect my incomplete understanding of the kernel comparison. �Please feel free to edit/correct so that others have a better reference on this:

Kernel dist

Notes

VPU

HDMI

Wifi

Video capture

Sound

SATA

Source

Freescale LTIB

Limited wandboard support

?

?

?

?

?

?

�
Robert Nelson	No new dev�> mainline

Y

Y

Y

N

Y

Y

http://eewiki.net/display/linuxonarm/Wandboard

Yocto� (John Weber)	�

Y

Y

Y

Y

Y

�?	https://github.com/johnweber/linux.git
Wandboard official	�

Y

N

Y

N

Y

�?	http://repo.or.cz/w/wandboard.git/shortlog/refs/heads/wandboard�
Mainline Linux	�

Y

?

Y

Y

Y

Y

https://github.com/Freescale/linux-mainline

--
You received this message because you are subscribed to the Google Groups "Wandboard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wandboard+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
�
�

[Robert Nelson]

On Tue, Aug 6, 2013 at 9:06 AM, John Weber <rjohn...@gmail.com> wrote:

Hi Dave,

Sata should work on my kernel.  I haven't personally tested though.

Freescale LTIB is not a kernel.  I would take it off this list.

Wandboard official HDMI works, but there is some question about EDID/DDC and the use of HDMI to DVI converters.  The EDID/DDC question pervades all the kernels, as far as I know.  SATA probably works there as well, but I don't use this kernel.

I don't know of anyone doing Video capture in Mainline, but it shouldn't be an issue.  The main problem there is the backend drivers for sensors and using the VPU/IPU.

This looks like the start of a useful wiki page for wiki.wandboard.org.  A lot more columns need to be added.

Kernel dist

Notes

VPU

HDMI

Wifi

Video capture

Sound

SATA

Source

Linux 3.0.35  (John Weber)

Non Android/Linux use Used in Yocto and XMBC

Y

Y (EDID?)

Y

Y

Y

Should work, needs comment

https://github.com/johnweber/linux.git Branch: wandboard_imx_3.0.35_3.0.0

Android 3.0.35 (Wandboard official)

Android use ideally

Y

Y (EDID?)

Y

N

Y

Should work, needs comment

http://repo.or.cz/w/wandboard.git/shortlog/refs/heads/wandboard

Mainline Linux

The bleeding edge

N

Y (EDID?)

Y

N

Y

Y

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/ + https://git.linaro.org/gitweb?p=people/shawnguo/linux-2.6.git;a=shortlog;h=refs/heads/for-next

John

edid works on the mainline patches.. although, it's still early and limited, but more monitors work on my quad with hdmi/dvi converters then the wandboard tree ever did..

Regards,

[John Weber]

On 8/6/13 9:04 AM, Dave McMordie wrote:
> Some questions about the MIPI support.
>
> 1) I noticed mxc_mipi_csi2.ko is not built by the wandboard_defconfig target.
> I assume I should enable this and rebuild-- is that correct?
> 2) My sensor is at I2C address 0x6C. I noticed that in board_wand.c the
> address listed on line 635 is 0x3C (half the value of the I2C address for the
> OV5640/OV5642. I guess I need to change this to 0x36 (half my address). Is
> this correct, and can you shed any light on the half thing?

The I2C address is 7-bits. The LSB is the R/W bit.

> 3) Not sure of the startup procedure, or how you get images. Here's what I am
> doing (not sure it is right at all):
>
> Load drivers manually:
>
> insmod /lib/modules/`uname -r`/drivers/mxc/mipi/mxc_mipi_csi2.ko
> insmod /lib/modules/`uname
> -r`/drivers/media/video/mxc/capture/camera_sensor_clock.ko
> insmod /lib/modules/`uname
> -r`/drivers/media/video/mxc/capture/ipu_bg_overlay_sdc.ko
> insmod /lib/modules/`uname
> -r`/drivers/media/video/mxc/capture/ipu_fg_overlay_sdc.ko
> insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_prp_enc.ko
> insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_csi_enc.ko
> insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/ipu_still.ko
> insmod /lib/modules/`uname -r`/drivers/media/video/mxc/capture/mxc_v4l2_capture.ko

You should not have to load all of these manually as long as the module
dependencies are setup right. In Yocto, I just modprobe mxc_v4l2_capture and
that brings in all of the ipu modules. I have the mxc_mipi_csi2 driver built-in
to the kernel. The ov5640 module loads automatically (with the
camera_sensor_clock module) when the platform data is set up correctly (i.e. the
board_wand.c file).

What root filesystem and build system are you using?

>
> dmesg -c
>
> Next I load my driver:
>
> insmod ov5647_mipi.ko

Cool! If you want to contribute it, let me know.

>
> Then I check that the device nodes have appeared (in my case video1, since
> there is a UVC device on video0).
>
> Next I run VLC and try to load /dev/video1 as a V4L2 device.
>
> What steps do you do to load the camera and capture?

I first used mxc_v4l2_capture.out in the /unit_tests directory. That gave me a
raw image file that I could inspect using GIMP (although that needed a good bit
of tweaking to see if I could get a useful image). Once I was reasonably
confident that what I was seeing was good image data, I started using gstreamer.

gst-launch -v mfw_v4lsrc fps-n=30 capture-mode=4 ! vpuenc codec=6
bitrate=4000000 ! rtph264pay ssrc=1 timestamp-offset=0 seqnum-offset=0 !
udpsink host=192.168.0.125 port=5000

In this case, I was streaming the video over a network using RTP. This could
probably be modified to view the image data on the HDMI display.

John

[Wand Board]

Maybe a suggestion is to migrate this table into the wiki at some point.

--
You received this message because you are subscribed to the Google Groups "Wandboard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wandboard+unsubscribe@googlegroups.com.

[Dave McMordie]

Thanks very much for your help.

My driver now loads correctly, though it will do nothing useful until I set up the registers. 

For the de-bayer, the reference manual lists Raw (Bayer) as supported input format.  If you see red flags suggesting this won't work or will be tough, please let me know.  I literally have no experience writing Linux drivers, but it doesn't look too tough from where I sit.

On 8/6/13 9:04 AM, Dave McMordie wrote:
> Some questions about the MIPI support.

dependencies are setup right.  In Yocto, I just modprobe mxc_v4l2_capture and
that brings in all of the ipu modules.  I have the mxc_mipi_csi2 driver built-in
to the kernel.  The ov5640 module loads automatically (with the
camera_sensor_clock module) when the platform data is set up correctly (i.e. the
board_wand.c file).

I grabbed the modules.dep from a Yocto build-- I couldn't figure out how to get the kernel build system to generate it  (I am building on the device with make ARCH=arm -j5).

 

What root filesystem and build system are you using?

Linaro Ubuntu 12.04.  It seems to be lacking a bunch of things (like hw video acceleration), but it gives me a useful desktop environment to do dev on.  I find cross compiling a hassle, and the device is fast enough with -j5.

 

>
> dmesg -c
>
> Next I load my driver:
>
> insmod ov5647_mipi.ko
Cool!  If you want to contribute it, let me know.

When it is up and running I'll send it your way for inclusion.

 

>
> Then I check that the device nodes have appeared (in my case video1, since
> there is a UVC device on video0).
>
> Next I run VLC and try to load /dev/video1 as a V4L2 device.
>
> What steps do you do to load the camera and capture?
I first used mxc_v4l2_capture.out in the /unit_tests directory. That gave me a
raw image file that I could inspect using GIMP (although that needed a good bit
of tweaking to see if I could get a useful image).  Once I was reasonably
confident that what I was seeing was good image data, I started using gstreamer.

gst-launch -v mfw_v4lsrc fps-n=30 capture-mode=4  ! vpuenc codec=6
bitrate=4000000  ! rtph264pay ssrc=1 timestamp-offset=0 seqnum-offset=0 !
udpsink host=192.168.0.125 port=5000

In this case, I was streaming the video over a network using RTP. This could
probably be modified to view the image data on the HDMI display.

Thanks again for all your help. 

[John Weber]

On 8/6/13 10:34 AM, Dave McMordie wrote:

Thanks very much for your help.

My driver now loads correctly, though it will do nothing useful until I set up the registers. 

For the de-bayer, the reference manual lists Raw (Bayer) as supported input format.  If you see red flags suggesting this won't work or will be tough, please let me know.  I literally have no experience writing Linux drivers, but it doesn't look too tough from where I sit.

Other processors (TI DM3xx, DM37xx, DM8xxx) have built-in image pipe for de-bayer (color interpolation).  This processor does not, even though Bayer is a supported input format.  So, you should be straight bayer in memory, and would need to postprocess this using the CPU or maybe the GPU using openCL or something like that.  It can convert from RGB to YUV in the IPU, but you might not care to do that since I believe with the right matrix you can demosaic and CSC in the same step.

On 8/6/13 9:04 AM, Dave McMordie wrote:
> Some questions about the MIPI support.


dependencies are setup right.  In Yocto, I just modprobe mxc_v4l2_capture and
that brings in all of the ipu modules.  I have the mxc_mipi_csi2 driver built-in
to the kernel.  The ov5640 module loads automatically (with the
camera_sensor_clock module) when the platform data is set up correctly (i.e. the
board_wand.c file).

I grabbed the modules.dep from a Yocto build-- I couldn't figure out how to get the kernel build system to generate it  (I am building on the device with make ARCH=arm -j5).

What root filesystem and build system are you using?

Linaro Ubuntu 12.04.  It seems to be lacking a bunch of things (like hw video acceleration), but it gives me a useful desktop environment to do dev on.  I find cross compiling a hassle, and the device is fast enough with -j5.

I hear you about cross compiling.  I won't be able to help much with an Ubuntu system.

 

>
> dmesg -c
>
> Next I load my driver:
>
> insmod ov5647_mipi.ko
Cool!  If you want to contribute it, let me know.

When it is up and running I'll send it your way for inclusion.

 

>
> Then I check that the device nodes have appeared (in my case video1, since
> there is a UVC device on video0).
>
> Next I run VLC and try to load /dev/video1 as a V4L2 device.
>
> What steps do you do to load the camera and capture?
I first used mxc_v4l2_capture.out in the /unit_tests directory. That gave me a
raw image file that I could inspect using GIMP (although that needed a good bit
of tweaking to see if I could get a useful image).  Once I was reasonably
confident that what I was seeing was good image data, I started using gstreamer.

gst-launch -v mfw_v4lsrc fps-n=30 capture-mode=4  ! vpuenc codec=6
bitrate=4000000  ! rtph264pay ssrc=1 timestamp-offset=0 seqnum-offset=0 !
udpsink host=192.168.0.125 port=5000

In this case, I was streaming the video over a network using RTP. This could
probably be modified to view the image data on the HDMI display.

Thanks again for all your help. 

--
You received this message because you are subscribed to the Google Groups "Wandboard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to wandboard+...@googlegroups.com.

[Dave McMordie]

Some progress-- it is definitely loading my driver, configuring camera registers, etc.  I also found another mipi driver for the OV5647 which offers the register settings.

However, I am getting nothing but "mipi csi2 can not receive sensor clk" (my driver is a copy of ov5640_mipi with changes to the register setup).  Digging into this, I noticed a post on Freescale about configuring the mux to use the MIPI gasket rather than parallel, and then I saw the following code in our board-wand.c:

/* For MX6Q:

* GPR1 bit19 and bit20 meaning:

* Bit19:       0 - Enable mipi to IPU1 CSI0

*                      virtual channel is fixed to 0

*              1 - Enable parallel interface to IPU1 CSI0

* Bit20:       0 - Enable mipi to IPU2 CSI1

*                      virtual channel is fixed to 3

*              1 - Enable parallel interface to IPU2 CSI1

* IPU1 CSI1 directly connect to mipi csi2,

*      virtual channel is fixed to 1

* IPU2 CSI0 directly connect to mipi csi2,

*      virtual channel is fixed to 2

*

* For MX6DL:

* GPR13 bit 0-2 IPU_CSI0_MUX

*   000 MIPI_CSI0

*   100 IPU CSI0

*/

if (cpu_is_mx6q())

mxc_iomux_set_gpr_register(1, 19, 1, 0); 

else if (cpu_is_mx6dl())

mxc_iomux_set_gpr_register(13, 0, 3, 0);

To me this looks like the parallel interface is enabled by default.  Does this get overridden somewhere in the sensor driver?

I've actually gone through most of the register setup to look for issues with the PLL setup and MIPI enable (which look okay), but what I am seeing on the scope is no clk or data on the lanes.  Input clock the chip is a 24 MHz clock generator (any chance I am required to use the board's clock output?).

[John Weber]

Hi Dave,

No. That is setting bit 19 to 0 which routes mipi to the IPU.  I made that change to get the ov5640 working on Quad. 

John

—

--

[Dave McMordie]

On Wednesday, August 7, 2013 9:31:04 AM UTC-4, John Weber wrote:

Hi Dave,

No. That is setting bit 19 to 0 which routes mipi to the IPU.  I made that change to get the ov5640 working on Quad. 

Thanks for the clarification; I should have checked the header file (took me a while to find the plat-mxc/mach folder)-- the semantics confused me, but I get it now.

Turns out the issue was using an external clock generator.  Looks like the CSI clock lane needs to be synchronous with the MX6's clock as its PLL source.  Now I am getting the sensor clock and data from the sensor (likely all garbage for now).

 

[John Weber]

You may be right.  I tried using an on-board clock oscillator as well, and I don't think I was ever able to get it to work with it, but there were lots of things changing at the time.  Ultimately I wanted to use the 24Mhz source from the processor due to cost, so as soon as I got that working I pulled the oscillator off.

[Dave McMordie]

Hi again John,

On Wednesday, August 7, 2013 11:39:53 AM UTC-4, John Weber wrote:

You may be right.  I tried using an on-board clock oscillator as well, and I don't think I was ever able to get it to work with it, but there were lots of things changing at the time.  Ultimately I wanted to use the 24Mhz source from the processor due to cost, so as soon as I got that working I pulled the oscillator off.

As soon as I switched to the processor generated clock, it syncs every time.  However I am not getting frames. (ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0).  VLC is able to open the dev node, get all kinds of info and start pre-buffering without errors.  It just times out waiting for the actual frames.  I am starting to thing this is because the IPU is not comfortable with the V4L2_PIX_FMT_SBGGR10 format.  Based on input from this thread (https://community.freescale.com/message/312336#312336), I have added the following code to mxc_v4l_capture to make sure the frame buffers are adequate for what will be 16 bit data:

case V4L2_PIX_FMT_SBGGR10:

     size = f->fmt.pix.width * f->fmt.pix.height * 2;

     bytesperline = f->fmt.pix.width * 2;

     break;

However, this, and correctly declaring the image format (as opposed to faking it as UYVY) doesn't seem to make any difference to the frame timeout issue.

On the scope, I don't see anything recognizable as clock on the clock lane, but I do see tons of what looks like noise over a 0.5 V flatline.  My scope is a 5 GS/s Tektronix with 1.5 GHz probes.  I have no experience probing this kind of bus and have a feeling it could be working fine despite what I see (due to the noise immunity of the bus, and I may also simply be missing the frames).  Also, it I touch the lines while it is coming up it fails to get the clock (suggesting that when it says it is working it is indeed working).  Were you able to successfully probe clock/data lines on your sensor board?

The fact that the mipi registers are claiming the clock is stable (error1 != 0x200) and data is coming (error1 != 0x0)-- does that suggest to you that all is good, or could this indeed be a signal integrity problem?

If this is not a signal integrity issue, can you think of anything special I should look at which would help me identify why I am not getting frames?  I am going through the mxc_v4l2_capture code now to turn on tracing wherever I can.

Thanks again for your help with this.  I am hoping this discussion will help others integrate more sensors into this platform.

Dave

[John Weber]

On 8/8/13 10:04 AM, Dave McMordie wrote:

Hi again John,

On Wednesday, August 7, 2013 11:39:53 AM UTC-4, John Weber wrote:

You may be right.  I tried using an on-board clock oscillator as well, and I don't think I was ever able to get it to work with it, but there were lots of things changing at the time.  Ultimately I wanted to use the 24Mhz source from the processor due to cost, so as soon as I got that working I pulled the oscillator off.

As soon as I switched to the processor generated clock, it syncs every time. 

Good!

However I am not getting frames. (ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0).

Crap.  But this is the error I saw before I changed the internal routing from the CSI to the IPU.  It seems like v4L2 is waiting for a buffer from the capture driver, and when it doesn't get one, it times out.  There are two IPUs on the Quad.  I wonder if you could be listening on the wrong one?  Can you share the mods you have done to the board_wand.c file?  A patch would be perfect.

 VLC is able to open the dev node, get all kinds of info and start pre-buffering without errors.  It just times out waiting for the actual frames.  I am starting to thing this is because the IPU is not comfortable with the V4L2_PIX_FMT_SBGGR10 format.  Based on input from this thread (https://community.freescale.com/message/312336#312336), I have added the following code to mxc_v4l_capture to make sure the frame buffers are adequate for what will be 16 bit data:

case V4L2_PIX_FMT_SBGGR10:

     size = f->fmt.pix.width * f->fmt.pix.height * 2;

     bytesperline = f->fmt.pix.width * 2;

     break;

However, this, and correctly declaring the image format (as opposed to faking it as UYVY) doesn't seem to make any difference to the frame timeout issue.

On the scope, I don't see anything recognizable as clock on the clock lane, but I do see tons of what looks like noise over a 0.5 V flatline.  My scope is a 5 GS/s Tektronix with 1.5 GHz probes.  I have no experience probing this kind of bus and have a feeling it could be working fine despite what I see (due to the noise immunity of the bus, and I may also simply be missing the frames).  Also, it I touch the lines while it is coming up it fails to get the clock (suggesting that when it says it is working it is indeed working).  Were you able to successfully probe clock/data lines on your sensor board?

I was able to.  They are very low amplitude signals by design, around 200mV p-p.  I think the common mode was around 0.7-0.8V. On my scope I did get a look at it, but it wasn't a great look since there was a lot of ground AC noise, but I was able to see square waves on the clock and data lines.

The fact that the mipi registers are claiming the clock is stable (error1 != 0x200) and data is coming (error1 != 0x0)-- does that suggest to you that all is good, or could this indeed be a signal integrity problem?

I didn't have to dig this far to get the OV5640 working.  It could still be SI, but that seems doubtful.

If this is not a signal integrity issue, can you think of anything special I should look at which would help me identify why I am not getting frames?  I am going through the mxc_v4l2_capture code now to turn on tracing wherever I can.

I suspect that you're running into something with the internal CSI to IPU routing or as you suspected it could be an image format problem.

Thanks again for your help with this.  I am hoping this discussion will help others integrate more sensors into this platform.

No problem.  I would push this to the Freescale Community now though, since it seems that we are the only folks talking here and there could be more knowledgeable people on that forum.  If you do that, send me a message with the URL and I'll go follow it.

Dave

[Dave McMordie]

On Thursday, August 8, 2013 11:27:50 AM UTC-4, John Weber wrote:

Crap.  But this is the error I saw before I changed the internal routing from the CSI to the IPU.  It seems like v4L2 is waiting for a buffer from the capture driver, and when it doesn't get one, it times out.  There are two IPUs on the Quad.  I wonder if you could be listening on the wrong one?  Can you share the mods you have done to the board_wand.c file?  A patch would be perfect.

I am so new to Linux that I am not sure what a patch is exactly :).  Here is the output of diff on the original board_wand.c and mine:

638,641d637

<  {

<  I2C_BOARD_INFO("ov5647_mipi", 0x36),

<  .platform_data = (void *)&wand_mipi_csi2_data,

<  },

I didn't have to dig this far to get the OV5640 working.  It could still be SI, but that seems doubtful. 

That's what I think-- I am proceeding on the basis that it is a driver issue. 

I suspect that you're running into something with the internal CSI to IPU routing or as you suspected it could be an image format problem.

I will double check that, but what is in board_wand.c looked okay to me (and I didn't change it).  I will look more at the image format possibility. 

Thanks again for your help with this.  I am hoping this discussion will help others integrate more sensors into this platform.

No problem.  I would push this to the Freescale Community now though, since it seems that we are the only folks talking here and there could be more knowledgeable people on that forum.  If you do that, send me a message with the URL and I'll go follow it.

Will do.

 

[Dave McMordie]

Here's the discussion at Freescale:

https://community.freescale.com/thread/310786

[Dave McMordie]

Hi John,

Still not getting anywhere with the camera, except now I have data flowing which I can see on the scope (was a camera setting).  There is one question I have which pertains to this thread about the kernel:

How can I ensure that I configure the kernel exactly the same way you did for building?

Best,

Dave

[John Weber]

Hi Dave,

If you checkout the Wandboard kernel I use in Yocto, the defconfig in
arch/arm/configs/wandboard_defconfig is the one I'm using.

Of particular importance is the driver you are developing for the image sensor.
Can you post the driver and/or kernel somewhere? Or tarball up a patch? I'm no
expert in v4l2 driver development but I'll take a look if you provide a link.
Others on this list might be interested too.

Thanks,
John

[Dave McMordie]

Okay, makes sense.  Do I manually copy the defconfig, to .config in the kernel distro, or is it selected with a make target?

The driver, such as it is, is located at:

http://www.viionsystems.com/UbuntuImages/ov5647_mipi.c

I would certainly be grateful for your feedback.  The register settings come straight from OmniVision and I have verified with them that my MIPI clock rate is set correctly.  I can now scope data coming out of the camera, but no joy.

By the way, are you planning to make your ov5640 camera for the wandboard available, and if so, when do you expect?

Best,

Dave

[Dave McMordie]

And another question about the pairing of kernels and rootfses:

As I mentioned, I built my rootfs with the linaro toolchain (armhf) following Robert Nelson's instructions, but am using the Yocto kernel from this thread.  This gives me all the drivers, like galcore, but doesn't give me the freescale platform libraries or unit tests, and so I have been using generic V4L2 test code and/or VLC to test image capture.

Can you think of any way I can get the platform libraries and unit test code built into this rootfs?

Should I just move to a Yocto image?  I tried that, but found there was no apt-get/deb in any of the targets, which is kind of my lifeline to get things done, and I couldn't figure out how to install it.  Is it possible to build a Yocto rootfs which runs Ubuntu with gnome, for example?  Should I give up and stick to command-line tools?

[Dave McMordie]

I've just got the unit tests built by following these instructions:

https://community.freescale.com/docs/DOC-95387

[John Weber]

Hi Dave -

On 8/30/13 8:58 AM, Dave McMordie wrote:
> And another question about the pairing of kernels and rootfses:
>
> As I mentioned, I built my rootfs with the linaro toolchain (armhf) following
> Robert Nelson's instructions, but am using the Yocto kernel from this thread.
> This gives me all the drivers, like galcore, but doesn't give me the
> freescale platform libraries or unit tests, and so I have been using generic
> V4L2 test code and/or VLC to test image capture.

Yep - There are lots of userland platform pieces that you need. Yocto is
designed to manage these dependencies and bring them in as part of the machine
definition.

>
> Can you think of any way I can get the platform libraries and unit test code
> built into this rootfs?

You've seen some instructions on FSL, but I really think you're doing a lot of
work that has already been done.

>
> Should I just move to a Yocto image? I tried that, but found there was no
> apt-get/deb in any of the targets, which is kind of my lifeline to get things
> done, and I couldn't figure out how to install it. Is it possible to build a
> Yocto rootfs which runs Ubuntu with gnome, for example? Should I give up and
> stick to command-line tools?

You can use a variety of package managers with Yocto. Apt is one of them, rpm
is as well. The thing is we don't have a remote repository set up in Yocto/Poky
for Wandboard or any i.MX6 as far as I know. Angstrom [1] would, which does do
this and is Yocto-based, but I don't know of any i.MX6 platforms in Angstrom.

The ultimate is, in my view, to have a system like Narcissus [2] set up for
Wandboard (or Narcissus itself) so that application developers can shortcut the
platform development process while at the same time being able to replicate the
platform from source if needed.

[1] http://www.angstrom-distribution.org/
[2] http://narcissus.angstrom-distribution.org/

[Dave McMordie]

After rebuilding the Yocto kernel and changing the format in my driver back to 10 bit SGBBR, I am now getting images from the sensor.  I am not exactly sure what changed, but one of the things I did was rollback a bunch of changes I had made to the kernel v4l2 driver stack (on the advice of other threads), removing explicit support for SGBBR/Generic support.  In the end, the changes I made to the kernel consisted of:

- setting the mipi clock for 280 Mbps operation (mxc_mipi_csi2.c)

- removing the "CSI IC MEM" option from v4l2_input_mxc_capture_inputs (so the only option is CSI MEM) in mxc_v4l2_capture

- adding the i2c support for this chip in board_wand.c

The final trick may just have been running Freescale's unit test utility, which I built according to the reference above.  That was what worked first, but now all my V4L2 test utilities seem to get frames (althought VLC cannot debayer and display SGBBR images).

Thanks very much for your help in this thread.

Here's a full patch of my changes to the kernel for the curious.  I have also attached the working version of the driver.

diff --git a/arch/arm/mach-mx6/board-wand.c b/arch/arm/mach-mx6/board-wand.c

old mode 100644

new mode 100755

index 110bf84..dc0ce41

--- a/arch/arm/mach-mx6/board-wand.c

+++ b/arch/arm/mach-mx6/board-wand.c

@@ -635,6 +635,10 @@ static struct i2c_board_info wand_mipi_csi_i2c_board_info[] __initdata = {

  I2C_BOARD_INFO("ov5640_mipi", 0x3C),

  .platform_data = (void *)&wand_mipi_csi2_data,

  },

+ {

+ I2C_BOARD_INFO("ov5647_mipi", 0x36),

+ .platform_data = (void *)&wand_mipi_csi2_data,

+ },

 };

 

 /* Platform data for MIPI CSI init */

diff --git a/drivers/media/video/mxc/capture/mxc_v4l2_capture.c b/drivers/media/video/mxc/capture/mxc_v4l2_capture.c

index 3e81f1c..343ed45 100644

--- a/drivers/media/video/mxc/capture/mxc_v4l2_capture.c

+++ b/drivers/media/video/mxc/capture/mxc_v4l2_capture.c

@@ -48,7 +48,7 @@ static int video_nr = -1;

 

 /*! This data is used for the output to the display. */

 #define MXC_V4L2_CAPTURE_NUM_OUTPUTS 6

-#define MXC_V4L2_CAPTURE_NUM_INPUTS 2

+#define MXC_V4L2_CAPTURE_NUM_INPUTS 1

 static struct v4l2_output mxc_capture_outputs[MXC_V4L2_CAPTURE_NUM_OUTPUTS] = {

  {

  .index = 0,

@@ -101,7 +101,7 @@ static struct v4l2_output mxc_capture_outputs[MXC_V4L2_CAPTURE_NUM_OUTPUTS] = {

 };

 

 static struct v4l2_input mxc_capture_inputs[MXC_V4L2_CAPTURE_NUM_INPUTS] = {

- {

+    /*{

  .index = 0,

  .name = "CSI IC MEM",

  .type = V4L2_INPUT_TYPE_CAMERA,

@@ -109,9 +109,9 @@ static struct v4l2_input mxc_capture_inputs[MXC_V4L2_CAPTURE_NUM_INPUTS] = {

  .tuner = 0,

  .std = V4L2_STD_UNKNOWN,

  .status = 0,

- },

+     },*/

  {

- .index = 1,

+     .index = 1,

  .name = "CSI MEM",

  .type = V4L2_INPUT_TYPE_CAMERA,

  .audioset = 0,

 

diff --git a/drivers/mxc/mipi/mxc_mipi_csi2.c b/drivers/mxc/mipi/mxc_mipi_csi2.c

index 1f051df..b68637b 100644

--- a/drivers/mxc/mipi/mxc_mipi_csi2.c

+++ b/drivers/mxc/mipi/mxc_mipi_csi2.c

@@ -286,7 +286,7 @@ int mipi_csi2_reset(struct mipi_csi2_info *info)

  mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);

  mipi_csi2_write(info, 0x00010044, CSI2_PHY_TST_CTRL1);

  mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);

- mipi_csi2_write(info, 0x00000014, CSI2_PHY_TST_CTRL1);

+    mipi_csi2_write(info, 0x00000028, CSI2_PHY_TST_CTRL1);  // DMJM: change clock from 14 to 28 (to 280 Mbps) for OV5647

  mipi_csi2_write(info, 0x00000002, CSI2_PHY_TST_CTRL0);

  mipi_csi2_write(info, 0x00000000, CSI2_PHY_TST_CTRL0);

[Dave McMordie]

More on this exciting (excruciating?) R&D drama.  When I reboot it comes back with the same behaviour I have been seeing for weeks: it doesn't get the frame interrupts.

To make it work I do the following: 

1. I set the format of the driver on line 1622 of the driver file to V4L2_PIX_FMT_UYVY.
   
2. Compile the driver
3. Unload and reload the capture drivers
4. Attempt capture -> it fails
5. Set the pixel format back to V4L2_PIX_FMT_SBGGR10, recompile, reload drivers
6. Attempt capture -> it works

I will post this info in my freescale thread to see if any sanity emerges.

Best,

Dave

[Đinh Công Bằngd]

Dear Mr Dave,

     Are you porting on Android 4.2? I am porting a mipi camera on android ICS, sames ICS does not support bayer RAW,so i could not received data from camera, my camera is output RAW10 format. 

[Dave McMordie]

Hi Mr. Đinh,

I am not using Android at all; my target system is Ubuntu (Linaro).  However, I noted on the freescale forum a thread discussing debayering in ICS using OpenGL:

https://community.freescale.com/thread/309817

I hope this is some help to you.  Also, if you search the freescale forums you will find some information about capturing from a Bayer source over MIPI.  As long as the camera is connected to virtual channel 0 (IPU0 / CSI0), you should be fine-- just make the changes to the freescale kernel described in the threads regarding Bayer/Raw capture.  If you try to connect a Bayer sensor to another channel you will need to make changes to the kernel driver at a deeper level as there is a bug on channel mapping when capturing raw over MIPI.

Hope this helps.

Dave

[Đinh Công Bằngd]

Hi Mr Dave,

      My camera is connected to VC0, IPU0, CSI0, and I edited in kernel like at here https://github.com/mcmordie/linux/compare/johnweber:wandboard_imx_3.0.35_4.0.0...wandboard_imx_3.0.35_4.0.0, but preview is as attach file and i received a warring " IPU1_INT_STAT_5=0x00000001", my camera has clock 880MHZ, 2 lanes, and i had configure as below:

.mclk = 24000000,

.mclk_source = 0,

.csi = 0,

.io_init = mx6q_mipi_sensor_io_init,

.pwdn = mx6q_mipi_powerdown,

{

.csi = 0,

.ipu = 0,

.mclk_source = 0,

.is_mipi = 1,

},

  .ipu_id = 0,

.csi_id = 0,

.v_channel = 2,

.lanes = 2,

.dphy_clk = "mipi_pllref_clk",

.pixel_clk = "emi_clk",

in file mxc_mipi_csi2.c i edit :

          mipi_csi2_write(info, 0x00000034, CSI2_PHY_TST_CTRL1);//34 880mhz

Register DPHY is 0x330, ERR1 and ERR2 are 0x00. I found on internet, in this thread,Gao Jianzhong also has a same problem, he was solve that problem as below:

I have got this worked.

 

when  i set the AXI_CLK_ROOT clock to 528Mhz,(default 264Mhz),

 

2560x1440@30fps is worked fine.

 

So it seems that the "ccm_pixel_clk" is not enough in CSI2IPU moudle or MIPI core

I don't know how to change AXI_CLKC_ROOT clock to 528M. Is there any ideas to help me go on?

[Đinh Công Bằngd]

sorry for my english,thank you so much.

[Đinh Công Bằngd]

Sorry, v_chanel = 0.

  .ipu_id  = 0,

.csi_id = 0,

.v_channel = 0,

[Dave McMordie]

On Friday, March 7, 2014 2:36:44 AM UTC-5, Đinh Công Bằngd wrote:

sorry for my english,thank you so much.

Your English is a whole lot better than my tiếng Việ! But you can try me in French if you prefer (although we might have to keep in to English on the forum).

:)

Dave 

[Dave McMordie]

On Friday, March 7, 2014 2:34:43 AM UTC-5, Đinh Công Bằngd wrote:

Hi Mr Dave,

      My camera is connected to VC0, IPU0, CSI0, and I edited in kernel like at here https://github.com/mcmordie/linux/compare/johnweber:wandboard_imx_3.0.35_4.0.0...wandboard_imx_3.0.35_4.0.0, but preview is as attach file and i received a warring " IPU1_INT_STAT_5=0x00000001", my camera has clock 880MHZ, 2 lanes, and i had configure as below:

.mclk = 24000000,

.mclk_source = 0,

.csi = 0,

.io_init = mx6q_mipi_sensor_io_init,

.pwdn = mx6q_mipi_powerdown,

{

.csi = 0,

.ipu = 0,

.mclk_source = 0,

.is_mipi = 1,

},

  .ipu_id = 0,

.csi_id = 0,

.v_channel = 2,

.lanes = 2,

.dphy_clk = "mipi_pllref_clk",

.pixel_clk = "emi_clk",

IPU0 CSI0 is hard-mapped to virtual channel 0.  You need to set .v_channel to 0 and then check that your driver really is programming the sensor chip with this value, or at least that the sensor's default is virtual channel 0.

Critically, you also need to check that the mapping of the MIPI channel to the correct IPU/CSI is also set up in your board file.  There is a mux which must be set to allow the use of MIPI on ch 0.

For example, in my board file I have the following:

/* For MX6Q:

* GPR1 bit19 and bit20 meaning:

* Bit19:       0 - Enable mipi to IPU1 CSI0

*                      virtual channel is fixed to 0

*              1 - Enable parallel interface to IPU1 CSI0

* Bit20:       0 - Enable mipi to IPU2 CSI1

*                      virtual channel is fixed to 3

*              1 - Enable parallel interface to IPU2 CSI1

* IPU1 CSI1 directly connect to mipi csi2,

*      virtual channel is fixed to 1

* IPU2 CSI0 directly connect to mipi csi2,

*      virtual channel is fixed to 2

*

* For MX6DL:

* GPR13 bit 0-2 IPU_CSI0_MUX

*   000 MIPI_CSI0

*   100 IPU CSI0

*/

if (cpu_is_mx6q()) {

mxc_iomux_set_gpr_register(1, 19, 1, 1);

//mxc_iomux_set_gpr_register(1, 20, 1, 0);

}

You need different logic for different processor variants (eg. solo, dual lite).

 

in file mxc_mipi_csi2.c i edit :

          mipi_csi2_write(info, 0x00000034, CSI2_PHY_TST_CTRL1);//34 880mhz

Register DPHY is 0x330, ERR1 and ERR2 are 0x00. I found on internet, in this thread,Gao Jianzhong also has a same problem, he was solve that problem as below:

I have got this worked.

 

when  i set the AXI_CLK_ROOT clock to 528Mhz,(default 264Mhz),

 

2560...@30fps is worked fine.

 

So it seems that the "ccm_pixel_clk" is not enough in CSI2IPU moudle or MIPI core

I never understood this thread and never got anywhere worrying about it.  It might be important, but I think if you are getting garbled images, you might want to look more closely at this.

With the results you have from the MIPI registers, the problem is almost certainly just the MIPI->IPU/CSI channel routing.  Before looking at anything else, make sure you can get end-of-frame (EOF) interrupts.  For this you need:

1) Correct channel mapping as mentioned above

2) Correct frame size and data type programming on the sensor and in the V4L2 layer.  I would suggest telling your sensor to output 8 bit data to start since companding adds another level of confusion.

3) Correct capture path selection (you have to use CSI->MEM, not CSI->IC->MEM since Bayer is not supported in the image converted.

When you have those three things, you will get frames, and then it is just a question of whether they look right.

Best,

Dave

[Đinh Công Bằngd]

Thank you so much, I don't know French but you can learn vietnamese for easy commiunity, it is simply :D :D :D.

Continue with my issue.

1) Correct channel mapping as mentioned above

 V_channel is set value 0, i written wrong :).

2) Correct frame size and data type programming on the sensor and in the V4L2 layer.  I would suggest telling your sensor to output 8 bit data to start since companding adds another level of confusion.

In driver , function ov12830_probe()

ov12830_data.pix.pixelformat = V4L2_PIX_FMT_SBGGR10;

in function ov12830_init_mode:

if (ov12830_data.pix.pixelformat == V4L2_PIX_FMT_SBGGR10)
{
mipi_csi2_set_datatype(mipi_csi2_info, MIPI_DT_RAW10);
}
else
pr_err("currently this sensor format can not be supported!\n");

 ov12830 output Raw10 format.(10 bit)

3) Correct capture path selection (you have to use CSI->MEM, not CSI->IC->MEM since Bayer is not supported in the image converted.

 I had used CSI->MEM, I do same you in  https://github.com/mcmordie/linux/compare/johnweber:wandboard_imx_3.0.35_4.0.0...wandboard_imx_3.0.35_4.0.0 .

This is thread of Gao Jianzhong,  he also has a same problem. https://community.freescale.com/thread/306542