Jump to content

Recommended Posts

Guest Victor von Zeppelin
Posted
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

Guest t0mm13b
Posted
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?

Guest ThrashMan
Posted
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?

Guest t0mm13b
Posted
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

Guest hecatae
Posted
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

Guest t0mm13b
Posted
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

Guest t0mm13b
Posted
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.

Guest t0mm13b
Posted

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!

Guest t0mm13b
Posted

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?

Guest droidvirgin
Posted

Can you flash this to the nightly 17 rom

Guest t0mm13b
Posted
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

Guest droidvirgin
Posted
running this flawlessly with n17 :D

Great thanks for the heads up

Guest ThrashMan
Posted

Applying update2 (unsigned) to N17 causes phone to stop at Android during boot :D

Guest That-Guy
Posted
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

Guest ThrashMan
Posted
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 :(

Guest t0mm13b
Posted (edited)
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
Guest css771
Posted (edited)

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
Guest t0mm13b
Posted
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... :(

Posted

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.

Guest t0mm13b
Posted

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 :(

Guest _amano
Posted

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.

Guest t0mm13b
Posted
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

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.