kernel 2.6.32

[Guest pier11]

OpenEve's qdsp5 compiles with our .32 with the following patch (it's commented out too in our huawei's trees):

--- /media/and/svn/openeve/trunk/arch/arm/mach-msm/qdsp5/adsp_videoenc_verify_cmd.c 	2011-12-17 08:49:13.320669658 -0500

+++ arch/arm/mach-msm/qdsp5/adsp_videoenc_verify_cmd.c  2012-01-12 14:50:48.000000000 -0500

@@ -115,10 +115,12 @@

            	if (cmd_size < sizeof(videnc_cmd_dis_cfg))

                    	return -1;

            	break;

+/*

    	case VIDENC_CMD_VENC_CLOCK:

            	if (cmd_size < sizeof(struct videnc_cmd_venc_clock))

                    	return -1;

            	break;

+*/

    	case VIDENC_CMD_CFG:

            	if (cmd_size < sizeof(videnc_cmd_cfg))

                    	return -1;

Edited January 12, 2012 by pier11

[Guest dr.flo]

from openeve 'system-gb-20110918-snapshot.zip'

strings libcamera.so | grep /dev

/dev/pmem_adsp

/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

/dev/msm_camera/msm_camera0

/dev/oncrpc



strings libmm-qcamera-tgt.so | grep /dev

/dev/pmem_adsp

do_mmap: Open device /dev/pmem_adsp failed!

/dev/msm_camera/msm_camera0

/dev/video20

v4l2_cam_frame: failed to open /dev/video20

/dev/fb0

/dev/LPMTASK

/dev/adsp/LPMTASK

But: no support for any of our camera sensors inside libmm-qcamera-tgt.so

Edited January 12, 2012 by dr.flo

[Guest pier11]

you are right - looks they use older camera libs with .32

Probably they have modified code for libcamera.so to use with gingerbread :)

but that shouldn't prevent us to try their qdsp5, especially when I've compiled it already. Can't try now - away from my dev env.

[Guest dr.flo]

Probably they have modified code for libcamera.so to use with gingerbread :)

Just tried their libcamera.so + our libmm-qcamera-tgt.so in CM7 with .29 kernel. Just crashes, as in any case where I tried to use our libmm-qcamera-tgt.so.

Taking their libmm-qcamera-tgt.so also didn't work. No crash but also no camera. To be expected if all of our sensors are unkown to the lib.

but that shouldn't prevent us to try their qdsp5, especially when I've compiled it already. Can't try now - away from my dev env.

Of course not! We should try anything we can. We will at least gain some more knowledge...

[Guest dr.flo]

But generally I think the idea of also looking at MSM7200A devices - instead of other huawei devices, is a good point.

My plan is to take this overview as a starting point, and do some google research to find out which of these devices have at least froyo.

From those froyo roms, I would grep the different libcameras if there is any combination that looks favourable to us...

[Guest pier11]

Just tried their libcamera.so + our libmm-qcamera-tgt.so in CM7 with .29 kernel. Just crashes, as in any case where I tried to use our libmm-qcamera-tgt.so.

May be if we compile libcamera.so from sources against our libmm-qcamera-tgt.so, it won't crash.

[Guest dr.flo]

May be if we compile libcamera.so from sources against our libmm-qcamera-tgt.so, it won't crash.

Are the sources to this libcamera.so available? They call it openEve / openEtna, but still they use proprietary libs...

A few days ago I tried this with a libcamera source from CM repo that referred a libmm-qcamera-tgt.so, still crashed.

Also from what I know, the libmm-qcamera-tgt / libqcamera / liboemcamera / whatever is never linked against libcamera. It is 'dlopen'ed.

[Guest pier11]

Compiled qdsp_7200A in our .32 tree.

Patch attached, if interested.

#ifdef CONFIG_MSM_7200A_ADSP - 9 of them -in headers are from our .29 tree.

As we turned off CONFIG_MSM_7200A_ADSP option when tried to "normalize" .29 tree - that might caused misconfiguration for our chip...Not sure though if that might affect absence of video...

qdsp_7200A.patch_for2.6.32.zip

[Guest pier11]

Are the sources to this libcamera.so available?

looks like:

https://github.com/O...froyo/libcamera

but I don't like comment to their latest commit: "Add source of libcamera, but disable for now"

[Guest pier11]

Compiled qdsp_7200A in our .32 tree.

Patch attached, if interested.

#ifdef CONFIG_MSM_7200A_ADSP - 9 of them -in headers are from our .29 tree.

As we turned off CONFIG_MSM_7200A_ADSP option when tried to "normalize" .29 tree - that might caused misconfiguration for our chip...Not sure though if that might affect absence of video...

Looks port of qdsp_7200A to .32 is not going to work. No sound. Video playback: pixelized, not playing - shows sort of first frame.

dmesg:

<6>[1973, mediaserver] [  338.792348] adsp: INIT_INFO failed

<3>[1973, mediaserver] [  338.792403] vfe_init failed at -16

logcat:

E/QualcommCameraHardware( 1119): interface_init: msm_camera opened failed!

$ ./adb shell ls -l /dev/msm_camera

crw-rw---- system   system   247,   5 2012-01-13 01:05 frame1

crw-rw---- system   system   247,   4 2012-01-13 01:05 config1

crw-rw---- system   system   247,   3 2012-01-13 01:05 control1

crw-rw---- system   system   247,   2 2012-01-13 01:05 frame0

crw-rw---- system   system   247,   1 2012-01-13 01:05 config0

crw-rw---- system   system   247,   0 2012-01-13 01:05 control0

[Guest pier11]

OpenEve's qdsp5 compiles with our .32 with the following patch (it's commented out too in our huawei's trees):

--- /media/and/svn/openeve/trunk/arch/arm/mach-msm/qdsp5/adsp_videoenc_verify_cmd.c 	2011-12-17 08:49:13.320669658 -0500

+++ arch/arm/mach-msm/qdsp5/adsp_videoenc_verify_cmd.c  2012-01-12 14:50:48.000000000 -0500

@@ -115,10 +115,12 @@

            	if (cmd_size < sizeof(videnc_cmd_dis_cfg))

                    	return -1;

            	break;

+/*

    	case VIDENC_CMD_VENC_CLOCK:

            	if (cmd_size < sizeof(struct videnc_cmd_venc_clock))

                    	return -1;

            	break;

+*/

    	case VIDENC_CMD_CFG:

            	if (cmd_size < sizeof(videnc_cmd_cfg))

                    	return -1;

This experiment is more successful, but doesn't give much new.

Frozen wrong colors in viewfinder, as we had already.

And white noise instead of sound, but proper duration of it.

[Guest pier11]

Interesting, that stock UK Pulse Eclair rom holds inside libqcamera.so ...

$ ls -l libqcamera.so 

-rw-r--r-- 1 eclipse eclipse 586616 2012-01-12 22:46 libqcamera.so

[Guest dr.flo]

and it also has libmmprocess.so, which is loaded by libqcamera.so - both of these libs are not copied when extracting binaries for CM - I guess this is why we never noticed them before. Also, they're just lying around in system/lib without being used.

Plugging these into our current best setup results in the familiar freezing preview. So nothing gained. But up to now, this is the 3rd known version of a libqcamera.so binary that gives some reply from the sensor (the others I know of are ascend-cm7 and u8150-froyo).

As far as I remember, although we did test several libqcamera.so, the libcamera.so was always the same (as in ascend and u8150, this binary is identical).

I think I should start a list with tested libcamera combinations, before this gets too confusing...

[Guest dr.flo]

pier, another thought:

As you are now an expert in kernel porting to the u8220....

What do you estimate - with your knowledge in mind, how much effort would it be to port pulse-mini .29 kernel to u8220?

I mean just the minimal adjustments needed to get this to boot up the u8110 eclair rom you composed. In that way we should have a setup that results in the closest possible match to the u8110 rom.

In the end, this kernel would be useless since we already have a .29 kernel.

But for the camera, there are two possible scenarios:

- camera would work in eclair u8110 rom -> conclusion: the fact that it doesn't work in our current best setup is a kernel .32 (porting) issue

- camara would not work in eclair rom -> conclusion: cam doesn't work because of hardware/qdsp5 related issues resulting from MSM7200a vs other variants

Edited January 13, 2012 by dr.flo

[Guest hzf]

just a question, maybe I am wrong(again), why don't you try to port the U82x0 Eclair .29 kernel to .32?

[Guest dr.flo]

just a question, maybe I am wrong(again), why don't you try to port the U82x0 Eclair .29 kernel to .32?

Regarding the camera problem, this would be of no use. Camara does not work in gingerbread because the user space libraries (libcamera and friends) we have for the pulse are not compatible with gingerbread. They are also not compatible with .32 kernel. Now if we make .32 kernel compatible to our libs, we could run eclair with camera and kernel .32, but I don't think there is any demand for that.

[Guest pier11]

pier, another thought:

As you are now an expert in kernel porting to the u8220....

What do you estimate - with your knowledge in mind, how much effort would it be to port pulse-mini .29 kernel to u8220?

I mean just the minimal adjustments needed to get this to boot up the u8110 eclair rom you composed. In that way we should have a setup that results in the closest possible match to the u8110 rom.

In the end, this kernel would be useless since we already have a .29 kernel.

But for the camera, there are two possible scenarios:

- camera would work in eclair u8110 rom -> conclusion: the fact that it doesn't work in our current best setup is a kernel .32 (porting) issue

- camara would not work in eclair rom -> conclusion: cam doesn't work because of hardware/qdsp5 related issues resulting from MSM7200a vs other variants

I agree that would be an interesting experiment. No, rather a project.

It took me two months of non stop work to achieve .32 port. On the other hand it was my first kernel port project. Obviously I know a bit more now.

I'd say 3 week would be a reasonable estimate... to possibly have

- running kernel

- ported board (with just needed to this experiment devices support)

- ported minimal needed devices: display, touchscreen, keypad, usb/adb, sound (dsp), cameras.

The price is very high for this experiment...

[Guest pier11]

I think we have not yet fully explored and compared tracing from working system vs partially working.

This should give us full logs related to cameras.

[Guest dr.flo]

I think we have not yet fully explored and compared tracing from working system vs partially working.

This should give us full logs related to cameras.

I agree on this. Maybe we both should do it, because of the different camera sensors we have.

[Guest pier11]

Couple more thoughts:

1. Newer camera code exposes extra device - v4l

/dev/video20

libqcamera.so uses it - sends ioctl at least.

The new msm_v4l2.c (it was not compiled in for .29 kernel) operates color spaces - like YUV - don't like that - might cause our color issues...

2. It makes sense probably to experimentally expose older interface (7x0x/msm_camera.c & co.) out of .32, test with older libs to see of video flows correctly from camera to framebuffer in that kernel.

If it does, than issue could be narrowed down to content of 7x0x, absence of v4l and new user space camera libs.

Edited January 13, 2012 by pier11

[Guest pier11]

Looks like Dream/Sapphire (msm7200A) in their 2.6.34 kernel use newer camera API and libqcamera.so... (So it can work in theory)

Especially liked their options :)

CONFIG_MSM_CAMERA_OLD

CONFIG_MSM_CAMERA_V4L2

their libqcamera in CM5 (which has 2.6.34 kernel) supports only two cameras:

mt9t013

s5k3e2fx

"This patch adds camera support for the older DSP found on Dream and Sapphire devices."

But camera interface it exposes is new.

Actually Magics (aka Sapphire) got official Froyo - FRG83D.

Edited January 14, 2012 by pier11

[Guest dr.flo]

"This patch adds camera support for the older DSP found on Dream and Sapphire devices."

But camera interface it exposes is new.

Now this really looks promising... we should integrate this patch into kernel .32, it might work with u8150-froyo camera libs then. Hopefully... A sad thing that dream/saphires libqcamera.so doesn't support our sensors. But still, as we believe the problem is independent of sensor type, the patch may fix the problem for us as well.

[Guest pier11]

Now this really looks promising... we should integrate this patch into kernel .32, it might work with u8150-froyo camera libs then. Hopefully... A sad thing that dream/saphires libqcamera.so doesn't support our sensors. But still, as we believe the problem is independent of sensor type, the patch may fix the problem for us as well.

Their libs looks interface differently with kernel though. They don't use v4l device at all - /dev/video20, while our froyo libs do. That's why they eliminated v4l easily.

Them:

$ strings libqcamera_cm-5.0.8-DS.so | grep dev | sort

/dev/adsp/JPEGTASK

/dev/adsp/LPMTASK

/dev/JPEGTASK

/dev/LPMTASK

/dev/msm_camera/config0

/dev/msm_camera/frame0

/dev/pmem_adsp

/dev/pmem_camera

Us:

$ strings UKPulse_Android21_2010/system/lib/libqcamera.so | grep dev | sort

/dev/graphics/fb0

/dev/msm_camera/config

/dev/msm_camera/control0

/dev/msm_camera/frame

/dev/pmem_adsp

/dev/video20

Looks like their froyo libs have more similarity with

our older libs:

$ strings UKPulse_Android21_2010/system/lib/libmm-qcamera-tgt.so | grep dev | sort

/dev/adsp/LPMTASK

/dev/LPMTASK

/dev/msm_camera/msm_camera

/dev/pmem_adsp

Edited January 14, 2012 by pier11

[Guest dr.flo]

2. It makes sense probably to experimentally expose older interface (7x0x/msm_camera.c & co.) out of .32, test with older libs to see of video flows correctly from camera to framebuffer in that kernel.

If it does, than issue could be narrowed down to content of 7x0x, absence of v4l and new user space camera libs.

I tried to try this, but when implanting the 7x0x files into .32 kernel, it fails to compile msm_v4l2.c, still have to search for the config option to turn it off... will need to have a closer look at the patch you mentioned

Edited January 14, 2012 by dr.flo

[Guest pier11]

1326571902' post=1884929']

I tried to try this, but when implanting the 7x0x files into .32 kernel, it won't compile msm_v4l2.c, still have to search for the config option to turn it off... will need to have a closer look at the patch you mentioned

If building older interface - 7x0x - msm_v4l2.c should not participate. See .29 media/video/msm/Makefile

Edited January 14, 2012 by pier11