Jump to content

kernel 2.6.32


Guest pier11

Recommended Posts

Result: Doesn't crash anymore; instead says it cannot connect to camera. No preview, nothing.. ???

Does sound work with that dsp?

You would need .29 libs from ascend (or any msm7225 based device like pulseMini) as kernel now exposes /dev/msm_camera/config0 instead of /dev/msm_camera/msm_camera0. libcamera.so should know that.

Use:

strings libcamera.so | grep /dev

to see what's hardcoded inside.

Result: Playback of Video (recorded with eclair 2.1) works without issues in CM7 + kernel .32

Thanks for tests. Good to know.

I've compiled vfe, will see soon if it runs.

Link to comment
Share on other sites

Does sound work with that dsp?

You would need .29 libs from ascend (or any msm7225 based device like pulseMini) as kernel now exposes /dev/msm_camera/config0 instead of /dev/msm_camera/msm_camera0. libcamera.so should know that.

Use:

strings libcamera.so | grep /dev
to see what's hardcoded inside.
Checked libqcamera.so from pulseMINI u8110 Eclair (2.6.29). It supports basically same range of cameras as Froyo version on u8150:
  • himax0356
  • mt9d112
  • mt9d113
  • mt9p012_km
  • mt9p012
  • mt9t013_byd
  • mt9t013_liteon
  • mt9t013
  • ov3647
  • ov7690
  • s5k3e2fx
  • s5k5ca
  • vb6801
It also expect camera devices on the same place as .32 Froyo version:
$ strings libcamera.so | grep /dev

/dev/pmem_adsp

/dev/graphics/fb0

/dev/msm_camera/control

/dev/msm_camera/config

As I noted earlier for that devices API - media/msm_camera.h - did not change in transition from .29 to .32

So for purity we could continue to try to "normalize" camera internals in pulse's .29 kernel - to get rid of 7x0x and qdsp5_7200A - and use pulseMINI's user space camera libs.

Thus possible issues of porting process of .32 kernel from u8150 would not interfere to results...

Link to comment
Share on other sites

Does sound work with that dsp?

You would need .29 libs from ascend (or any msm7225 based device like pulseMini) as kernel now exposes /dev/msm_camera/config0 instead of /dev/msm_camera/msm_camera0. libcamera.so should know that.

Use:

strings libcamera.so | grep /dev

to see what's hardcoded inside.

Sorry I didn't test sound. Don't remember. But I did use ascend camera libs. Thats what makes me wonder. I would have expected that the driver could at least have opened the camera device. Maybe I broke something by trying to revert dsp code.

edit: another thing could possibly be that the driver really wants "/config" and not "/config0" because the libs were written for devices that only have one camera. Maybe in that case the kernel would create the device names without indices? I'll lookup this in the kernel source....

So for purity we could continue to try to "normalize" camera internals in pulse's .29 kernel - to get rid of 7x0x and qdsp5_7200A - and use pulseMINI's user space camera libs.

Thus possible issues of porting process of .32 kernel from u8150 would not interfere to results...

Good idea. So my plan for tonight is the following

- take pulses original kernel directly from huawei (compiling this should result in exactly the stock kernel?)

- only revert 7x0x and qdsp5_7200A

- combine this zImage with stock eclair ramdisk

- exchange user space camera libs from pulse to pulse mini (and/or ascend eclair)

That's what you meant, isn't it?

Somehow I have a feeling that this will not result in a working camera. It should, normally. But somehow I don't expect it...

But this time I will also check if sound is working.

Edited by dr.flo
Link to comment
Share on other sites

Good idea. So my plan for tonight is the following - take pulses original kernel directly from huawei (compiling this should result in exactly the stock kernel?) - only revert 7x0x and qdsp5_7200A - combine this zImage with stock eclair ramdisk - exchange user space camera libs from pulse to pulse mini (and/or ascend eclair) That's what you meant, isn't it?
Exactly correct :)

Were ascend libs in your experiment from Eclair or Froyo?

Edited by pier11
Link to comment
Share on other sites

Were ascend libs in your experiment from Eclair or Froyo?

They were from CM7-Ascend (so essentially from Froyo) because I tested the modified .29 kernel from within CM7

(therefore there might have been other issues, so I think the experiment for tonight will be a much cleaner approach)

Link to comment
Share on other sites

They were from CM7-Ascend (so essentially from Froyo) because I tested the modified .29 kernel from within CM7

(therefore there might have been other issues, so I think the experiment for tonight will be a much cleaner approach)

yes, my idea was to use the libs from stock pulseMINI ECLAIR (2.6.29 kernel). So they would be a perfect match for .29 kernel.

There is kernel source for mini - u8110. So in case of failure, pulse's "normal" camera code can be verified against qdsp5 and /media/video/msm* in mini source. (There is .29 kernel source for ascend too).

Link to comment
Share on other sites

pier could you please give me a link to that stock pulse mini rom you got the libs from? Doing a quick search I only found 'dload' versions, I don't know how to unpack them...

Link to comment
Share on other sites

pier could you please give me a link to that stock pulse mini rom you got the libs from? Doing a quick search I only found 'dload' versions, I don't know how to unpack them...

I took from dload from UK official version from their forum on this modaco site -U8110V100R001C85B214SP05

It's Eclair 2.1

There are two scripts:

- split_updata.pl (to split). You probably don't need crc util. It will do the job without it.

- unyaffs (to see what's inside individual partitions)

Edited by pier11
Link to comment
Share on other sites

Guest pilmenb

Good day! Dear pier11 and dr.flo! Is there a working version of firmware or a backup copy on a 32 core with the latest changes and want potestit posmotert firmware as a show with an optimized kernel.

If you please lay out would be very thankful!

Link to comment
Share on other sites

ok, I've composed stock u8110 pulse mini rom, in the same fashion I did for u8150:

- removed some app/media to fit into 100MB system partition,

- used stock ramdisk with very minor mods,

- used pulse's (not mini) .29 kernel, excluded 7x0x and qdsp5_7200A folders from compilation.

Here is the resulting u8110 rom if interested.

The rom actually exposes the same issues as u8150 - no ril, wifi, sound. So maybe easier to figure out it's radio issues here and apply findings to u8150 with .32 kernel. As this rom is closest possible match to our stock eclair.

As for cameras, even though devices appear:

ls -l /dev/msm_camera/*

crw-rw---- system   system   246,   1 2012-01-12 04:38 config0

crw-rw---- system   system   246,   4 2012-01-12 04:38 config1

crw-rw---- system   system   246,   0 2012-01-12 04:38 control0

crw-rw---- system   system   246,   3 2012-01-12 04:38 control1

crw-rw---- system   system   246,   2 2012-01-12 04:38 frame0

crw-rw---- system   system   246,   5 2012-01-12 04:38 frame1
it still can't connect to them:
E/QualcommCameraHardware( 1103): interface_init: msm_camera opened failed!

dmesg have this:

<3>[342, kadspd] [ 94.584996] [adsp:adsp.c:handle_adsp_rtos_mtoa] unknowned proc 2

<6>[1818, Binder Thread #] [ 99.580531] [adsp:adsp.c:msm_adsp_get] INIT_INFO failed

<3>[1818, Binder Thread #] [ 99.580586] vfe_init failed at -16

Edited by pier11
Link to comment
Share on other sites

Maybe we're getting closer, little by little...

It seems to me that the qdsp5 thing needs some more investigation.

I found that when I just revert qdsp5_7200A from pulses original kernel to qdsp5 and boot that into my stock 2.1 pulse rom,

- sound output doesn't work (nothing, not even noise)

- (but) previously recorded video plays back fine

- camera doesn't open:

interface_init: msm_camera opened failed!

My conclusion: Even if correct camera devices are present (in case of my experiment with stock pulse libcamera, msm_camera0, msm_camera1), but qdsp and camera libs mismatch -> camera doesn't open at all.

Also, remember recently I tried a similar experiment (AntonioPT kernel .29 with both camera and qdsp reverted) under CM7 with the camera libs that give freezing preview with your kernel -> camera doesn't open at all, likely in the same way as it didn't open in my experiment above, and in the same way as in your pulse mini experiment.

Sound output works in CM7 with kernel .32 -> so kernel .32 qdsp5 is more functional than kernel .29 reverted qdsp5. Therefore the camera gets further.

Could you please try

- kernel .32 zImage

- everything else (ramdisk, rom) from your pulse mini experiment above?

I would expect the camera to open and show a freezing preview!

EDIT: tried this myself.

Results are somewhat surprising

- Camera app opens but does not give any preview.

- Sound works!

- Playback of video doesnt work (-> therefore also no preview in camera)

Another thing:

- used pulse's (not mini) .29 kernel, excluded 7x0x and qdsp5_7200A folders from compilation.

How exactly did you do this? In my experiments of this kind, I disabled qdsp5_7200A by means of the config file, but to revert 7x0x I manually edited some files, because removing the 7201A_SURF (or similar) define in config broke the compilation of the kernel.

I think for us to be able to compare the results of such experiments, we should make sure we talk about exactly the same way of excluding 7x0x etc, since any small differences may just be the key...

Edited by dr.flo
Link to comment
Share on other sites

How exactly did you do this? In my experiments of this kind, I disabled qdsp5_7200A by means of the config file, but to revert 7x0x I manually edited some files, because removing the 7201A_SURF (or similar) define in config broke the compilation of the kernel.

I think for us to be able to compare the results of such experiments, we should make sure we talk about exactly the same way of excluding 7x0x etc, since any small differences may just be the key...

Here is my patch

Don't be afraid of diff for board.h - I just replaced the file from u8110 (small pulse change re-applied).

Plus I changed in .config for disabling qdsp5_7200A:

CONFIG_MSM_ADSP=y

# CONFIG_MSM_7200A_ADSP is not set

Link to comment
Share on other sites

Could you please try

- kernel .32 zImage

- everything else (ramdisk, rom) from your pulse mini experiment above?

I would expect the camera to open and show a freezing preview!

EDIT: tried this myself.

Results are somewhat surprising

- Camera app opens but does not give any preview.

- Sound works!

- Playback of video doesnt work (-> therefore also no preview in camera)

I've tried myself too.

Exactly the same results as you described.

Very similar behavior that we had with .32 systems, but no video displayed.

Camera part worked the same way as in our most successful experiments :) Anyway it's that same .32 kernel

Link to comment
Share on other sites

I just tried pulse kernel .29 with just 7x0x reverted (so, one with qdsp5_7200A) on pulse mini rom.

Sound working, still no video

pulse mini eclair rom has sound with kernel .32 and u8220 kernel .29 (unmodified regarding to sound)

pulse mini eclair rom doesn't have sound with .29 kernel reverted to qdsp5

does this make sense?

Do you have the pulse-mini .29 kernel sources? for me, the zip I downloaded from huawei failed to extract...

Edited by dr.flo
Link to comment
Share on other sites

I did the same experiment. Enabled qdsp5_7200A back.

7x0x still not used. (actually I replaced all drivers/mevia/video/msm/* from u8110).

Interestingly how enabling "good" qdsp makes camera find it's devices (/dev/msm_camera/...)

:)

Try to download kernel from UK T-mobile - source

It's the same inside - I checked md5

Link to comment
Share on other sites

Interestingly how enabling "good" qdsp makes camera find it's devices (/dev/msm_camera/...)

yes... but if I remember correctly the outcome of our various confusing experiments, we did not yet find a real "good" qdsp with .29 kernel. Either video or audio was always broken.

I would simply want to have a second combination (apart from that one with kernel .32) that results in at least something with camera preview. In order to figure out what breaks the camera in our present "best" situation. It could be some kernel .32 related issue, therefore a .29 kernel that exposes correct camera devices AND has both audio and video working with the "good" qdsp5 might possibly work with a camera lib of the libqcamera family (ascend, u8150, pulse mini). It should at least work up to that "freezing preview" point that we now have with kernel .32

Link to comment
Share on other sites

I think we need to port something :)

qdsp5_7200A from .29 kernel to .32 one and/or

qdsp5 from .32 kernel to .29 kernel

on unrelated note,

msm_camera.c is the one and only responsible for exposing devices either in line with older (libmm-q...) or newer libraries (libqcam)

Link to comment
Share on other sites

in our .29 experiments

qdsp5_7200A behaved better than qdsp5 as:

1. It gave sound

2. It allowed /dev/msm_camera/* devices to be opened and used

Thus it might be a good candidate for porting to .32 kernel. (In any case Huawei introduced it for a reason in .29 kernel. Looks not just only for compatibility with older camera libs...)

Edited by pier11
Link to comment
Share on other sites

This might be true...

After all, sound in your froyo rom isn't working. Another qdsp may help fix that at least.

Edited by dr.flo
Link to comment
Share on other sites

We can also try qdsp5 from OpenEve project -

that's the same chipset device msm7200a - LG GW520.

And the source tree is an official 2.6.32 LG one. Importantly it's based on Code Aurora as we are, contrary to htc dream/sapphipe code that is based on AOSP

Also their tree is patched. So may be that could make some interesting deviation from what we have in the moment.

Looks like their development is booming - alpha versions of kernel for ICS 4 hours ago :)

That tree helped me port usb-gadget subsystem one day...

dsp as a sysbsystem inside msm7200a chip, so the same everywhere.

Edited by pier11
Link to comment
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.