Jump to content

kernel 2.6.32


Guest pier11

Recommended Posts

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 by pier11
Link to post
Share on other sites
  • Replies 488
  • Created
  • Last Reply

Popular Posts

Sound/Mic work now. Plays mp3, does google voice search, heard remote answering machine via normal phone call. Plugged qdsp5 from current kernel. Seems to be working OK. 2.6.27 kernel also used s

Ported backlight stuff - driver, related board config, huawei's framebuffer patch. Now brightness changes, also display turns back light completely off when inactive. The device with wifi/3g but

WiFi works now. Compiled ar6000 wifi driver from sources on Huawei site. Also mobile data network works.

Posted Images

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 by dr.flo
Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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...

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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 by dr.flo
Link to post
Share on other sites

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.

Link to post
Share on other sites

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...

Link to post
Share on other sites

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 by pier11
Link to post
Share on other sites

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 by pier11
Link to post
Share on other sites

"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.

Link to post
Share on other sites

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 by pier11
Link to post
Share on other sites

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 by dr.flo
Link to post
Share on other sites
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 by pier11
Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.