Related
Hi Universal cracks,
i got a Qtek device which seems totally bricked.
The history of the device is unknown, so my investigation is getting deeper and deeper.
On gathering all information together it seems that the IPL and maybe also the SPL is damaged and cannot be easily revovered, because the bootmenu is not reachable in any way (believe me, i read everything about recovering intensely ).
That's why i'm looking for a general way to recover bricked devices using JTAG.
The idea is the following:
1. Access the device via jtag
2. Setup ram according to the setting used in wince or linux kernel
3. Rewrite IPL (it is yet unknown how to do it!)
4. Load SPL as executable binary into RAM using JTAG
5. Start the SPL from RAM
6. With SPL running from RAM Re-format the DOC reinstall SPL into DOC
Restart
That's it!
To resume my efforts so far i may report:
1. JTAG connection established (using OpenOCD or OCD Commander)
2. Init SDRAM (using intel PXA270 development kit setup)
3. Write a file to SDRAM and start it
4. Made a dump of IPL and SPL (using haret)
What did not work???
1. Access mDOC G3 in normal mode via JTAG (seems to stick in reset mode)...
2. Rewrite IPL using JTAG...
3. Start the SPL successful from SDRAM base address....
What do you think specialists!
Anyone willing to help?
Cheers,
scholbert
Hello Scholbert,
Sorry I couldn't help you out on this matter. But When I read your post I thought that you gone deeper than me in this technically.
So can Please go though my problem http://forum.xda-developers.com/showthread.php?t=353063 & help me out to solve WHITE SCREEN Problem?
Thanks in Advance.
bootloader
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Please could you post the patched version of openwince jtag?
Hi roglio,
roglio said:
Hi scholbert, it couldn't be enough to simply rewrite the bootloader?
Click to expand...
Click to collapse
Maybe you're right , restoring the uni via JTAG could be mission impossible (at least the way described in my starting post).
As far as i got to know from various postings, the bootloader itself does some security checks during runtime (password checking, CRC checking ...).
It could require some real awful hacks, to start the SPL from RAM with an external debugger.
Please could you post the patched version of openwince jtag?
Click to expand...
Click to collapse
I made a lot experiments on other platforms using the openwince jtag.
In this case i used the famous OpenOCD:
http://openfacts.berlios.de/index-en.phtml?title=Building_OpenOCD
There's PXA270 support out of the box!
You have to download the sources from their SVN-repository .
Anyway i'll have a look on my workstation in a few days, what could be of interest for the geeks out there.
Regards,
scholbert
Geek inside
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update. If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
I'll post any further step ahead.
Thanks.
roglio
Hi again,
roglio said:
Hi scholbert, all bricked universal are broken because the bootloader was wrongly updated or overwritten with a bad update.
Click to expand...
Click to collapse
this seemed to be happened to my device too. With single stepping starting at address 0x0 there's an error after some instructions. So it seems there's wrong assembler code in the IPL section already.
If we look for a fresh bootloader, the right starting address and wrote it back we've fixed the major problem. Recover a universal starting from this point is already well documented...
Click to expand...
Click to collapse
That's the theory .
Tomorrow I'll download OpenOCD and try to compile it on cygwin to start doing some experiments.
Click to expand...
Click to collapse
Good luck for this action! I did compile it on a debian linux system.
I lack of some informations anyway: the most important is the address where to put the correct bootloader...
Click to expand...
Click to collapse
Let's assume we got a working device .
As far as i know, this is what happens after coldboot (comments welcome):
1. DOC is in reset mode, processor jumps to address 0x0 and excutes IPL
2. IPL initializes RAM, switches DOC to normal mode and copies SPL to RAM
3. further details of IPL functions unknown
4. leaving IPL, jump to physical address 0xa0000000
5. execute SPL ....
The problem is, that at this point various system checks are following.
If something goes wrong before we good USB serial connection or bootloader screen. The processor simply could stop at any instruction and we won't know why .
I'll post any further step ahead.
Thanks.
roglio
Click to expand...
Click to collapse
Good luck for your next steps!!!
Maybe, we may draw some attention with this little discussion. It would be nice to get things rollin' and someday there'll be hope for all those bricked devices around .
P.S.:
I already made bootloader dumps. See attachments!
IPL and IPL2 got the same content but they were dumped on different physical addresses. SPL was dumped from RAM. Of course these files were taken from a working device.
scholbert
Hi, after your description of the boot process I'm not so optimist anymore...
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Just a doubt: which configuration file are you using?
Does you have already configured also the flash banks?
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
This give me at least a hope...
Hi roglio,
Anyway, I've just finished to compile OpenOCD under cygwin, without any major problem.
Click to expand...
Click to collapse
Great!!!
Just a doubt: which configuration file are you using?
Click to expand...
Click to collapse
I will post the configuration file as soon as possible (it's on my linux machine at work ).
Does you have already configured also the flash banks?
Click to expand...
Click to collapse
No, only the PXA270 chip select for the DOC device was set up. These NAND flashes need special initialisation to switch form reset mode to normal mode to be programmed or to read the filesystem.
This process was not yet successful using JTAG .
I share your doubts about what's happen after SPL execution... IMHO anyway we should give a chance to a complete reflash: fully dump a working device and after wrote it back to a bricked uni just to see what happen.
Click to expand...
Click to collapse
If we are able to access the DOC device in a proper way, this may work.
At least there are professionel programmers on the market, that are able to reprogram these devices using the JTAG interface. But these are very, very expensive .
Some time ago, I've accidentally overwritten the bootloader of a Toshiba e740 PDA (very nice device indeed). After using a proprietary jtag sw/hw I've resurrected it simply writing the bootloader back in place.
Click to expand...
Click to collapse
Yes basically this also possible for the uni, but this damn#?=% DOC device is very hard to handle. There's also no linux device driver for these devices yet.
Great work anyway!!!
This give me at least a hope...
Click to expand...
Click to collapse
Our hope should never die .
Best regards,
scholbert
Googling
Hi, scholbert! Today I was googling around and I've found some interesting informations about mDOCs... These special flashrom are internally handled as NAND flash but with the cpu (when used to eXecute In Place XIP) are handled as NOR flash chips. I haven't still found useful information to understand how this could be useful for our goal.
Another interesting information about mDOCs is that exists some pc software that permit to flash them via jtag but are part of very expensive development packages!
Anyway mDOCs are handled by linux! Basically it is possible to patch the linux kernel to handle them via trueffs. I'll be more detailed tomorrow, but my first impression is that these information about linux drivers for mDOC family aren't useful for our project...
Does you have retrieved the conf file for openocd?
Hi roglio,
that's nice information. I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Unfortunately, there's no source code of the low level routines to access this device. If someone would share m-systems BDK for the G3, you're welcome!
Does you have retrieved the conf file for openocd?
Click to expand...
Click to collapse
Yes, but i realized that i used a slightly modified one of the standard package (no SDRAM init, nothing but access PXA270).
You will find it attached!
My efforts with the uni using OpenOCD get stuck at a point, because i only got a very simple JTAG hardware. To use it as a debugger you also need to have influence on the systems reset.
That's why i decided to used some Macraigor stuff to get nice hardware debugger for accessing the universal hardware with OCD Commander.
Obviously both systems are very similar.
OpenOCD is completely GPL, so this should be first choice in the end!!!
You will also find the OCD Commander config file (htc-uni.zip) attached.
This could be the base for an OpenOCD script (very similar stuff).
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
I nearly forgot to mention, that you'll need to update the description for the stepping of PXA270 in the OpenOCD source code. If i remember correctly, the C5 is missing. Without it the PXA is not recognized correctly. I will post the updated file tomorrow.
Stay tuned!!!
scholbert
scholbert said:
I also gathered together anything about the mDOC series i could find, all over the planet. If you need more details
Click to expand...
Click to collapse
Yes! Post it! Thank you! (or send them to rapidshare or similar).
scholbert said:
Just an additional information:
I successfully disassembled the IPL . At the moment i'm in the process of clearing up, how the basic init process is working!
Click to expand...
Click to collapse
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Which tools are you using to decompile IPL?
Hi,
Yes! Post it! Thank you! (or send them to rapidshare or similar).
Click to expand...
Click to collapse
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
A weird idea... What do you think about relocate and then recompile IPL and run it from SDRAM?
You should remove and/or modify IPL routines related to SDRAM init anyway!
Click to expand...
Click to collapse
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Relocate and compile would be nice too, but more work .
Which tools are you using to decompile IPL?
Click to expand...
Click to collapse
Someone in the forum pointed out to use radare. This was the starting point for further investigation.
At least radare uses objdump for disassembly.
So i decided to use the tools itself.
Here's a short howto:
How to convert raw arm binaries to elf and disassemble the code:
Although not every ARM code is compiled with the famous GCC (e.g. wince binaries) you may use some tools
of the GCC to convert raw binary code that is executable on ARM platforms.
Make sure that you made a real memdump or read out pure flash files from a known offset (reset entry points, direct jumps into code, etc).
In other words use pure binaries!!!
Otherwise this method won't work. It is nice to disassemble bootloader code for example.
Image files with filesystem information won't work, either!!
You'll need a working ARM cross compiler in this example the arm-none-eabi gcc version 4.2 from codesourcery was used.
1. first you have to build an elf-binary for ARM without offset (assumed 0x0) from the raw binary.
arm-none-eabi-objcopy -I binary -B arm -O elf32-littlearm ipl_0x0-0x800.bin ipl_0x0-0x800.elf
2. second simply disassemble the elf-binary!
arm-none-eabi-objdump -D ipl_0x0-0x800.elf > ipl_0x0-0x800.asm
That's it!
scholbert
Click to expand...
Click to collapse
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Regards,
scholbert
scholbert said:
Hi,
I will somehow. Maybe i'll put on my website or post it here!
Very busy at the moment .
Click to expand...
Click to collapse
Ok... I'll look forward for these documents! Thanks!
scholbert said:
The first attempt will be to enhance the JTAG config file with all that stuff i already found out, e.g. setup all GPIO, alternate functions .....
Click to expand...
Click to collapse
Great!
After my jtag will be fully functional, I'll try to do some experiments running IPL from memory...
scholbert said:
Of course you need some skills to point out how assembler code is organized and you'll have to find out where ASCII strings are stored. If you don't check this everything looks like instruction code!
Click to expand...
Click to collapse
I'm a little rusty... but I'll try!
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Cheers,
roglio
Anyway I found a very great tool for disassembling arm code: IDA Pro v5.2
It is awesome.
Click to expand...
Click to collapse
Yeah i know. I once worked with the eval version.
Very nice piece of software, but no freeware.
Good luck for your experiments!!!
scholbert
IPL disassembled
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Hi,
roglio said:
Hi scholbert!
Attached you will find the IPL asm I've disassembled with IDA.
I hope it could be of some usefulness!
Cheers,
roglio
Click to expand...
Click to collapse
Great work!
Here's mine. As you will see it's very equal (at least it should be ).
I made some comments already, but it's not finished yet.
The structure can be seen already. It is soon possible to reconstruct the whole asm code and compile it .
scholbert
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
@scholbert: wow you're always at least a step ahead!!!
Great!
@mo3ulla: hi! yes it is worth the effort because the chance to have skills to build a jtag connector is greater than have skills (and tools) to reball a bga chip (and program it!).
With jtag interface and a relocated IPL we can resurrect bricked uni simply loading it in ram and running. Then reflash the pda with a simple usb cable
Hi,
roglio thanks for the credits .
But at least this no competition, it's really great that someone took a look at this posting and started to discuss.
This goes out to you roglio .
mo3ulla said:
is it all necessary ?? more easy way in desoldering flash ... and program it or change to flash from dead device
Click to expand...
Click to collapse
When i started this topic, i thought about a way to de-brick some uni's without touching the hardware. So roglio is absolutely right!
Once tried reballing at home???
At least the major point is:
Why touch the hardware, when it's a software problem?
Obviously no one got a programmer for mDOC devices!
If the universal would have NOR flash all things would be less complicated.
So what we are doing here, is to replace a 10.000$ programmer.
These professional devices do the same in the end, they use software algorithm to programm these NAND flashes.
The SPL uses the same software parts to reprogram G3 NAND flashes, but to start SPL (get into bootloader menu), IPL is needed. On a heavily bricked device these parts are damaged.
If we setup the device like IPL does or recompile IPL to run from RAM using JTAG, it could be possible to start SPL and get into bootloader menu.
The rest is already described here ....
Regards,
scholbert
O.K., here's dump from the bricked uni.
The screenshot shows the IPL section. It seems to be IPL version 2.36 which is for devices with a G4 NAND.
Mine is a G3, so this is the reason why it got bricked.
Someone updated the bootloader with a wrong version .
I enhanced the config file for the JTAG debugger with the settings i found out by disassembling IPL version 0.36 (G3 devices).
But unfortunately no success. The SDRAM is not accessible .
Without SDRAM initialised, i am not able do download SPL to the platform.
grumbl....
I'll have to check all settings again.
Especially the SDRAM setup...........
No time for that at the moment.
Anyone who'd like to join our experiments????
Cheers,
scholbert
Hi All
I have made a couple of posts over the last few days reporting noes on my attempts to upgrade my Elf.
Now what I am about to write is probably not news to most or at some of you, but I thought I would note here anyway.
My Elf was (still is) a UK Orange locked fone. In an attempt to remove the CID lock and reload a better unbranded version of ROM, I ended up stuffing it to the extent where could not load it, from SD or link. It was stuck on Bootloader with IPL 2.21.0002 and SPL 2.28.0000. Nothing would budge it.
I could attached with MTTY and snoopy and I have documented how to get the drivers to work using Windows 7 (for most same for Vista). I could see it was still blocked and security at FF. Device info tool confirmed. Another unblock tool failed as well. I attempted to use Qmat to attached with the report that the registry needed to be changed for the Security Policies. Fine I thought, can do that so got the mobiel registry tool to do so.
I wish to note here about the tools: They work great, as far as I can tell (and I have been a tech in IT for too many years to tell - repairing to component level for years in the past! - so have some idea of what I am doing).
So what's my point besides beware and be careful:
Well, the problem turned out to be that the security policies set here for the backup
@echo HTC Elf/Elfin Automatic Backup Utility
@echo.
@echo Script by dsixda (xda-developers.com)
@echo Thanks to itsme for the tools
@echo =======================================
:start
@echo.
@echo Removing application lock on device
@prapi -s HKLM\Security\Policies\Policies "00001001" integer 1
@prapi -s HKLM\Security\Policies\Policies "0000101a" integer 1
work fine, however, on my phone they are stuck on Integer 2, which suggest, (considering my problem) a security LOCKOUT, so one can go no further as the registry change commands did not work. I could not even make the Gold SD!!!!
I took the phone to HTC in Milton Keynes Care centre here in the UK, where they kindly replaced my motherboard, at a cost, which they say had blown...I think what they really meant was that it had a complete security LOCKOUT and hence only fix was a replacement!!!! Which I did .. could not waste the phone.
I would be very interested to read any feedback/comments no matter what type as to views on the above.
Hope this helps find a solution, if any for others, and save them money
ciao
If the motherboard is blown, you couldn't start the elf.
jeremy89632 said:
If the motherboard is blown, you couldn't start the elf.
Click to expand...
Click to collapse
Jeremy
I agree, hence the qualifying note after... without suggesting any skullduggery!
And this concerns me.. I know that a blown mb means a complete dead unit... And the security policy issue is a windows setting, not a boot setting, so I am concerned that I was charged for a new mb for nothing and that the ROM was reloaded by other means!
However, it is more likely that the board was not totally stuffed but the link ROM/RAM was stuffed somehow. I have never seem a s/f load blow a hardware conx, but there is always a 1st
Oh, you are using Windows 7?
Pretty surprised, Im using too.
But I didnt know drivers was supported so well.
Hi,
My name is Wen from WMPoweruser and we recently decided to take up your case and try our best and get a ROM for the TG01. At the current status the chances of the TG01 getting a cooked ROM is currently low because the lack of a HardSPL, but I got word of another method of flashing.
EDIT: I3v5y is working on it, and soon enough we will have enough for his test device, and the ROM status is currently unknown, just doing some research as to if we can move some things around and tweak it to get a result. He is a professional at that.
Total $250.... We have enough for a UK TG01
Status
Unlocker/Flasher:Searching for a method of unlocking.. with the help of some people and Flar
ROM:We have more than enough cooks for that sadly only one in the UKThanks,
Wen
Hi wen, i'm very glad to hear this news you are giving us.
TG01 users will be very excited and happy when the custom works on the TG01
i don't mind donating to help the TG01 be able to have custom roms on it.
Also is it possible to hardspl the TG01 like you can hardspl the xperia x1 (my old phone)
Thanks, sam
sagam12 said:
Hi wen, i'm very glad to hear this news you are giving us.
TG01 users will be very excited and happy when the custom works on the TG01
i don't mind donating to help the TG01 be able to have custom roms on it.
Also is it possible to hardspl the TG01 like you can hardspl the xperia x1 (my old phone)
Thanks, sam
Click to expand...
Click to collapse
Thats is what I am trying to find, and is what our biggest problem is
There is a method to push the rom flashing using the pins beside sim card holder.
Read here:
FINALLY!! there is a way to ressurect dead TG01's after flashing:
1. Format SD card (FAT32)
2. Copy SDDL+.exe(not sure if it's needed)
3. Copy whole PRG folder with desired .tsw update (i think best will be the one dedicated to your language version
4. under sim card slot you'll find black plastic sticker (little bit hard to remove)
5. after removal of plastic sticker there are 3 pins
6. put battery back turn phone on
7. shorten 1 and 3 pin with cable and push reset button
8. white screen should come up and bootloader will load rom from your SD
9. Voila! Your TG01 is alive
tested by 2 spanish TG01 users and by polish TG01 user.
In case I'm not responsible for any damage you make by trying this method.
Hi Wen,
Custom ROM can be possible.The rom is decrypted by cotulla, but the resultant .nb0 has a wiered structure.It is still has some extra bytes, which has a weired parition table.Working on it as how to normalise.Hex copy paste also doesnt work properly.If this is done, then I am risking my tg01 for custom rom development.
Wen(WM) said:
Hi,
My name is Wen from WMPoweruser and we recently decided to take up your case and try our best and get a ROM for the TG01. At the current status the chances of the TG01 getting a cooked ROM is currently low because the lack of a HardSPL, but I got word of another method of flashing.
I want to get all the current information about ROMz for the TG01 like HardSPL status, Cooks, Dumps and anything else that could help us get this ROM started and cooking. We currently have 8 cooks at hand and if we can get some help getting a HardSPL or anything going, we can have a good ROM released fast from someone like NRG, Shadowline, Ark, Captain Throwback or any of our good cooks, but they do need a test device. So if anyone wants to donate let me know so I will add a Cotton, but I am sure no one does.
Thanks, and I hope we get cooking soon
Wen
Click to expand...
Click to collapse
Hi Wen,
I think there is no need to create HardSPL for TG01. Protection of TG01 is half-broken.
First, we've got program called ".TSW Tools", that helps to decrypt encoded .TSW image file. You can get the software here: http://cotulla.pp.ru/Misc.html
Second, when we have .bin image, we need to decrypt it.
@Globalbus form forum.pdaclub.pl told us something about the .bin:
1. The block of image that could be intresting begins at 0x50F4000 and goes to the end.
2. MBR tells us the following arrangement: ULDR, XIP, IMGFS, FAT (with initiation sector)
3. Checksums:
Every 0x200 bites some trash (0xFF)
Every 0x200 bites some checksum (CRC32?)
And NAND control blocks.
I translated it the best i could. I hope, that I helped you.
Come on, everybody with expert knowledge get it on now, i will donate..
get this started
RE
kosiek said:
Hi Wen,
I think there is no need to create HardSPL for TG01. Protection of TG01 is half-broken.
First, we've got program called ".TSW Tools", that helps to decrypt encoded .TSW image file. You can get the software here: ...
Second, when we have .bin image, we need to decrypt it.
@Globalbus form forum.pdaclub.pl told us something about the .bin:
1. The block of image that could be intresting begins at 0x50F4000 and goes to the end.
2. MBR tells us the following arrangement: ULDR, XIP, IMGFS, FAT (with initiation sector)
3. Checksums:
Every 0x200 bites some trash (0xFF)
Every 0x200 bites some checksum (CRC32?)
And NAND control blocks.
I translated it the best i could. I hope, that I helped you.
Click to expand...
Click to collapse
WOW this sounds good even though i don't understand half of it lol
also, wen i've donated $5 hope it helps, only small but i don't even work so sorry can't be more than $5
Good luck!
So here is a resume of all work made by TG01 user or not:
1- Dump OEM/SYS TG01 (by ABM30) =
http://forum.xda-developers.com/showpost.php?p=5500122&postcount=253
2- Tool to extract file from .TSW (by cotulla) =
http://cotulla.pp.ru/Misc.html
Quote:
we can decode tsw files to bin but TG01 bin differs little bit from standard bin images here is what an experienced cook said:
The important to us part of image starts 0x50F4000 till endof
MBR looks:
-ULDR, XIP, IMGFS, FAT (with initiation fragment)
Checksums:
every 0x200 bajts (0xFF)
every 0x200 bajts checksum (CRC32?)
And standard NAND control blocks.
3- Force bootloader to flash any official rom after wrong flash (by nico101)=
http://forum.xda-developers.com/showpost.php?p=5487567&postcount=245
i have my own sim unlocked TG01 that i am also will to donate for testing purposes if needs be.
but i would like it back and hopefully not bricked either, but we apparently have debricking instructions!!
come on cooks lets get cooking!!!
And the ball is rolling Will be donating as soon as payday hits
I can provide Wm6.5 O2 21856 DE dump and rare WM 6.1 PL (wasn't relased officially it's from show off phone for polish orange
We have I3v5y working on the ROM and we he says it should not be too hard, so lets just hope and he is going to need a test device
Very good news.
Thank you so much!
Fantastic news Thankyou very much!!!!!
well so far I have 20 and the device is 450 and I guess if we are close, I will take over the rest, also the flash method is the one that you guys said, so ya.
Wen(WM) said:
We have I3v5y working on the ROM and we he says it should not be too hard, so lets just hope and he is going to need a test device
Click to expand...
Click to collapse
Thats Good News
so good
It is a fantastic news really and thx to Wen, I hope the ROM will be release very soon.
And my device is a japanese version, hoping the unlock method.
Wen(WM) said:
well so far I have 20 and the device is 450 and I guess if we are close, I will take over the rest, also the flash method is the one that you guys said, so ya.
Click to expand...
Click to collapse
Don't panic it will come.
I plan to pay 50e but i forget my account paypal since longtime.
I just need to active it.
I have $110 so far, so 1/3 of the way there.
The SMT5600 is app unlocked and, I think, Super CID (via lokiwiz02_173 but how verify?) but no ROM changes as of yet as I want to make a backup of the original ROM before proceeding further.
After problems getting a term program to work (now using nueTTYConsole on Vista) I am able to get what appear to be complete ROM backups.
Procedure summary:
WinHex zero fill 64MB SD
USB bootloader SMT5600 with 64MB SD
r2sd all (via nueTTYConsole-12-v0.1-spackr)
SD back to PC [no to format query]
psdread E: 0 31328768 ipl.bin (using itsutl050119)
Status messages from the r2sd all command appear to be good and complete but no two backups, using the exact same procedure, are ever identical when binary compared with WinMerge. Size is, of course, the same but WinMerge always reports 'two' differences in what seems to be the same general area of the images: The first is very near the front of the image (WinMerge reports as 'lines', line 3) and the other at the very tail end.
Is that normal (maybe because TIME, or some other dynamic variable, changes or scratch storage?), is there a better backup procedure, and how can I verify the backups are good before I flash a new one and forever lose the original?
Thanks in advance for any enlightenment offered.
To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.
tobbbie said:
To check if it works - just restore the backups before doing anything else.
Follow the whole procedure (including psdread and - after reformatting the card - psdwrite again) to restore your device via the card. As a first try leave out the device external activities and restore immediately afterwards from the card just written.
Click to expand...
Click to collapse
Thanks for the reply
Yes, I thought about doing a test restore, but, considering the problems I'd already had, wasn't sure if it might do something like not mention there being a 'problem' till it was half way through, leaving me with a scrambled ROM.
I take it you're saying it'll checksum first and no even start if things don't look good?
tobbbie said:
For me it works well (on the SDA 2 - where no official update exists, a Hurricane device - but this generic handling is identical afaik) and the difference in the backups are normal.
Mind that the size of the read/write to card includes the bootsector, so don't miss the last 512 bytes. As far I remember there were two different size readings with two methods to verify the image size. The r2sd size is smaller than the size of bytes different to null on card.
Click to expand...
Click to collapse
Hmm. I saw the confusion about SMT5600 image size but I'm not sure what you're saying here about the bootsector and "different to null."
Speaking of which, what would be wrong with just making a 64M save and, ok, you've save a pile of extraneous 0's along with it but, so what? Might be irritating if I were putting it on rapidshare but for a personal backup is there any down side to it?
tobbbie said:
To check for SuperCID enter "info 2" in the terminalprogram, it should report HTCSuperCID at the end.
Click to expand...
Click to collapse
Thanks. Good to know.
Something apparently went wrong somewhere because I didn't get that report but I'll try again.
The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
I think there is no risk attached to the procedure, go ahead!
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.
tobbbie said:
The r2sd is a command that HTC has implemented in the SPL (Secondary Program Loader). I am not aware of checksums or other safety measures - it will as I noticed following the procedure detect if there is an image on the card, which type of image and if you want to restore.
Click to expand...
Click to collapse
Well, I am certainly no expert on this thing but r2sd spits out a wealth of information, including checksums, and I was sort of guessing based on what I'd do if I'd made it. Just that, if you're going to calculate them, it seems a shame to not use them. But, hey, I've seen stranger things done.
tobbbie said:
The difference in size is that r2sd reports one size "x" after the image was taken, but if you count the bytes until when the card shows the zeros you will notice that this offset on card is 512 bytes larger than the r2sd reported size. So when using psdread you have to take the larger size. Indeed it is no problem to write more to the file and restore more as well with psdwrite. The restore procedure in the SPL will anyway know how much to restore - it just needs to find ALL bytes, including the last 512
Click to expand...
Click to collapse
Oh, OK. I wasn't going by r2sd. I opened it up in WinHex, found the end of data, and compared that to the size mentioned on "Backup your Typhoon ROM - WinMo @ MoDaCo." The 'corrected' number there matched well enough.
But now that I think of it, I did that because I *did* look at r2sd and it seemed too small. So you've explained it. Good.
tobbbie said:
I think there is no risk attached to the procedure, go ahead!
Click to expand...
Click to collapse
How can there be no risk if it doesn't check anything?
tobbbie said:
The only danger is if something goes wrong with the IPL (Initial Program Loader) or SPL because they open the door to the device handling.
Click to expand...
Click to collapse
Oh, I think I see what you mean. You're suggesting that if I've cut the ROM image short then only that part will fail but the loader should still be good so I could recover by burning another (good) ROM image.
Well, perhaps, but that would mean I don't have a valid backup and couldn't make one since it would be trashed in the bad flash. Or so it seems to me.
tobbbie said:
Sadly you MUST deal with SPL to upgrade to WM5+ afaik, so be very sure to select the right IPL and SPL that matches your device HW (OMAP 730, 750 or 850) and intended OS Version. Also take care not to enter any command in the SPL except the ones you are supposed to enter - it may kill your device as well. Do never use "format all" or "doctest" - you have a brick then.
Click to expand...
Click to collapse
I was thinking of going straight to WM6.x per
karhoe.net/guide-upgrading-htc-feelertyphoonamadeus-to-windows-mobile-6-update-september-06-2008.html
which involves changing the loader first via Patched_RUU
Do you think going to WM5 first is a safer procedure?
I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...
tobbbie said:
I said I was not aware of any checking - but as I have not written the SPL, I simply do not know it. You are right that reporting stuff like this makes it highly probable that upon restore a check on the image should be done before restoring. Try it out, if you like
Click to expand...
Click to collapse
Hehe. Yeah.
I was sort of hoping someone else had already stepped off that cliff and could tell me what the ground was like before I dove in
tobbbie said:
WM5 or WM6 does not make a difference what the SPL is concerned. Afaik you have to use the same anyway. The device is tight in memory anyway, so don't expect miracles.
Go ahead, either dare it or leave it...
Click to expand...
Click to collapse
The primary aim was to get bluetooth a2dp but the incentive may have diminshed, depending on how another project works out.
Thanks again for the help.
I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.
tobbbie said:
I would not bet on A2DP - I have it in the Tornado and the CPU use is much higher due to additional compression on the BT interface. Player + BT overhead is getting to average above 80% CPU (depending no the settings, but for good quality is like this) - it will also drain your battery much faster.
The Typhoon, Hurricane and Tornado have identical good analog Audio capabilities (I measured them with RMAA - see www.rightmark.org) and make a perfect music player as they are.
If your device is SuperCID you can take any other Typhoon ROM - you must just be sure that r2sd will save your bootloader + OS if you want to go back to WM2k3. I have done this already on my Amadeus (and went back to WM2k3) and this can still serve as a nice musicplayer.
Click to expand...
Click to collapse
I admire people who can make these flash things work because it never does for me. I've now got an SMT5600 that will do nothing but display a rainbow boot screen and error out regardless of what ROM I try.
That's why I didn't try this till I had a new phone.
Hey that thread has a long history - what happened in the meantime?
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case.
What do the lines tell in the 3 color bars?
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.
tobbbie said:
Hey that thread has a long history - what happened in the meantime?
Click to expand...
Click to collapse
I put it on hold pending a new phone and other things cropped up.
Frankly, I had 2003 pretty well tricked out with SmartToolkit and gStart.
tobbbie said:
3 colour screen does not mean the device is dead yet. You still have a bootloader that works and this is the thing to start from in any case. What do the lines tell in the 3 color bars?
Click to expand...
Click to collapse
I swear it wasn't a troll but no sooner than I posted it wouldn't flash I managed a flash and I'm not sure why this worked when the others failed.
I was trying to verify the hard spl, getting info, etc. To make that easier I turned 'ui' on during boot and, just for chuckles expecting nothing, I tried flash again. You know, the definition of 'insanity'. Low and hold the dern thing flew.
As far as I know nothing was different other than 'ui' on. Same tools, same wm6.5 bin file, etc.
tobbbie said:
Did you already upload the changed SPL (I think it was 1.09) that allows to flash ROMs of WM5 or WM6 on that original WM2k3 device? If so, the you need to revert back to old SPL first before you can upload the original ROMs again.
Click to expand...
Click to collapse
You have no idea how helpful mentioning "1.09" is. The SPL flash program opines something like changing to v 5.000 but that number shows up no where and no where does it tell you to look for '1.09'. There are other confusions, like saying the existing device was 'Orlando' (I think it was), but I guess that's moot now.
Anyway, it's now running WM6.5 and I have a new toy to fiddle with inbetween playing with Android on my Tilt 2.
Thank you for the help.
Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.
tobbbie said:
Glad it worked now
The older (wm2k3) devices could only be updated with a binary transfer protocol (the .BIN file - which can be confused with other ".bin" in the scope of cooking in general). To enable the reception of the MTTY command "l" (for Load) and the execution of the related actions, the SPL must be in "UI" (User Interface) mode - this is the key for further flashing - and it must be mentioned in all such upgrade manuals. Also mind that other terminal programs (like TerraTerm) have not implemented that protocol. So only MTTY works for that purpose! As I am struggling currently with porting a Tornado ROM to the Hurricane I have come quite deep into that topic recently.
Click to expand...
Click to collapse
So I discovered after missing the little '0' in the instructions.
tobbbie said:
Are you having the WM65 from aleut now on the device? I think it is very tight on RAM now, so what are the memory key-data from settings->about after a reboot? You should repeat that with the standard home screen (Windows default) which is less memory greedy.
Click to expand...
Click to collapse
Yes, I originally flashed Aleuts 6.5 but I've since reflashed with his 6.1.
tobbbie said:
The way back to WM2k3 is not so easy as you must replace the SPL with the original one first before you can get back to the original OS. Whenever you mess with SPL it is a potentially dangerous action as failure doing that right will result in a bricked device.
Click to expand...
Click to collapse
Yep, flashing SPL is the most vulnerable but I don't think I'll be going back to 2003. Although, I might try WM5 if that has more free memory.
With most things I plan on using installed there's 8.5Meg free at boot and while that sounds laughable by today's standards there's only 22Meg total for a more impressive sounding '38% free' Although, as soon as you touch the thing almost half of that is gone.
Hurrah! this has been fixed WOO!.
see here.
well done guys, you have made me a happy g2 owner again!!
Hi Everyone,
i figured we might need to clean up the
http://forum.xda-developers.com/showthread.php?t=805024
conversation.
as i see it, there are 2 issues
1. people receive an unlock code, the phone accepts it but then it cannot find any network
2. people receive an unlock code, have troubles entering the code but eventually get it in ok.
please do not post anything "setting" related - apn's, bands etc as this has been tried and shown not to work (yet)
it might be helpful if people who have issue number 1 could post some answers to some questions.
as i am not at all smart enough to work out what we need to know from these people, id appreciate it if those in the know could pm me what they think could be useful, and ill make a template for people to follow
troubleshooting template
----
----
----
----
Current Theories: (please PM me if i have anything wrong here or if i need to add details.)
-------------
Theory #1
Ghul99: the code is accepted, but the phone is still locked?
http://forum.xda-developers.com/show...&postcount=121
------------
interesting information
this seems to support theory #1
1. i unlocked phone - code entered successfully, and i was no longer prompted to enter an unlock code
2. i perm-rooted my phone - all went to plan
3. i put the vision rom on my phone (http://forum.xda-developers.com/showthread.php?t=834450) loaded ok
4. i put a sim in my phone and now i am prompted for an unlock code.
5. i tried to re-enter my code but it would not accept it (it is the same code from step 1)
Nice idea for taking the initiative to clean up the thread which was getting excessilely long!
I'm hoping we can see some progress in a few days as I'm really missing being able to get any cell reception on a MOBILE PHONE!?
Regards.
I will summerize my knowledge later but one thing upfront.
IntuativNipple posted today in IRC that he found the way to get real S-OFF which would also allow SIM-unlock without code.
So there is hope for a solution, but keep your patience.
Sent from my T-Mobile G2 using XDA App
guhl99 said:
I will summerize my knowledge later but one thing upfront.
IntuativNipple posted today in IRC that he found the way to get real S-OFF which would also allow SIM-unlock without code.
So there is hope for a solution, but keep your patience.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
That's really exciting.
Thanks for bring up the good news!
Sent from my T-Mobile G2 using XDA App
guhl99 said:
I will summerize my knowledge later but one thing upfront.
IntuativNipple posted today in IRC that he found the way to get real S-OFF which would also allow SIM-unlock without code.
So there is hope for a solution, but keep your patience.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
Just to help guhl and catch up with some unnecessary posts.
Common solutions like Reboot, different sims to try, Hard reset, flash stock ROM or trigger the unlock window to reenter the code doesn't work
Summary of my knowledge so far
For case 1 which was the original problem my theory is the following.
Cause:
Because of problems with the write procedure to the emmc memory the MCCMCN to which the phone is locked did not get cleared but set to an arbitrary value in my case "C3AB".
The CID value is still the same as it used to be (and also in case of a successful unlock would stay the same) which is "T-MOB010". The CID is a 8 character string and the case where all characters are the same (i.e. "11111111") is called Super-CID.
It is of no relevance if you use or used the hardware or software keys, T-Mobile or third party sources. The only reason where it would be your fault is if you pulled the battery!
The unlock-code that we possess (regardless if official or from a different source) is not valid to unlock the phone from this value "C3AB". If one tries again (directly with the modem, using my modified libril.so or a different ROM) the lock counter will increase.
Potential ways to repair this state:
1. Give it back to T-Mobile if you can In my opinion this is a clear warranty case
2. Find someone who has the MegaSIM and the HTC-diag software.
This will definitely work but it is going to be hard to find someone because the SIM is rare and very new.
3. Wait until (or help achieving) the so called "real S-OFF" state of the phone (when also the radio has security disabled) is reached.
When this is achieved one can disable the SIM-lock without any code.
There are still some very good developers after this goal even if for different reasons.
Which information could help us:
1. The output of the following AT-Command sequence from successful and unsuccessful unlocks
Code:
ATE1
ATV1
[email protected]?
[email protected]?AA
[email protected]?40
[email protected]?80
I will try to write a HowTo later for Windows.
For linux see the following posting from the old thread (http://forum.xda-developers.com/showpost.php?p=8750299&postcount=121)
2. The next thing that would help is a logcat from the first unlock process itself.
Howto:
Start the first logcat using the USB-cable and adb before you boot the phone with the foreign SIM.
Code:
adb logcat -b radio > lc_unlock.txt
leave the logcat running and complete the unlock procedure till the phone reboots (the logcat will end automatically)
As soon as the first logcat exits start a new one using:
Code:
adb logcat -b radio > lc_after_unlock.txt
leave it running for 1 minute and then stop it using <Ctrl>-C
3. The next thing that really would help is that you do not post anything in this thread (use the old one instead) that has to do with:
- the APN
- trying another SIM (you would be very lucky if you had one that fits the arbitrary SIMlock)
- reboot, factory reset, use a stock or non stock firmware
- use the hw/sw-keyboard, wait for the right outside temperature or other esoteric procedures
Finally I would like to ask moodecow to edit his original posting and incorporate or link everything that he finds important or helpful in his posting so that it will stay an top.
That is some very exciting news, thank you for the update!
One quick question, when we achieve radio-s off it esssentially would mean everyone could unlock their phones for free?
Thanks.
Sent from my T-Mobile G2 using XDA App
I have 2 ideas, which can help:
1. For people before unlock - maybe performing S-off before unlock will help.\
2. For people after unlock: in bootloader there is "SIMLOCK" option. When you open it, it shows file not found etc. As I think, it can be used to simlock phone for operator, whose numbers are in some file. There is my solution - find what that files are in phone's source code or by any other method, then put them in right place, enter numbers of operator you want to use, open that "SIMLOCK" and lock phone to your network. I don't know if it will work, but it makes some sense.
ms93 said:
I have 2 ideas, which can help:
1. For people before unlock - maybe performing S-off before unlock will help.\
2. For people after unlock: in bootloader there is "SIMLOCK" option. When you open it, it shows file not found etc. As I think, it can be used to simlock phone for operator, whose numbers are in some file. There is my solution - find what that files are in phone's source code or by any other method, then put them in right place, enter numbers of operator you want to use, open that "SIMLOCK" and lock phone to your network. I don't know if it will work, but it makes some sense.
Click to expand...
Click to collapse
Your first idea sounds reasonable and I would support it.
Your second idea is something that is worked on, but you do not only need the correct file (which is actually called DMCID.dat) but there also has to be some "magic number" (like on a gold card) on the micro-sd card.
an important piece of info to carryover from other thread:
1- No APNs are listed
2- if you try to define one, it doesnt save
No APNs being listed is related to the rom more or less, not the issue we're having.
APN is software issue, correct me if I'm wrong so either way it shouldn't pose as an issue to us.
im saying its a symptom that seems to go along with the problem in the title of this thread, so, worth noting.
ie: i think everyone who has the post-unlock no-connection problem, cannot save APNs. all others can.
if you are a counterexample please say so. that would help.
guhl99 said:
For case 1 which was the original problem my theory is the following.
Cause:
Because of problems with the write procedure to the emmc memory the MCCMCN to which the phone is locked did not get cleared but set to an arbitrary value in my case "C3AB".
The CID value is still the same as it used to be (and also in case of a successful unlock would stay the same) which is "T-MOB010". The CID is a 8 character string and the case where all characters are the same (i.e. "11111111") is called Super-CID.
It is of no relevance if you use or used the hardware or software keys, T-Mobile or third party sources. The only reason where it would be your fault is if you pulled the battery!
The unlock-code that we possess (regardless if official or from a different source) is not valid to unlock the phone from this value "C3AB". If one tries again (directly with the modem, using my modified libril.so or a different ROM) the lock counter will increase.
Potential ways to repair this state:
1. Give it back to T-Mobile if you can In my opinion this is a clear warranty case
2. Find someone who has the MegaSIM and the HTC-diag software.
This will definitely work but it is going to be hard to find someone because the SIM is rare and very new.
3. Wait until (or help achieving) the so called "real S-OFF" state of the phone (when also the radio has security disabled) is reached.
When this is achieved one can disable the SIM-lock without any code.
There are still some very good developers after this goal even if for different reasons.
.
Click to expand...
Click to collapse
i have got HTC MEGA SIM and Almost all DIAG files but
T-mobile G2 case =After putting unlock code NO NETWORK cant be solved because when we give s58 clear command it shows SIMLOCK CORRUPTED
i can post the detailed info and pictures if you want it would be a pleasure if could help in any kind of DEVELOPMENT
BTW
if we don t put code in the same version,same country,purchased in the same lot of handsets and use MEGASIM directly without touching anything than it works perfect
kabir_del said:
i have got HTC MEGA SIM and Almost all DIAG files but
T-mobile G2 case =After putting unlock code NO NETWORK cant be solved because when we give s58 clear command it shows SIMLOCK CORRUPTED
i can post the detailed info and pictures if you want it would be a pleasure if could help in any kind of DEVELOPMENT
BTW
if we don t put code in the same version,same country,purchased in the same lot of handsets and use MEGASIM directly without touching anything than it works perfect
Click to expand...
Click to collapse
Posting any further details and/or pictures would be much appreciated!
So if megasim has failed due to corruption I think that the only way to solve our issue is to write directly to emmc partition holding locking information. And I don't now how easy and plausible this is...
I think if we get S-Off for Radio, we'll be able to write to that partition. I hope
andrewklau said:
I think if we get S-Off for Radio, we'll be able to write to that partition. I hope
Click to expand...
Click to collapse
I am a little bit worried about writing this information directly because the partition will be encrypted.
And also copying the complete partition from a working phone or one that is still unlocked will not be an option because the IMEI will also be there and we would not want to overwrite that.
So my hopes are more that there is some kind of a restore procedure from a secure area (I know that Nokia phones can do this, but HTC ?) or that we can lock the phone again with the SIMLOCK option in hboot.
Sent from my T-Mobile G2 using XDA App
well I guess time will tell, does tmobile or htc do replacements (or has anyone tried) for phones no longer on a contract or that are now unlocked?
Sent from my T-Mobile G2 using XDA App
andrewklau said:
Posting any further details and/or pictures would be much appreciated!
Click to expand...
Click to collapse
here we go Pictures first Video coming soon
First Red colour is the error we get on when we try the command
1=clear s58 data
2ND IMAGE is the one when we press the DEVICE INFO
today is sunday not much time will upload the full clear video tommorow and still i have not tried to the all options of the diag maybe it can repair it but sure i will do some more things tomm.
88
I have tried to use my HTC vision G2 as I unlocked it but after that I am unable use as I am unable to find anything which would be hlpful for me as I have the first case problem. I just want to know that would it help me that if someone would flash my HTC Vision G2. I just want to know about that as now I am in Pakistan
Sent from my T-Mobile G2 using XDA App