Guest pier11 Posted January 12, 2012 Report Share Posted January 12, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 12, 2012 Report Share Posted January 12, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest pier11 Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest dr.flo Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest dr.flo Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest dr.flo Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 12, 2012 Report Share Posted January 12, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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" Link to comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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 Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 13, 2012 Report Share Posted January 13, 2012 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 comment Share on other sites More sharing options...
Guest dr.flo Posted January 13, 2012 Report Share Posted January 13, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest hzf Posted January 13, 2012 Report Share Posted January 13, 2012 just a question, maybe I am wrong(again), why don't you try to port the U82x0 Eclair .29 kernel to .32? Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 13, 2012 Report Share Posted January 13, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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 comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 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. Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 13, 2012 Report Share Posted January 13, 2012 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. Link to comment Share on other sites More sharing options...
Guest pier11 Posted January 13, 2012 Report Share Posted January 13, 2012 (edited) Couple more thoughts: 1. Newer camera code exposes extra device - v4l /dev/video20libqcamera.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 Link to comment Share on other sites More sharing options...
Guest pier11 Posted January 14, 2012 Report Share Posted January 14, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 14, 2012 Report Share Posted January 14, 2012 "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 comment Share on other sites More sharing options...
Guest pier11 Posted January 14, 2012 Report Share Posted January 14, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest dr.flo Posted January 14, 2012 Report Share Posted January 14, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Guest pier11 Posted January 14, 2012 Report Share Posted January 14, 2012 (edited) 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 Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now