Jump to content

kernel 2.6.32


Guest pier11

Recommended Posts

Guest jgilalonso

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

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

Guest dr.flo

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

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

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!

Link to post
Share on other sites

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.

Link to post
Share on other sites
Guest pier11

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

Link to post
Share on other sites
Guest pier11

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.

Link to post
Share on other sites
Guest dr.flo

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

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

Link to post
Share on other sites
Guest dr.flo

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.

Link to post
Share on other sites
Guest dr.flo

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

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

Link to post
Share on other sites
Guest pier11

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)

Link to post
Share on other sites
Guest dr.flo

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

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

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

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

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

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