kernel 2.6.32

January 5, 2012

see the second post of this thread for what is working. Was tested with CM7.1rc1

Incredible!!!!! You're a genius!!!

Only a questions:

- What is not working?

- What about performance, native tethering and openGL 2.0?

- If CM7 is based on gingerbread, which is the difference between a kernel 2.6.32 (froyo) and 2.6.35 (ginger)?

Can you upload a new ROM CM7.1 with your new kernel?

Thanks a lot!!! I love my Pulse!!!!

January 5, 2012

And, for anyone who is interested:

here is this kernel combined with dtox125 CM7.1 rom and ascend libcamera.so. You must have signature checking turned off in CWM to install this (files were exchanged in zip file).

NOTE: the camera is NOT WORKING. Just install this if you want to see how this...

With regard to camera I'm also getting simi-positive results. If on CM6 camera did't even try to start, on froyo stock rom I'm getting:
- image with very weird inverted colors;
- image freezes soon after. So I can't make a picture.

...looks like on CM7.1

BIG NOTE: this is just for people who want to experiment. I'm not able to support this in case of problems, I just copy-pasted some files from one ROM to another!

Edited January 5, 2012 by dr.flo

January 5, 2012

And, for anyone who is interested:

here is this kernel combined with dtox125 CM7.1 rom and ascend libcamera.so. You must have signature checking turned off in CWM to install this (files were exchanged in zip file).

So I just wanted to test this thing and I must say for no overclocked cm7 looks great. It's way more responsive than the cm7 on .29 (I know it's not just me, cause I could actually go to the settings and performance settings without lagging).

I loved it, but I will go back to cm6 for a while.

+ the boot screen creeped me out at the beginning, but I love it, especially Tux!

Edited January 5, 2012 by D-D-

January 5, 2012

So I just wanted to test this thing and I must say for no overclocked cm7 looks great. It's way more responsive than the cm7 on .29 (I know it's not just me, cause I could actually go to the settings and performance settings without lagging).
I loved it, but I will go back to cm6 for a while.

+ the boot screen creeped me out at the beginning, but I love it, especially Tux!

Console with Tux there was for development, I removed it in source tree already :)

Thanks for testing!

January 5, 2012

Console with Tux there was for development, I removed it in source tree already :)

Thanks for testing!

Noo, get it back!

You're welcome.

Anyway, I don't know if it's rom or kernel thing, but it wouldn't indicate battery percentage and wouldn't turn on wifi.

And I would guess that since it's still in dev, there is no OC on this kernel.

Everything else worked great.

January 5, 2012

No overclock so far. Not a priority in the moment.

For wifi to work, a new kernel model is needed to be used (the previous one from .29 is not compatible). I've compiled from source the new one.

Battery percentage is sort of side effect appeared after I added sound :) But in my recent compilations it looks like started to work again... (But anyway you should have percentage present in Settings->About...)

January 5, 2012

Good introductory reading on Camera architecture on MSM platform:

RFC: V4L2 driver for Qualcomm MSM camera

January 5, 2012

OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then:

1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.)

2. For the same devices it has changed between Froyo and Gingerbread.

3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake.

I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel.

January 5, 2012

OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then:

1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.)
2. For the same devices it has changed between Froyo and Gingerbread.
3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake.

I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel.

Interesting.... Lets think about what this means

1. we would like u8150 libcamera.so to work on the pulse because it is a native froyo binary (and therefore also could be used in CM7 gingerbread)

2. therefore we need (and now have) a kernel which exposes an API that matches 1.

3. our camera hardware works with .29 kernel drivers

4. both APIs are "slightly" different

Right? Now possibly the most elegant solution would be to modify the kernels camera driver in a way that the API stays like it is in our kernel port now, and in the inside it should talk to the camera like .29 did.

I did not look too closely at both API versions yet, but my first impression is that the differences are possibly not too large. Some parameters added, enums instead of defines, ...

I think It might be possible to modify .29 drivers in such a way that they expose the same API as the MSM7225

What do you think?

EDIT: what makes you think "2. For the same devices it has changed between Froyo and Gingerbread."? I believe this is not the case. As far as I know, Froyo binaries work in gingerbread with only a very minimalistic wrapper that basicly renames one or two functions. The interface kernel <-> user should not be affected

Edited January 5, 2012 by dr.flo

January 5, 2012

What do you think?

I conceptually support it :)

Interestingly, the camera drivers themselves are nearly identical in .29 and .32, but "something in between" implemented differently.

That something in between is:

msm_camera.c

msm_vfe7x

flash

For .29 those were taken from somewhere else(.27?) and placed to separate folder drivers/media/video/msm/7x0x instead of using ones from original source tree.

EDIT: what makes you think "2. For the same devices it has changed between Froyo and Gingerbread."?

comparing include/media/msm_camera.h in .32 tree to one in .35 source tree

January 5, 2012

For .29 those were taken from somewhere else(.27?) and placed to separate folder drivers/media/video/msm/7x0x instead of using ones from original source tree.

Maybe they needed a quick workaround because they got a "picture with very weird colors" when using the original source tree? Just kidding...

This is the key I think...

comparing include/media/msm_camera.h in .32 tree to one in .35 source tree

ah, ok I understand. But nevertheless Ascend and u8150 all have identical libcamera.so in both their stock froyo versions and both their CM7 versions where camera is said to be working. Their CM7 maybe runs on .32 kernel? But I think this doesn't need to bother us.

January 6, 2012

interesting reading on how camera stuff works:

CameraVFE

And more on parts of camera ecosystem

Edited January 6, 2012 by pier11

January 6, 2012

pulse .29


struct msm_ctrl_cmd_t {

int timeout_ms;

uint16_t type;

uint16_t length;

void *value;

uint16_t status;

};

u8150 .32


struct msm_ctrl_cmd {

uint16_t type;

uint16_t length;

void *value;

uint16_t status;

uint32_t timeout_ms;

int resp_fd; /* FIXME: to be used by the kernel, pass-through for now */

};

Note the different position of the type/length element. Any libcamera compiled with one version of the header is definately unable to communicate with the camera driver compiled with the other version of the header...

Can you provide some step by step instructions on what to do in order to compile your kernel from the repo?Maybe using this as a starting point?

Edited January 6, 2012 by dr.flo

January 6, 2012

Can you provide some step by step instructions on what to do in order to compile your kernel from the repo? Maybe using this as a starting point?

Here they are:

Building and packing the kernel into a flashable boot.img

Tested all the steps in the instruction up until to phone works with the newly compiled kernel. Works.

Edited January 6, 2012 by pier11

January 6, 2012

Ok now test

January 6, 2012

Insertion cyanogenmod-plus-pulse-v0.9.1 and power consumption at height. cm7 sits down the battery in 2 times faster than cm6 who can will look cm6 why on it the battery is discharged not so quickly http://narod.ru/disk/32747712001/mod-2.2.1.rar.html

Edited January 6, 2012 by skykilla

January 6, 2012

OK, if include/media/msm_camera.h is API between propriatory MSM part in user space (libqcamera.so?? aka liboemcamera.so) and kernel, then:

1. API has not changed between Eclair and Froyo for MSM7225-based devices (like u8150 Comet/Ideos, u8110 pulse-Mini, etc.)
2. For the same devices it has changed between Froyo and Gingerbread.
3. Our API on Eclair is different to MSM7225's Eclairs above, and rather similar to pulse's Cupcake.

I compiled .32 kernel with MSM7225 version of API. That's why u8150 camera libs work there, but not the pulse's libs from .29 kernel.

libcamera/QualcommCameraHardware.cpp:

#include <media/msm_camera.h>

As thought, media/msm_camera.h defines interaction format between kernel and user space...

January 6, 2012

To test the rom and the sort of link to download the kernel.

currently employed and the touch screen?

Edited January 6, 2012 by romea

January 7, 2012

From what I gathered,

1. libcamera.so provides higher level user space API. (It also talks to proprietary libqcamera.so).

2. libcamera.so (QualcommCameraHardware.cpp) via ioctl talks to kernel. Receiving part is msm_camera.c in kernel. Interface is include/media/msm_camera.h

3. Communication with kernel goes via the following devices created by msm_camera.c via ioctl:

/dev/msm_camera/config0

/dev/msm_camera/config1

/dev/msm_camera/control0

/dev/msm_camera/control1

/dev/msm_camera/frame0

/dev/msm_camera/frame1

(As we have two cameras)

January 7, 2012

interesting findings...

Have you ever looked at u8220's libcamera.so with a hex editor?

It has the following string inside

"hardware/msm7k/libcamera/7x0x/QualcommCameraHardware.cpp"

So I strongly believe that the pulse uses a modified piece of code not only inside the kernel drivers, but also inside libcamera; must be, because of the different api.

Also from what I have read, libqcamera (in the pulse's case libmmcamera + libmm-qcamera-tgt) contains the majority of hardware dependend functions, so I guess we can't just patch the kernel drivers to act like in .29 kernel (as I proposed before).

Is this (libmmcamera + libmm-qcamera-tgt) part of older android versions (donut?). Then maybe the 7x0x subtree is a copy of donut's version. Are there sources of QualcommCameraHardware.cpp available for any donut device? This seems to be a version of libcamera source code that connects to old proprietary libmmcamera, but it is built for gingerbread...

Maybe some combination of .29 kernel drivers + original libmmcamera / libmm-qcamera-tgt + recompiled libcamera would be feasible?

edit: and thank you for the perfect instructions on building the kernel!

Edited January 7, 2012 by dr.flo

January 7, 2012

Pulse never experienced Donut (1.6), but had Cupcake (1.5).

You probably know about Code Aurora project - open source from our chipset maker - Qualcomm. That is where Huawei's kernels ware derived from. (Huawei didn't change kernels significantly. Whereas Code Aurora departs quite significantly from AOSP - Android Open Source Project - Google's original version)

So Code Aurora has libcamera for Cupcake (1.5) referencing our libs:

libmmcamera = ::dlopen("libmmcamera.so", RTLD_NOW);

libmmcamera_target = ::dlopen("libmm-qcamera-tgt.so", RTLD_NOW);

AOSP's Cupcake references libqcamera instead:

libqcamera = ::dlopen("libqcamera.so", RTLD_NOW);

By comparing camera API it seemed to me that .29 version had more similarities to what was in .27 kernel (Cupcake) in Pulse. (Maybe they didn't want to license/pay for the new version of proprietary Qualcomm's libmm-qcamera-tgt.so & Co. - who knows)

On the other hand .32 kernel holds camera drivers for our camera sensors; and that same sensors I think present on "true" .32 devices (ascend? pulse-mini?) So that makes me want use normal .32 interfaces/libs (and it kind of worked in half already), not to look backwards.

Edited January 7, 2012 by pier11

January 7, 2012

Further to differences between pulse-29 layer interactions and .32

Froyo (2.2) rom u8150

Expected devices:

...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libcamera.so | grep /dev

/dev/pmem_adsp

/dev/graphics/fb0

/dev/graphics/fb0 opened failed!

/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

/dev/msm_camera/control

/dev/msm_camera/config


...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep /dev

/dev/video20

/dev/graphics/fb0

/dev/msm_camera/frame

/dev/msm_camera/control0

/dev/msm_camera/config

/dev/pmem_adsp

.32 kernel Available devices:

sh-3.2# ls -l /dev/msm_camera/

crw-rw----	1 1000 	1000  	246,   1 Jan  6 14:33 config0

crw-rw----	1 1000 	1000  	246,   4 Jan  6 14:33 config1

crw-rw----	1 1000 	1000  	246,   0 Jan  6 14:33 control0

crw-rw----	1 1000 	1000  	246,   3 Jan  6 14:33 control1

crw-rw----	1 1000 	1000  	246,   2 Jan  6 14:33 frame0

crw-rw----	1 1000 	1000  	246,   5 Jan  6 14:33 frame1


sh-3.2# ls -l /dev/video20 

crw-------	1 0    	0      	81,   0 Jan  6 14:33 /dev/video20


sh-3.2# ls -l /dev/graphics/fb0 

crw-rw----	1 0    	1003   	29,   0 Jan  6 14:33 /dev/graphics/fb0


sh-3.2# ls -l /dev/pmem_adsp 

crw-rw----	1 1000 	1005   	10,   1 Jan  6 14:33 /dev/pmem_adsp

Eclair (2.1) stock Pulse rom: Expected devices:

...Stock2.1/system/lib$ strings libcamera.so | grep /dev

/dev/pmem_adsp

/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

/dev/msm_camera/msm_camera

/dev/oncrpc


...Stock2.1/system/lib$ strings libmmcamera.so | grep /dev

/dev/video20

/dev/fb0

/dev/msm_camera/msm_camera

/dev/pmem_adsp


...Stock2.1/system/lib$ strings libmm-qcamera-tgt.so | grep /dev

/dev/pmem_adsp

/dev/msm_camera/msm_camera

/dev/LPMTASK

/dev/adsp/LPMTASK

.29 Pulse kernel Available devices:

sh-3.2# ls -l /dev/msm_camera/      	

crw-rw----	1 1000 	1000  	246,   0 Jan  7 18:01 msm_camera0

crw-rw----	1 1000 	1000  	246,   1 Jan  7 18:01 msm_camera1


sh-3.2# ls -l /dev/pmem_adsp 

crw-rw----	1 1000 	1005   	10,   1 Jan  7 18:01 /dev/pmem_adsp


sh-3.2# ls -l /dev/adsp/LPMTASK 

crw-rw----	1 1000 	1005  	250,   6 Jan  7 18:01 /dev/adsp/LPMTASK

Notice mismatch of devices on 29-pulse vs 32 on the following node

/dev/msm_camera/

When I tried to use our CM6 atop of .32 kernel no wonder I got:

interface_init: msm_camera opened failed!

If Huawei didn't use /7x0x folder, the API on .29 would be the same as on .32 systems.

Edited January 7, 2012 by pier11

January 7, 2012

On the other hand .32 kernel holds camera drivers for our camera sensors; and that same sensors I think present on "true" .32 devices (ascend? pulse-mini?) So that makes me want use normal .32 interfaces/libs (and it kind of worked in half already), not to look backwards.

You're right. Did you ever try out the patched CM7 I uploaded? Just to see if the camera behaviour there is really the same as in u8150 froyo?

Now what should be done next? Do the logs give any hints about why the preview freezes?

What I don't understand is why this happens if we really have the same HW as in those devices where the binaries are from. Shouldn't it just work then?

btw, have you ever tried this phone info? Mine says I have a mt9t013_byd

January 7, 2012

have you ever tried this phone info? Mine says I have a mt9t013_byd

I've read that thread. I know mt9t013_byd is one of two variations of main sensors on our boards. Mine is ov3647.

I didn't try patched cm7, but from your description it behaves similar to what I observed...

On the other note, that libcamera source from motorola cliq xt, gibgerbread, - it might be what is needed to glue .29 infrastructure to cm7 (gingerbread). Try to compile it with cm7 :-)

looks they use .29 kernel with gingerbread as we did initially.

Edited January 7, 2012 by pier11

January 8, 2012

Rather good news for idea of using froyo camera ecosystem. Looks like proprietary u8150's libqcamera.so has support for our cameras:

...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep ov3

ov3647_process_start

ov3647


...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep ov7

ov7690_process_start

ov7690_format

ov7690


...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep mt9

mt9t013_liteon_process_start

mt9t013_byd_process_start

mt9d113_process_start

mt9d112_process_start

mt9p012_register_to_real_gain

mt9p012_process_start

mt9p012_set_lens_shading_correction

mt9p012_km_register_to_real_gain

mt9p012_km_process_start

mt9p012_km_set_lens_shading_correction

mt9t013_process_start

mt9t013_reg_pat

mt9d113_format

mt9t013_liteon

mt9t013_byd

mt9d113

mt9p012 failed %d

This is used on u8120

...1MULTI-TOUCH_STOCK_ROM__u8150/system/lib$ strings libqcamera.so | grep s5k

s5k5ca_process_start

s5k5ca_format

s5k3e2fx_process_start

s5k5ca

And thought that libqcamera has tons of hardware specific stuff looks right.

Edited January 8, 2012 by pier11

kernel 2.6.32

Recommended Posts

Guest jgilalonso

Link to comment

Share on other sites

Popular Days

Popular Days

Popular Posts

Guest pier11

Guest pier11

Guest pier11

Posted Images

Guest dr.flo

Link to comment

Share on other sites

Guest D-D-

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest D-D-

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pilmenb

Link to comment

Share on other sites

Guest skykilla

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest romea

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest pier11

Link to comment

Share on other sites

Guest dr.flo

Link to comment

Share on other sites

Guest pier11

Link to comment