yashsingh1/xdaforums huggingface dataset:
[Windows Mobile Apps and Games] mikrus:
Hi!

I have same problem like ArgieCZ. I had my BMA on factory Xperia X1 WM6.1 (GENERIC UK R2AA010) via Jbed till today. Couple months ago I've installed blizzard_mobile_auth_EU_BattleNetMobileAuthenticator_240x320_icon_24x24_1_0_0.jar, synchronized and attached to WoW account. It worked just fine without any problems.

Today I've updated my phone via SE Update Service (Generic UK R3AA010) previously unattaching BMA from WoW account. Afret update I've installed BMA and now I having problems with synchronization. My GPRS connection work just fine on Opera but when I trying to activate BMA I always get synchronization error.

Any ideas?

Ps.: Sorry for my grammar. English isn't my native.

Edit:

I done it. I don't know if there is a pattern but it's what I will wondering. So what I do:

When I frist installed BMA after software update I've used .jar file from memory expansion card that I used couple months ago. Like I told you above I couldn't success synchronization process. So I uninstalled it and extracted again .jar from downloaded .rar file to another location in my memory card. Then I go to instalation process and everything is OK. This is strange but it bring to my mind similar situation couple months ago when I trying install BMA and my "first shoot" which was unsuccessful because of wrong GPRS configuration. After that I succed when I used installler from diffrent location. Maybe it stores some file for security with path to installer .jar? I don't know.

But I find something new. I wanted to find out if my installer is broken or something I've put the .jar file to my old P990i phone via BlueTooth. I have old non-active SIM card in P990i for "turn on" purpose (no GSM/GPRS connection, just using as my TomTom device :) ). For BMA synchronization I've used WiFi connection to my home router. And guess what? It's work! Synchronization goes with no problems. Got serial number and can use it. So you don't have to connect via cellurar GPRS/3G connection - it works via WiFi aswell. Another tip: in P990i you get full screen view what I wish to have on my X1 phone.
[Windows Mobile Apps and Games] SaiBork:
So... couple of months further? How is this windows mobile client doing?

The java one works, but the text is weeny and the menu buttons are a pain on touchscreen mobiles with hardware buttons underneath (like my HTC Touch HD)
[Windows Mobile Apps and Games] enlikil:
update

Well I was able to get it to work on windows mobile 6.1 and 6.5 but i had a problem trying to get windows mobile to enroll me into the program.

I ended up having to use the windows version of the authenticator to get my code.. then copy it to my phone.... then it worked..

but i couldn't get it all into one pretty package, mostly becuase of Microsofts lame port job of .net into windows moble that was giving me problems with the enroll ... becuase i don't know enough about the Http/streams and the way windows mobile emulates Webget()
[Windows Mobile Apps and Games] Snowscar:
Sry but i didnt bother reading the whole thing..

I have a HTC Touch Pro 2 which is the same as the HD2.

You have to get the java app from blizz mobile store. You can then run it using Jblend which is installed on your phone.. The problem seems to be internet connectivity. Even though i have wifi and gprs the java app fails to recognize it.

You can also run the authenticator as an exe file that u compile urself

http://alfred.co.in/how-to/blizzard-authenticator-pc-version-how-to/
[Windows Mobile Apps and Games] ryan_975:
Just wanted to add a little to this: the 114 byte string is not a hash, but is actually the hex representation of the 40-byte secret token and the 17-byte serial number that has been bitwise XOR'd with a 114 byte mask. 40+ 17 = 57 bytes. Each byte is represented by two hex digits, so 57 * 2 = 114 bytes.

In the string you've listed,

5dbd459e6811525d500083dd1496a45d60a572131f5ee81bdb92fbc8e35f3fe2aa3c1f82b209470d

is your secret token, and

f0c8894d27fa5e494830682b76bebc5ead

is your serial

I have found the last 34 digits of the mask to reveal the 17-byte serial (represented as the last 34 bytes of the string in the file),

a59ba47c17ca6c6479015c1d5bxxxxxxxx

which means your serial number is

US-1007-1146-xxxx

I can't figure out the first 80 digits of the mask to reveal the secret token.

EDIT: just found the entire mask inside the executable...

398e27fc50276a656065b0e525f4c06c04c61075286b8e7aeda59da9813b5dd6c80d2fb38068773fa59ba47c17ca6c6479015c1d5b8b8f6b9a
[Windows Mobile Apps and Games] cdm9002:
It is just encoded. You need to convert the whole string to an array first.

You're missing a 3 at the start.
[Windows Mobile Apps and Games] ryan_975:
oops, so I am. lol Thanks.

I knew that it was possible to find the mask very easily, as I've seen others do it, but I've not learned enough to do it on my own, so I was resorting to less efficient methods. Mostly just wanted to point out that there was nothing special about that 114-byte string the person I quoted had found.
[Windows Mobile Apps and Games] cdm9002:
Yep, agreed. They could of made it a lot harder. I traced the decompiled opcodes to work out what was happening. Reminds me of those assembler days :)

I included the capability to read the Android HASH value in my port of the Authenticator to .Net/C# at code.google.com/p/winauth/

-c.
[Windows Mobile Apps and Games] Squishie:
I've been trying to pull said XML for a while now with little luck. I'm running a fully stock 2.2 Nexus One. I can adb shell into the the directory that the .xml is stored (/data/data/com.blizzard.bma/shared_prefs/) yet every attempt I've done to pull the file is Premission Denied. Any tricky work-arounds for retrieving the file? I would very much like to have a dual authenticator system through using an emulator since the wife and I share the same account.
[Windows Mobile Apps and Games] gamebifi:
somehow i cant download the jar and jad file , i did get the sms so have payed for them but the files end up as files from 0 bytes. i followed this guide //deathcoil.net/authguide.html if someone has them i apreciate an alternate download location
[Windows Mobile Apps and Games] Squishie:
Well, after rooting my phone through the one-click app, I installed Cyanogenmod and was able to retrieve the xml easily.

I talked to a good friend of mine and had him write up a little script that will xor the code and spit out the ID and Token.

I realize the potential security risks, but having the authenticator on the pc and phone makes it so much easier to manage.

If the unthinkable happens, I'll swap back to my physical authenticator.
[Windows Mobile Apps and Games] RickoT:
Check out my post here on getting this working (very nicely) on my tp2, I imagine it will work beautifully on any touch screen phone

http://ip208-100-42-21.static.xda-developers.com/showthread.php?t=752975
[G1 Android Development] jokersax11:
i thought this might have better set up as its own thread.

edit

i have done some mild kernel work in winmo on a 7200 and do believe this is not only possible but a decent hack worth putting time into. also no2chem is to winmo as cyanogen is to android. so its from a good source
[G1 Android Development] coolbho3000:
I posted in that thread too. I think the 65nm MSM7201A in the G1 could be easily pushed to 768MHz.

Then add 768000 to static struct cpufreq_frequency_table freq_table[] and you should be able to echo those values into scaling_max_freq and scaling_min_freq
[G1 Android Development] random_username_:
although this would kill the battery in 5 minuites it is great for hero and emulators as well
[G1 Android Development] mcarey66:
If someone could pull that off it would be killer.

Do you really think it would be that big of a drain on the battery if it was only climbing that high under heavy load situations rather than being set that high at all times?

I would be willing to take a hit in battery life to gain a performance increase of that type as long as the batter life doesn't end of 1/4 of what it was.
[G1 Android Development] javacody:
I've got an upgraded battery, so I don't care. Give me more speed!

:D
[G1 Android Development] jokersax11:
One note please remember this was confirmed on 7500 not 7501a also it was a cdma phone not gsm but it could work with some work
[G1 Android Development] monkey804:
If this makes a big different in performance, I'm willing to use the brick size battery I bought. It's been laying around unused since I bought it.
[G1 Android Development] random_username_:
i am willing to try this but i dont know which file you edit. If someone can tell me ill give it a go
[G1 Android Development] velazcod:
I don't think it'll be that easy though
[G1 Android Development] daproy:
You need to recompile the kernel with the added values in clkctl_acpu_speed acpu_freq_tbl[] in http://android.git.kernel.org...b0b8;hb=HEAD

I might give it a go if you want to try it out. I think we should determine if the last two 5 and -1 numbers are important first. Does look like scaling:

78 /* Index in acpu_freq_tbl[] for steppings. */
79 short down;
80 short up;

As far as I can tell the stepping values are used here:

332 while (cur_s != tgt_s) {
333 /*
334 * Always jump to target freq if within 256mhz, regulardless of
335 * PLL. If differnece is greater, use the predefinied
336 * steppings in the table.
337 */
338 int d = abs((int)(cur_s->a11clk_khz - tgt_s->a11clk_khz));
339 if (d > drv_state.max_speed_delta_khz) {
340 /* Step up or down depending on target vs current. */
341 int clk_index = tgt_s->a11clk_khz > cur_s->a11clk_khz ?
342 cur_s->up : cur_s->down;
343 if (clk_index < 0) { /* This should not happen. */
344 printk(KERN_ERR "cur:%u target: %u\n",
345 cur_s->a11clk_khz, tgt_s->a11clk_khz);
346 rc = -EINVAL;
347 goto out;
348 }
349 cur_s = &acpu_freq_tbl[clk_index];
350 } else {
351 cur_s = tgt_s;
352 }
[G1 Android Development] random_username_:
yep ill try it out if you compile it:D:D btw what is the worst hat could happen to my phone?
[G1 Android Development] daproy:
The code is optimized to stay on the same PLL so the last two numbers are the array index in the acpu_freq_tbl[] two go down to or up to from that entry. Since our new entry is ACPU_PLL_1 the next one down is entry 6 and there are none to step up to so it should be:

{ 768000, ACPU_PLL_1, 1, 0, 128000, 5, VDD_7, 128000, 0, 6, -1 }

The step up from 384000 should also be changed now that we're adding a higher frequency on the same PLL to:

{ 384000, ACPU_PLL_1, 1, 1, 128000, 2, VDD_6, 128000, 0, 2, 8 }

So the acpu_freq_tbl[] should be:

static struct clkctl_acpu_speed acpu_freq_tbl[] = {
{ 19200, ACPU_PLL_TCXO, 0, 0, 19200, 0, VDD_0, 30720, 0, 0, 4 },
{ 122880, ACPU_PLL_0, 4, 1, 61440, 1, VDD_3, 61440, 0, 0, 4 },
{ 128000, ACPU_PLL_1, 1, 5, 64000, 1, VDD_3, 61440, 0, 0, 6 },
{ 176000, ACPU_PLL_2, 2, 5, 88000, 1, VDD_3, 61440, 0, 0, 5 },
{ 245760, ACPU_PLL_0, 4, 0, 81920, 2, VDD_4, 61440, 0, 0, 5 },
{ 352000, ACPU_PLL_2, 2, 2, 88000, 3, VDD_5, 128000, 0, 3, 7 },
{ 384000, ACPU_PLL_1, 1, 1, 128000, 2, VDD_6, 128000, 0, 2, 8 },
{ 528000, ACPU_PLL_2, 2, 1, 132000, 3, VDD_7, 128000, 0, 5, -1 },
{ 768000, ACPU_PLL_1, 1, 0, 128000, [B]5[/B], VDD_7, 128000, 0, 6, -1 }
{ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 },
};

and

static struct cpufreq_frequency_table freq_table[] = {
{ 0, 19200 },
{ 1, 122880 },
{ 2, 128000 },
{ 3, 245760 },
{ 4, 384000 },
{ 5, 528000 },
{ 6, 768000 },
{ 7, CPUFREQ_TABLE_END },
};

coolbho3000, does this sound correct? You sure about the values for a11clk_src_div, ahbclk_khz, ahbclk_div at 768000? Sound like you've already started looking into this.

Is there a reason to change the AHB bus clock divider ahbclk_div to 5?
[G1 Android Development] daproy:
JJbdoggg, not sure what it'll do if it doesn't work. Probably freeze up the phone.
[G1 Android Development] miketaylor00:
Your processor could get fried.
[G1 Android Development] coolbho3000:
I'm 100% sure about a11clk_src_div (according to Qualcomm docs 0000 means you don't divide the PLL at all, leaving it at 768000, 0001 means you divide by 2, 0010 means you divide by 3, etc) but I'm not sure if ahbclk_khz is supposed to go above 132000 so I left it at 128000, making ahbclk_div 5 (768000/6 = 128000). Other possible values for the two might be 153600 and 4, and 192000 and 3. I'm digging through the Qualcomm documentation to see if I can find anything.
[G1 Android Development] daproy:
More info in a follow up from the original post:

http://www.nuerom.com/BlogEngine/post/2009/09/08/Yet-more-notes-on-overclocking.aspx
[G1 Android Development] coolbho3000:
Seems unstable, but worth a shot. Seems like the worst that's happened to a WM user is a freeze.

3) There is a clock divider for the AHB that is separate from the ARM11 frequency. I’ve tried increasing the divider from the default of 0x4 to 0x5, with no real increase in stability.

It seems like multiple AHB clocks/dividers would work then, probably answering my above post... maybe best to try and see which is the most stable?
[G1 Android Development] The Reverend Gridlock:
that would end getting really hot, if it is usable and perfected, hell yeah would i love to have some power like that out of my g1, i got 2 batteries
[G1 Android Development] daproy:
Well I played around with this a bit. Pulled cyanogen's latest kernel code with BFS from github. Patched acpuclock.c (patchfile attached). Compiled with the android toolchain.

First off there is definitely something wrong with the kernel i compiled because it was horrible slow to boot. I did use the .config from cyanogen 4.1.6 without edits so I'm not sure why. I can't imagine it was due to the patch since with default min and max scaling it should be running the same as the kernel compiled by cyanogen.

Regardless, I was able to try to overclocking:

# echo 528000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# echo 768000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# cat /proc/cpuinfo
Processor	: ARMv6-compatible processor rev 2 (v6l)
BogoMIPS	: 527.15
Features	: swp half thumb fastmult edsp java
CPU implementer	: 0x41
CPU architecture: 6TEJ
CPU variant	: 0x1
CPU part	: 0xb36
CPU revision	: 2

Hardware	: trout
Revision	: 0080
Serial	: 0000000000000000
# echo 768000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# cat /proc/cpuinfo
Processor	: ARMv6-compatible processor rev 2 (v6l)
BogoMIPS	: 766.77
Features	: swp half thumb fastmult edsp java
CPU implementer	: 0x41
CPU architecture: 6TEJ
CPU variant	: 0x1
CPU part	: 0xb36
CPU revision	: 2

Hardware	: trout
Revision	: 0080
Serial	: 0000000000000000

It reboot immediately following the cpuinfo but looks like it did scale up to 768000

Phone is fine after the reboot and back to default min max freq.

Before trying to toy around with different AHB clock dividers I should probably work out getting a good kernel to compile first, unless cyanogen has some spare time and feels like taking a look at this. I know I won't have any spare time in the next few days.
[G1 Android Development] Nesli:
Amazing!!

Nice to see 766 in cpuinfo :D What do you think, was the reboot caused by cpu failure or "something wrong" in kernel?

If I understand well, we must modify kernel, and we cant easily install app to overclock..
[G1 Android Development] :
at least it works now you just have to find a way to keep it working :D good luck and if you need any testing done just pm me ;)
[G1 Android Development] Gimpeh:
I imagine this could be done on a HTC Magic aswell.
[G1 Android Development] crazybyte:
Fresh news http://www.nuerom.com/BlogEngine/post/2009/09/10/Why-we-cane28099t-do-7e600MHz-yet.aspx

nuerom has an account on xda-developers, it should read this topic!

We are very close!!
[G1 Android Development] ivanmmj:
Did you have it running on battery or plugged in? It might not be getting enough power...
[G1 Android Development] Muse.Invincible:
any more info to come out of this?
[G1 Android Development] superg05:
this was an interesting read
[G1 Android Development] daproy:
Recompiled with cyanogen's latest source from github branch cm-donut-4.1 and everything runs just like cyanogen's release.

Tried to overclock to 768000 like i did before but it results in the phone freezing. I have to pull the battery to bring it back. Looks like the MSM7200 doesn't like this much speed nueOverClockTest. I also tried while in airplane mode with the same lockup. I guess disabling the radio doesn't help like it did here. All the tests were done on USB power.

Keeping my eye on whether we can get a more stable overclock setting ~600MHz. I haven't played around with increasing the AHB bus clock yet by lowering the divider. Hoping I don't destroy my phone.
[G1 Android Development] coolbho3000:
daproy, I'm willing to test your compiled kernels on my G1, to see if there's any variance between different devices.
[G1 Android Development] javacody:
I'd be willing to test too, but I'm using Jac Ski kernels and not planning on switching anytime soon...
[G1 Android Development] carnegie0107:
Woah, this is really interesting. Crazy scary, but interesting. Not sure if I'm brave enough to test anything that would come out of this thread, but the geek in me is loving what I'm reading, so I have to give this thread a shameless BUMP!
[G1 Android Development] david1171:
I have 2 G1's and plan to buy a nexus one as soon as it is available to regulars schmoes like me, so I can casualty test a G1 for the cause.

might as well make it scream in its last days;)
[G1 Android Development] Ace42:
Can we get this restarted :)

This would be helpful for roms like hero.
[G1 Android Development] defconoi:
im in, hows the compiling going :D
[G1 Android Development] itsjefflol:
This is sick, if this works I'll probably start using Hero ROMs a lot more often
[G1 Android Development] coolbho3000:
I compiled one as well, but it acted like how daproy reported it, it simply froze upon attempting to scale up to 768MHz.
[G1 Android Development] Ace42:
Can you get her in the 600's?

Can you try any diff scales for the CPU?
[G1 Android Development] coolbho3000:
Uninteresting stuff like 352MHz (1056/3) work. Unfortunately the 600s is not possible because of the way the PLLs are set up (you can only do a frequency that multiplies into one of them, eg. 1056 or 768).
[G1 Android Development] Ace42:
Do you know why it freezes?

I know with GPU OC theres a limit to where you should go without getting artifacts.Maybe theres a bug with how the new freq is put into the kernel?
[G1 Android Development] Areyo:
Woooooow

I didn't know the G1 was capable of this
[G1 Android Development] CrazyEye:
Wait, could this up the voltage up to that high?

I thought it wasn't possible....

If this is true and you can get higher CPU scaling. Is there a way to unlock the second core, to my knowledge the G1 has a dual core and its locked to just one core of use.

I could be wrong but thats what I read up on.
[G1 Android Development] Ace42:
Nope your right...

Quote:

Qualcomm has announced that its dual-core MSM7201A chipset is powering the G1 from T-Mobile; the first Google Android powered mobile phone. The chipset features built-in 3D graphics, multi mode 3G support and more.

We should focus on having 2 cpus running @528! no need to get new phone when current one is dual-core! :D
[G1 Android Development] djluis48:
Actually, this is very interesting, altough it seems that is not possible, keep the good work guys XD
[G1 Android Development] CrazyEye:
Hmm.. I really want to try this out with a hero or even CM.

Dual core would be epic as hell to have, why didn't they unlock the other one?!

gahh

Stupid corporate world... I bet the next great phone is going to have the same processor as the G1 but be unlocked and runs a lot fast.
[G1 Android Development] Ace42:
Yeah the G1 would be close to the speed of Nexus or even the Droid!

I guess the battery life would greatly suffer from the cores being active.I bet a kernel could be made to reactivate the sleeping core that lies in the G1:p

Even if we cant get up to 768 atleast we'll have access to both cores @528 or@384.
[G1 Android Development] CrazyEye:
yeah, if someone compiles (hopefully Cyanogen) and has it running I'll have it set to scale from 128 to 700+ so when the screen is off it downscales.

If both cores are unlocked I would just leave it at stock cpu settings (since both cpus are working)

Having a dual core processor with one core locked is a waste of money.

Probably why G1 mobo's are super expensive.
[G1 Android Development] Ace42:
Maybe G1 has other hidden secrets that HTC locked away?
[G1 Android Development] JAguirre1231:
I'm thinking that Google and Htc secretly put in a secret combination. When buttons are pressed in the right order we will see the TRUE android, and it will help Google rule the world. Once they rule it all Android adopters will be spared, but the others will fall prey to Google's ad-based empire
[G1 Android Development] zapyourit:
Having a dual-core proc in the G1 would be amazing. According to http://pdadb.net/index.php?m=cpu&id=a7201a&c=qualcomm_msm7201a under Special Features, it lists an "ARM9 coprocessor" so maybe we have some hope of getting this to work. Any ideas on how to unlock the extra power? I know that the Phenom II x3 are triple-core with an unlockable fourth core through a bios function (ACC) but as far as I can tell, we only have the IPL and not a true bios. At this point, I get lost. Any more knowledgeable folks wanna take a stab?
[G1 Android Development] ivanmmj:
It's not a dual core in that sense. It's a coprocessor and it's already used by the system.
[G1 Android Development] CrazyEye:
either way, dual core or higher mhz. LETS GET IT DONE! haha
[G1 Android Development] sirocyl:
As far as it appears to me, the problem with overclocking is raw power. I'd need to disassemble the thing and test some things with it open to verify this, but its behavior matches this problem. The power circuit can't throughput enough to power the CPU at 768MHz, and thus the phone crashes as the CPU gets "poisoned" by the (relatively) low voltages. It happened to me once when I overclocked a PC CPU that drew too much power from the motherboard.

As for the dual-core situation, ivanmmj is correct. Your Dream's CPU/SoC has a main core, and a I/O style coprocessor that handles stuff like the framebuffer graphics, camera, 3D graphics, GSM and audio, etc. It reserves its own chunk of memory out of the G1's (10 of which we can reclaim by removing the non-framebuffer 3D/texture cache in the kernel). The CPU uses this I/O coprocessor constantly, even when you don't realize it. Without it, the main CPU would be tied up and wasting power, and it would constantly be slow, freeze up, and even crash. Another reason for this coprocessor is security - as it is indeed locked in ways that some commands (such as SIM lock status, NAND partitioning, bootloader config) need to be specially privileged, and the SPL acts almost like a "hypervisor", controlling access to it and initializing the main processor.

If anyone is familiar with console modding, it's quite similar to the Wii's "Hollywood/Starlet", the PS2's "Emotion Engine/IOP", the PS3's "Cell/SPEs" and so forth. It has a main processor, but it initializes and controls the device with a coprocessor.

If I'm wrong, correct me, but I've had this G1 for a year, and several WinMo devices before it (WM5 era, mostly - WM6 on my Wizard), and I've tried pushing them to every limit imaginable - twice at the cost of the device itself.
[G1 Android Development] defconoi:
I dont know.. It seems people have already overclocked it:

http://xdaforums.com/showthread.php?t=557445&page=2

And here:

http://www.nuerom.com/BlogEngine/post/2009/09/08/Yet-more-notes-on-overclocking.aspx