Jump to content

An experimental CM7 Kernel


Guest t0mm13b

Recommended Posts

Guest Victor von Zeppelin
Pity, that the ar6000 module cannot be recompiled, the date/time stamp on the wifi module is 1st August 2008... so that's saying something there...

Tom, everything that comes out of the buildbot is dated 1st August 2008, for some reason :D

Link to comment
Share on other sites

Guest t0mm13b
Tom, everything that comes out of the buildbot is dated 1st August 2008, for some reason :(

:D

why????? :(

I wouldn't think the buildbot would automate the build of the wifi module or would it simply touch it to be that date?

Link to comment
Share on other sites

Guest ThrashMan
The answer is quite simple - build in the proximity fix into the code, did switch off debugging crapola, wifi broken, wash, rinse, repeat, have been wasting a few cpu cycles trying to determine why wifi fails to load... :D and my first posting speaks my thoughts...about the wifi module that is... :(

lol doesn't the Blade have ar6002 hardware, can that be compiled instead?

Link to comment
Share on other sites

Guest t0mm13b
lol doesn't the Blade have ar6002 hardware, can that be compiled instead?

Good question, no sources for ar6002 unfortunately.... well, not AFAIK, there's ar6003... but completely untested, could backport the 2.6.37 kernel's driver to the .32 and see .... ? any takers? :D

Link to comment
Share on other sites

Guest hecatae
Good question, no sources for ar6002 unfortunately.... well, not AFAIK, there's ar6003... but completely untested, could backport the 2.6.37 kernel's driver to the .32 and see .... ? any takers? :D

you got a tester for that here, and the ar6003 legacy driver does not support ar6001 or ar6002

Link to comment
Share on other sites

Guest t0mm13b
you got a tester for that here, and the ar6003 legacy driver does not support ar6001 or ar6002

I am under the impression that the ar6kl driver is specified for the AR600x chipset, which would lead me to be under the impression that it would be backwards compatible? Is that correct? :D

Link to comment
Share on other sites

Guest t0mm13b
I am under the impression that the ar6kl driver is specified for the AR600x chipset, which would lead me to be under the impression that it would be backwards compatible? Is that correct? :D

Now, the kernel is fixed, proximity sensor and wifi working now.. :( w00t.

Link to comment
Share on other sites

Guest t0mm13b

Updated OP post, now kernel works \o/ go ahead and have phun bladers....

must make this a signature here...

Why I love my Blade: unzip, strip, touch, finger, grep, mount, fsck, more, yes, fsck, fsck, fsck, umount, sleep. :D

saw this somewhere else on modaco, it was from a poster on the Vega forum :( lulz!

Link to comment
Share on other sites

Guest t0mm13b

Mea culpa hacatae - ath6kl is the one... sorry, am quoting from memory here... got mixed up...

anyway, here is the gist of ath6kl from the first linky you enclosed,

'ath6kl' is the wireless driver for Atheros AR600x family of chips. It has been tested to work with the latest in the family, AR6003.

That's my impression that its backwards compatible?!

As for ar6k, have tried that and the eclair version that came from ZTE, both b0rk3d.... :D

What do you think?

Link to comment
Share on other sites

Guest t0mm13b
Can you flash this to the nightly 17 rom

It simply replaces the kernel with the modded version, nothing else is changed... so feel free to flash it on top of the nightly 17, I am currently on RC2, and simply overwrote the kernel and modules ... all is well there :D

Link to comment
Share on other sites

Guest That-Guy
Applying update2 (unsigned) to N17 causes phone to stop at Android during boot :(

Working fine for me on Nightly 17

All I did was Clear Cache and dalvik Cache, flashed update and reboot.

Took about 5 mins to load up though :D

Link to comment
Share on other sites

Guest ThrashMan
Working fine for me on Nightly 17

All I did was Clear Cache and dalvik Cache, flashed update and reboot.

Took about 5 mins to load up though :D

That did the trick......thanks :(

Link to comment
Share on other sites

Guest t0mm13b
Working fine for me on Nightly 17

All I did was Clear Cache and dalvik Cache, flashed update and reboot.

Took about 5 mins to load up though :(

same here... the system needs to "settle a bit" after boot up, considering all apps are competing for time to run, which is an indication they are poorly written, as a general rule, when it comes to writing service level apps, give a timer for to allow the system to "settle" instead of greedily grabbing time, for it to run.... :D

Not to worry, that part of system booting up is normal, on mine, it takes about 45 seconds for the droidwall to flash up a toast message to say it's being granted permission to be allowed to run...

No can do on my part, just simply, some start up apps (incl. services) are competing for time hence the "illusion" that it takes a long time... as a rule of thumb, allow for 5 mins for the entire system to "settle" and yer grand :(

Edited by t0mm13b
Link to comment
Share on other sites

Guest css771

Hey, I couldn't get the importance of some of the modules included. Other than cifs, librasdioif and zram, what do the other modules do. I'm just asking coz I didn't find them in the default cm7 source. AFAICT, evbug has to do with event logging. But why is that necessary if debugging stuff needs to be toned down..

Edited by css771
Link to comment
Share on other sites

Guest t0mm13b
Hey, I couldn't get the importance of some of the modules included. Other than cifs, librasdioif and zram, what do the other modules do. I'm just asking coz I didn't find them in the default cm7 source. AFAICT, evbug has to do with event logging. But why is that necessary if debugging stuff needs to be toned down..

Heh! Good question....

I did tone down the debugging stuff but that had a negative consequence - the wifi broke.... somehow, somewhere, there's a link between the configuration with debugging flags on (some or not all) and the wifi.. bizarre business.... was like huh? WTF... :D :(

You're definitely not alone in this and do wholly agree with your thoughts, it has baffled me for 2 days in a row... but had to reinstate some debugging flags for the wifi to work... :D

Hope this is a satisfactory answer... somehow... :(

Link to comment
Share on other sites

I flashed Clockwork 3.0.1.4 and then N17 and then tomm13b's latest update. Wiped cache/cleared Dalvik cache each time and rebooted in between each one.

All looks very good! Thanks tomm13b!

I am using my crappy iPhone until my screen protector arrives for the Blade, so have only tested proximity with the (great) proximity app. It seems to function perfectly.

Link to comment
Share on other sites

Guest t0mm13b

Hiya everyone,

tis late here... so ...

The progress on this:

  • Wifi module - ar6000 is built in.
  • FM Radio driver is integrated.

The experimental kernel is based off nightly 21.

Objectives:

Get the wifi working using the built in wifi module... tis b0rk3d at the moment due to the changes in the configuration.

The FM Radio driver is in place and loaded by the kernel, but there is something else missing... I have pm'd Andorko for help on this - his application force closes due to failures - whether that's the base android sources, or that the audio manager has changed considerably in this gingerbread source. Even the old and original ZTE radio application that came with the JJ ROM release, that force closes also... so my basis of the research is the framework changed somewhere...

Wifi when using the Settings > Wireless > Wifi, when that gets ticked it fails with simple 'Error' so will continue digging, the problem here is that there's too many binary firmware images lying around all over the place, and of course, different, the checksums varies wildly from one ROM to the next... so it's impossible to say at this stage on which is the real correct firmware binaries despite the ones on TomG's github... but meh, will play with it and see what happens :(

How I got the radio service to work, is, I copied the script init.qcom.fm.sh which is found in JJ's /system/etc, along with a binary executable image called fm_qsoc_patches, and added it to the init.local.rc script, thus a service fm_dl is registered... but breaks :D The real oddity I found is this, fm_qsoc_patches, is supposed to calibrate, and download the firmware into the FM radio chip, no firmware is found anywhere... so for those who have JJ, can you dig around and see... I have disassembled fm_qsoc_patches with IDA and found it loads firmware from /data/app/fm_cal... :D whether the firmware is already within the binary executable...? anyone can shed some light on this?

If you are interested in helping out testing this, pm me as this experimental kernel is not really for usage of public... it's more for devs....

Cheers :(

Link to comment
Share on other sites

Guest _amano

Big thanks for your efforts on making CM feature complete. The lack of FM radio is a big disadvantage for the blade port.

The drivers being loaded is a big first step. Let's see if the application failures can be ironed out.

Link to comment
Share on other sites

Guest t0mm13b
Big thanks for your efforts on making CM feature complete. The lack of FM radio is a big disadvantage for the blade port.

The drivers being loaded is a big first step. Let's see if the application failures can be ironed out.

Howdy all,

Have built a new kernel available for anyone to try out and test...please see the first posting....

Cheers :D

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.