Android OS Forum banner
1 - 20 of 21 Posts

· Android Mechanic
Joined
·
201 Posts
*EDIT* So far its staying persistant. MAC and all other wireless settings have not changed since this. Also, performance increased slightely, tho this could just be attributed to the ridding of errors rather than an increase to the normalized wifi performance level. Still testing this with different calibration values tho. Also I have been messing with different ini values, hexedits on the nvs and firmware, jar edits, disassemling the proprietary libs/modules, and trying to implement open source/freshly compiled/optimized code. Far from over, but for now atleast it has fixed my wireless issues. Also note I left the init.mapphone_cdma.rc alone after manually executing it (it will automatically revert itself) and also placed the nvs_map.bin in both /pds/wifi and /system/etc/wifi for the time being. *EDIT*

So first couple things.... I am no cvpcs, jt1134, Rev, Razor, Framework, Droidxchat,r2, bmc, sensei, really do I need to go on? lol That said, I am not a complete idiot when it comes to linux and android. I have been modifying and tweaking for a long time on multiple platforms. So please don't think this wall of eye destroying text is going to change the world and/or drop-kick platypuses (platypusi? I think I prefer that version). Just one tired persons rambling on his trip thru tiwlan today (as well as gps too, since well why not), and I'll leave all the other adventures and projects for another day. So just be prepared for a wall of text ....

Ok, so today I noticed something about the wireless.... its more convoluted then an MC Escher painting. Proc's, modules, drivers, init, everything going against each other. Now I knew that the X is a mess in ways due to the locked boot loader, but I wondered if I could maybe do something to simplify the process the same as I did the GPS. Now the gps seemed to share some of the same issues. Proc's and confs being plain or libs conteracting, etc. The end result was lock times that took forever, sometimes 30 secs+....real PITA at times. Well that one was easy actually, well sort of, I looked at other platforms and realized the lto and xtra files were not being used or even downloaded by the X. It was straight .conf baby, so we had to look into that... So I reworked and rewrote the gps.conf, retraced the file layout, changed the supl, changed the host, added new servers, most of the same tweaks you all probably have done. Got me the same result as you I'm guessing..... my lock time for gps is now roughly 1 sec with a max of 3 secs, within that time its viewing and receiving from 9/9-12/12 sattelites, with the link lowest at 24, also accuracy increased from 36ft downb to 20-24 ft. Hmm not, bad, just some manual tweaking.... AND that is without fulling porting over the LTO Xtra functionality.... thats just straight conf/libs/supl/ and hint of gps aid data that is working atm,

So the wireless, well not so much. Between the wpa_supplicant misbehaving or straight up eating itself, 252532523 different modules/drivers/confs/ blah blah all trying to do the same thing, well nothing was really happening I found. I mean, yeah, I had internet, could connect to wireless networks, there was no real issue...yet. See, the problem that I noticed wasn't on a fresh install it was after the same build had been running for awhile. So got me wondering, what would do that. Well biggest would be the driver and module I figured. So, today I decided to look thru logs and dmesg lsmod all the fun crap. Noticed a big issue, the driver wasn't actually working correctly! It was trying to, tryin hard, but failed to initialize properly every time. This failure would cause some of the issues I had been noticing such as MAC yahtzee, inconsistent speeds, connectivity issues, etc. So I decided to force the issue based on what the phone and logs were telling me was happening.

Well first off it was not calibrating, well that ain't cool.... not calibrating means no firmware updates, files missing, errors compiling ontop of errors, and just well no beuno. Problem is this: The calibration of the driver/interface yields you an nvs_map.bin. The nvs in turn completes the wlan_loader's needs to update firmware. All of each play a part in the module/driver/interface properly initializing. Well it wasn't, and it didn't....so I forced it. Manually calibrated via console:

# wlan_cu -itiwlan0 -b

/ w p 1 l 2 f 2

/ t r h 0 7

/ t b b 375 128 0

/ t b t 1 0 0 0 0 0 0 0

/

q

And just like so, bam, freshly calibrated and nvs_map.bin was created. Moved it /system/etc/wifi/ (mv nvs_map.bin /system/etc/wifi) double checked my permissions. Next step: Firmware.

For that we look to the init scripts and a service named wlan_loader located in the /system/bin. The loader is called for in the init.mapphone_cdma.rc file, which is weird as its usually in the straight init.rc..... whatever.

When I tried to manually use the service I would continue to get errors regarding driver initialization, so I checked the format and saw it listed as :

service wlan_loader /system/bin/wlan_loader \
-f /system/etc/wifi/fw_wlan1271.bin -i /system/etc/wifi/tiwlan.ini \
-e /pds/wifi/nvs_map.bin
disabled
oneshot

Seemed odd order and o hey.....the nvs is.....wait why there?! So I changed it up to something a bit more familiar as well as double checking myself as to the order via interwebz. Changed it to:

service wlan_loader /system/bin/wlan_loader \
-e /system/etc/wifi/nvs_map.bin \
-f /system/etc/wifi/fw_wl1271.bin \
-i /system/etc/wifi/tiwlan.ini
disabled
oneshot

with this I manually re-proc'd the init.mapphone via root explorer. Didn't work completely awesometastically as it created a mess and mostly didn't work, and why would it.... supposed to be on boot, not after. But one key thing was as I had turned off wifi, it DID reproc that setup. So I turned wifi back on and it kicks off. Fully initializes....it starts, it checks its firmware, it updates and upgrades its firmware, module kicks in with kernel, nvs creates proper MAC, and its working awesome..... until reboot. Change doesn't stay persistent. So I took the chance and made some changes to tthe tiwlan.ini I had wanted to.... redid the procedure....same effect. Gold. Until reboot, where it reverts. Which is where I am at currently, trying to make it persistant. Been mucking around other sources affecting it as well, but didn't really go to crazy trying to figure it out tonight....its late lol.

What I am thinking, and going to try first, is from ground up. The wlan is originally made during system image creation via a few different files:

-libs/kos/sos etc......

-the BoardConfig.mk file is what sets a lot of the values and actually enables the wl1271 in a way. As well as the wl1271 board.

-the init.rc is well....the init.rc lol. We already saw how its affected. However, being made this way from CREATION might make it more stable as well as persistant I am wondering.....

-WLAN well..... ummm yeah, need I go there? Its a lil important to how the build works :wink2:
dhcpcd, wpa_supplicant, wlan_loader,..... etc etc

-As well as a few others.....bluetooth setup affects it, as well as the OMAP setup, stuff like that.

So that's where I got with it today.... got it fully functioning, sans bugs, calibrated, updated, zooming around like a fat kid chasing after a cupcake..... but can't get it to stay persistant.....persistently lmao.

Now, there are other easier routes to take then a full rrebuild from source. But some of the other stuff I have been working on really would work better if mixed in from scratch. Webkit and skia optimizing and tweaking for internet, this stuff, fully trying to work in LTO/Xtra compat, launcher tweaks, I/O optimizing, SQLite modification, etc etc..... Hence, the jump all the way in the pool for a swim as opposed to playing around with init scripts or symlinks. So theres that, and for those that made it all the way to the end, im kinda impressed, thats A LOT of text ... and didn't talk about any of the other projects really.... sorry, lol, im tired lmao, if curious about anything please feel free to ask whenever however, I don't mind. I'll post periodically about where everything is at if folks want it, otherwise I'll keep the text-luge away lol.
 

· Supporting Member
Joined
·
224 Posts
I really enjoyed your write up, very interesting. I am curious to see if you can succeed with this, I have always been disappointed with wifi on the x. If you need testers or anything like that let me know, good luck!
 

· Android Mechanic
Joined
·
201 Posts
Discussion Starter · #3 ·
Hmm so few more tweaks and staying persistant for now. Full inititialization from boot as well as files are being correctly identified. Ironically, same can he said for LTO/XTRA tho must be said did have a nice little boot loader fun-mergency..... guess that means to leave alone for now lol. Least both are staying persistant for time being....

Sent from my DROIDX
 

· Android Beginner
Joined
·
12 Posts
blackadept - excellent post! I started down this path about a week ago trying to read up on creating the nvs_map.bin calibration file but quickly got discouraged as I don't operate at the same level of awesome as you do! I would love to see a writeup on what you did to make it "persistently persistent" (lol!) Keep up the great work and don't be afraid to ask me or any of the others here for help. I don't mind bricking a phone in the name of progress! This post will probably be watched very closely by many people that are in the same boat as us - get some rest and be sure to keep us updated! We'll all be impatiently waiting patiently for any good news to turn up to solve this ridiculous problem!
 

· Android Beginner
Joined
·
12 Posts
It's not a "ROM" thing necessarily. Even going back to the SBF files yields no positive outcome/solution. Many of us have tried unsuccessfully to SBF to stock, update to current .605, different roms/radios/praying/virgin sacrifices (THAT was a waste!)/etc and so far nothing has solved this issue for any of us! Very frustrating. are you experiencing this issue too? if not, i'd be interested to see if you have the nvs_map.bin file, among other specific (important) settings.
 

· Android Mechanic
Joined
·
201 Posts
Discussion Starter · #8 ·
The problem as to why MAC was not fixed is the nvs. however the problem for the nvs CAN be the ROM but can also be equally the fault of the operator.

The nvs is what the MAC is pulled from, as well as a lot of other settings. This file is actually the parameter's given to the daughter, sort of like your drivers license. Your drivers license tells you who you are, where you live, etc. If you didn't have that you'd have to figure it out every time, slowing eberything down and causing variances in how you act. That's where the nvs comes in, with parameters set, drivers and modules in place, it has all its needs to do its job.

When you turn your phone on it goes thru a series of steps, one of which is initialization - read:wifi <- . If the phone doesn't have the nvs_map it is unable to completely initialize as it can not finish the process without it. This continues to cause issues as the phone stays on because of how the interface works. As the phone runs it's actually periodically calibrating the device automatically when it detects the firmware is running due to temp, new connections, voltages, squirrels, pirates, and other such shenanigi (don't hate me for the 'i' pluralilawesomeness) trying to minimize or eliminate any variances affecting performance. This is why you never really hear about needing to calibrate, its done for you.....

BUT, with no nvs it is still going to go thru the same motions. The difference is instead of it completing painlessly and innocuously, it instead ends in error after error proc'ing and re-proc'ing trying to rectify this. As uptime rises, so does the error count, and eventually, atleast I believe, starts causing performance and connectivity issues. As soon as you calibrate it once, you should be good to go as far as that is concerned. Once it's happy, your happy. Now when it initializes it has the file needed to set the daughter's parameters. Having that allows it to complete its initialization fully (with no MAC change) and also allows it to successfully complete its periodic calibrations during uptime and firmware use.

Another thing to keep in mind is there is multiple options for calibrating set within that string of letters and numbers I posted there. A lot of how the device acts can be attributed to that because these options are part of what is making the nvs, which then is part of what is making the wireless work. The string I used is just a basic generic one, but there are others for different standards and such. I'll try and make a post either tonight or tomorrow going over the calibration strings a little more detailed.
 

· Android Lover
Joined
·
230 Posts
blackadept said:
*EDIT*

Well first off it was not calibrating, well that ain't cool.... not calibrating means no firmware updates, files missing, errors compiling ontop of errors, and just well no beuno. Problem is this: The calibration of the driver/interface yields you an nvs_map.bin. The nvs in turn completes the wlan_loader's needs to update firmware. All of each play a part in the module/driver/interface properly initializing. Well it wasn't, and it didn't....so I forced it. Manually calibrated via console:

# wlan_cu -itiwlan0 -b

/ w p 1 l 2 f 2

/ t r h 0 7

/ t b b 375 128 0

/ t b t 1 0 0 0 0 0 0 0

/

q

And just like so, bam, freshly calibrated and nvs_map.bin was created. Moved it /system/etc/wifi/ (mv nvs_map.bin /system/etc/wifi) double checked my permissions. Next step: Firmware.
are you supposed to have spaces in these commands? IE: "/ w p 1 l 2 f 2"
 

· Android Lover
Joined
·
230 Posts
DONE!

# wlan_cu -itiwlan0 -b
wlan_cu -itiwlan0 -b
user_main, start
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
/ w p 1 l 2 f 2
/ w p 1 l 2 f 2
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../poWer> set_Power_mode, set_powersave_powerLevel, set_deFault_powerlevel, set
_doZe_mode_in_auto, traffic_Thresholds, eNable, Disable
/ t r h 0 7
/ t r h 0 7
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../biT> Bip/, Radio debug/
.../Radio debug> Get hdk version, cHannel tune, Tx debug/, rx Statistics/
Channel tune of channel 7 was performed OK
/ t b b 375 128 0
/ t b b 375 128 0
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../biT> Bip/, Radio debug/
.../Bip> update Buffer calref point, Tx bip, Rx bip/
BufferCalReferencePoint was configured succesfully
/ t b t 1 0 0 0 0 0 0 0
/ t b t 1 0 0 0 0 0 0 0
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../biT> Bip/, Radio debug/
.../Bip> update Buffer calref point, Tx bip, Rx bip/
Entering FillMACAddressToNVS
Mac[0]=00
Mac[1]=17
Mac[2]=00
Mac[3]=e0
Mac[4]=bc
Mac[5]=41
exiting FillMACAddressToNVS
/
/
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, po
Wer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
q
q
 

· Average Android
Joined
·
555 Posts
Excellent write-up. Most of it was absolutely beyond me, but I still like this kind of thing. So the nvs_map.bin is created from scratch from the first set of commands, which is obviously essential for those with the MAC address probelm, but what is the purpose of all of the firmware stuff? Is there any advantage for those of us not currently affected by the MAC bug? I like to get everything as streamlined and speed bump-free as possible.

Also, you mentioned work that you did on the GPS. Again, are there any improvements to be gained by other users by implementing your process?
 

· Android Beginner
Joined
·
2 Posts
So i did all these:

# wlan_cu -itiwlan0 -b

/ w p 1 l 2 f 2

/ t r h 0 7

/ t b b 375 128 0

/ t b t 1 0 0 0 0 0 0 0

/

q
And it went fine. However, how do I move the file? putting in that move command doesn't work, and terminal says "cant rename..." Likewise, my MAC continues to change. What am I doing wrong? :(
 

· I just hide here
Joined
·
1,883 Posts
Hey black did you want this thread stickied or the other one u made that is stickied right now? Its completely up to you. And because of this revnumbers is going to incorporate a fix for the root of these problems. Apparently he said he forgot some files for wifi
 

· Android Beginner
Joined
·
2 Posts
SyNiK4L said:
Hey black did you want this thread stickied or the other one u made that is stickied right now? Its completely up to you. And because of this revnumbers is going to incorporate a fix for the root of these problems. Apparently he said he forgot some files for wifi
(im still kind of new here) - where/when/how/who can I get this fix? Where would I need to look?
 

· Android Mechanic
Joined
·
201 Posts
Yeah some files were....sorta...but not necessarily, lol. Wish I could annoy him sometime bout it lmao. Tbh, this fixes easiest from build up. While you can fix it when running it is easier and works better with an approach from compile and up, changing stuff there helps a lot as you can make edits to the persistent files, like the init scripts, whereas edits post fix can revert. That's why I made mention of running the mapphone init at the end there.

Another build time aspect is the ability to make similar edits, on a more macro level, to make it more device specified. Being that the ROM is such an awesome, practical, fast, and well ... at risk of sounding a kiss a$$ ... honestly, revolutionary of a ROM, it has grown to become the beast it is. That is a damn good thing for us, I mean look at all developements its bred and is breeding, you don't get that often, if ever. One downside is that multiple phones = multiple builds, multiple builds = multiple methods, multiple methods = multiple files, etc. While the build process is very good at individualizing the method, as is its coding, sometimes tho redundancies and differing build strings can still make it thru some of the core build which span devices. *actually I wrote another big ol post yesterday about how hapzard modding can cause more issues than solve. After I made it I wasn't sure about posting it and deleted it ... That touched on this idea tho, obviously for different reasons lmao*

I know that he can't officially do this stuff, just isn't practical for as many builds as they have, but the one's kanging it thru the world can. :p

As to which one stickied, I'll leave that up to y'all. I just felt it might help some folks so I posted it even tho the work is still very much in testing as a whole. Tho whichever is used I really should go back and clean it up a bit lmao. Also gotta figure out where to put all this other crap once its ready (or should prolly instead say "if " not when lmao .... hate bugs and proprietary hurdles....lmao) whether on this post or that one ... or a different one lmao. Irconic part is I actually used to make posts like this often, regardless of it was theory, fixes, or any mods/scripts I had made, just to share, kick around ideas, and learn as well.
 

· Android Mechanic
Joined
·
201 Posts
Discussion Starter · #18 ·
ahh crap, sorry there aark, ADD fail on answering you there lol.

Yeah bud, thats the idea anyways. Basically changing the .conf to a better pool server, changing the supl, and adding some widely used tweaks. I cant remember what I did with the old one I based off of ... I'll look later tomorrow (errr today?) and post it. Ain't hard to find tho, like I said its widely used.

The other part of it beyond the .conf is how and from where we get our aGPS data and setting up the phone to use LTO and XTRA . Also fixing the system files so that our own phones make the resulting configuration files....
 

· Android Lover
Joined
·
230 Posts
SyNiK4L said:
Hey black did you want this thread stickied or the other one u made that is stickied right now? Its completely up to you. And because of this revnumbers is going to incorporate a fix for the root of these problems. Apparently he said he forgot some files for wifi
I thought i had it traced down to cm4gb (or CWR)......Heh...
http://rootzwiki.com/showthread.php?1497-WiFi-MAC-address-changes-when-I-power-WiFi-on-and-off.#15

That's when mine went bad (actually when CWR didn't work and a re install had to happen)

Glad we got it working..
 

· who needs drugs when you have a Nexus (CrackFlashe
Joined
·
286 Posts
i hate to say it, but you would think with all the devs working on AOKP, and Cyanogen, this issue would not happen to every one of my phones the moment i flach a CM mod.
im currently looking for a fix for my Gnex along the same lines as this, which fixed my DX. and it remains fixed to this day.
 
1 - 20 of 21 Posts
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top