Investigation: Gen2/HSUPA/nvbackup

[Guest hedgepigdaniel]

I have been poking around here and there and I have come (tentatively) to the conclusion that HSUPA support on Gen2 depends on something in the NV memory - which is backed up in channel1.nvm.

mrradmir and lemovarinit suggested this originally in this thread. Some people at least (hecatae, pisti7204) reported that HSUPA worked consistently. hecatae reported that it worked on both Comviq and Telia Gen2 firmware. Most others have had no luck, myself included.

I did a simple text search through some Gen2 amss.mbn files and found the following strings in each (each line is a new string, in the file they are separated by a null character)

RRCEUL: Read failed for NV_WCDMA_HSUPA_CATEGORY_I(nv item: 4210), set default to 5

rrcnv.c

RRCEUL: HSUPA category NV (nv item: 4210) contains invalid category(%d). Set to default

Could Not Read rrc_wcdma_hsupa_cm_enabled(nv item number 5090) - Enable by default[/codebox]

A couple of conclusions:

1. These look like strings to be written to a log somewhere, and if the location of this log was known it would be of great use
   
2. somewhere in channel1.nvm (item 5090) is a flag (rrc_wcdma_hsupa_cm_enabled) that enables or disables HSUPA. If it cannot be read, HSUPA is enabled by default
   

I would say that since Blades have generally not been sold with HSUPA support, this flag has been turned off for most phones. If we can find where in channel1.nvm this flag is set, then I think we might be able to enable HSUPA for those that haven't yet been able to. Before that though, it would make sense to take channel1.nvm from someone who has HSUPA working, and see if it can enable it for someone who doesn't. If anyone who has HSUPA is willing to share their channel1.nvm (with the IMEI changed, if you like), I will gladly try it on my phone and report my results. Instructions to create channel1.nvm from your phone are in [topic=337757]this thread[/topic] - it requires no changes to your phone other than putting stock recovery on it. I'll give the base one linked in that post a go aswell, but I'm not holding out too much hope.

Additionally, one would assume there is a pattern in terms of which Blades have HSUPA support. Those who have it enabled, what country/provider did you originally buy your blade from?

EDIT:

I was probably wrong to assume that item 5090 enables or disables HSUPA, rather it enables or disables cm, whatever that is. tried changing that to no avail (although I didn't try it on all firmwares)

I tried flashing the Comviq, TeliaSonera, and Hungarian updates (the entire update) and then used speedtest and failed to get HSUPA each time. If that doesn't work, then I doubt any combination of amss.mbn files involving those three will work.

Ideas:

QxDM allows a complete backup of nv memory to a .qcn file. If i find someone who gets HSUPA, restore their nv backup to my blade, and install the same firmware and ROM, then I believe I will have restored everything significant in the phone's memory. If HSUPA then works, then the investigation can continue. If it doesn't, I can only conclude that there is some hardware difference in different blades that enables or disables HSUPA or that some HSUPA networks work with the blade and others don't. One idea I had is to induce the lost IMEI problem to see if by some miracle that enables it.

Edited May 15, 2011 by hedgepigdaniel

[Guest cpg]

This is an interesting point. Sadly, AMSS is huge and a bit messy. A few other interesting texts i found are "This shouldn't happen" and "Should never reach here" :unsure:

I checked my nvm backup and items 0x1072 (4210) and 0x13E2 (5090) aren't even in it. I wish my provider would offer HSUPA, so i could experiment a bit with these values :)

[Guest Schwinni]

A few other interesting texts i found are "This shouldn't happen" and "Should never reach here" :)

In the Java world (and the Dalvik VM is related to the Java VM - although very different in some things) that's quite normal to write such a comment.

When the compiler forces you to catch a certain exception although you know that it cannot occur (because of the checks you did earlier) you write such a comment. :unsure:

[Guest cpg]

In the Java world (and the Dalvik VM is related to the Java VM - although very different in some things) that's quite normal to write such a comment.

When the compiler forces you to catch a certain exception although you know that it cannot occur (because of the checks you did earlier) you write such a comment. :unsure:

Though this part of the phones firmware isn't related to Java/Dalvik :) To me, it brings up an image of a blue screen of death showing something like "better luck next time" :P

Personally, i'd have chosen something more descriptive (blue screens actually are!), though in this case, noone would probably see those messages anyway, even if the code would come there.

Anyway, some further digging shows these 2 NV items (4210 and 5090) are not included in the backup made by the windows flasher (only a small selection of the settings is stored in channel1.nvm). And when cefs.mbn gets written to the phone, 4210 defaults to the value 5 and 5090 is not set. Those are the same values i got from my phone (which has the stock Orange cefs, as i haven't used the windows flasher).

However, some people could have different values for these for some reason, or there could be other items affecting bands and/or speed.

[Guest Schwinni]

Though this part of the phones firmware isn't related to Java/Dalvik :unsure:

I think such comments are wide spread in every programming language.

Sometimes you need some helper variables in some loops which you never read or the state doesn't really matter. A common comment for that is "// doesn't matter". :P

But this completely looses context to the thread topic now. So I better shut up. :)

[Guest hedgepigdaniel]

Having fiddles some more, I don't think that all NV items are stored in channel1.nvm - just a subset of them. Also, the location of the data in channel1.nvm bares no particular relation to the item number. Using QXDM however, I managed to change the value of item 5090 (a boolean value) from 0 to 1. I also confirmed with another phone that HSUPA works on my SIM card (it does, at 1400Kb/s on a Galaxy S). Even after this change, HSUPA does not work. Next thing to try is some experimentation with amss.mbn versions and ROM's. I also want to see if these NV settings are persistent after flashing firmware. I think alot of them may be a bad idea to fiddle with.