Related
Which is latest version of bootloader in JAM??. Is there any version higher than 1.0??. Please submit...
i have 1.02
Due to some issues happened during big storage mod I have restore my phone from other old JAM backup. I think before that my boot loader is also 1.02 But now it is 1.0 . I did the d2s with 80000 0400000 full backup. Will it overwrite bootloader??. Can I upgrade my bootloader in anyway? Please help....
Do we have any advantages with latest version boot loader?? What difference we will have with the each versions??
SD Flashing can change your bootloader .. if you really want to change back your bootloader .. just use your old SD backup (the first/original SD backup that you made) then flash it to your device.. if you dont have it already you can change your bootloader using
itsme's PNEWBOOTLOADER.exe , the tool can upgrade bootloader of WALLABY, HIMALAYA and MAGICIAN .. tnx itsme for creating this tool ..
the only difference i see with different bootloader is during flashing .. some bootloader have some problem in flashing .. like in HIMALAYA .. 0.23 cant flash radio ROM using SD backup , 0.26b cant flash Extended_ROM in nbf, all version below 1.03 .. have this problem that sometimes it cant flash using a nbf(himaupgradeut.exe) and need to make a sd flashing..
Anyway my point is if u didnt find any problem using your current bootloader, i suggest to stay with that but if you do then thats the time that i can only suggest to change your bootloader .. anyway changing your bootloader can fry your device ..
-toe
To use pnewbootloader tool where can I get the rom file of the new bootloader version??
heres bootloader 1.02
15:03:32 Jan 24 2005
1.02 version: 1.38
3d1b0f86b5f1774c32982611b813abbb <- m not sure with md5 (pls itsme correct me if m wrong .. )
i dont have a magician so i didnt try it and i cannot guarantee that this is a correct bootloader
PS. This bootloader is for Magician and not for anyother device, i will not take responsibility for any thing that will cause for a brick device due for using of this bootloader .. please be very careful .. i already once killed my device due to bootloader ..
-toe
SD Flashing
Hi toenailed,
What's SD Flashing?
thanks
Toenailed:
could u be so kind to tell me what i'm doing wrong, i'm trying to upgrade / or maybe should i say fix my bootloader, when I do a pmemdump 80000000 00040000 I get little stuff, mostly it's blank.. (*uh oh*) I'm sure this is not the way it should be. I tried using it'sme pnewbootloader, and got an error
"Unable to find flash info offset, cannot disable bootloader writeprotect"
this is what i typed:
Code:
C:\exp\1\build>pnewbootloader.exe -f -o 80000000 -l 00040000 c:\flashboot.bin\BL1.02-1.38.nb0
Unable to find flash info offset, cannot disable bootloader writeprotect
also tried the simple
Code:
pnewbootloader.exe BL1.02-1.3.28.nb0
I'll post my setup in a bit, i'm trying to re-flash my devices SHIPPED roms, hopefully that will restore things.. (crosses his fingers) anyways what I think I did is erased the GSM bootloader, thus I cannot use my phone at all, the close i get to using my phone is getting to WinMobile.. anyways this is really not a problem thus I called my carrier and they are going to ship me a new one.. I just wanted to known for sake of knowledge and if someone else has the same problem.. also just incase i do it again with my new phone, doubt my carrier will fall for the "I pulled out my battery, and now my device is dead" lol heck i even think I erased my ESN and PRL out of my device, since I get N/A when i'm in Mobile..
[/b]
it means that i did not add code for your specific rom version to pnewbootloader.
what is the OS version you are using?
willem
Oh sorry about that: it'sme, (btw thanks for ur great tools, and website, full of resources). currently I just upgraded to the PDA2k_WWE one, that was just posted recently here is the info...
ROM VERSION: 1.40.00 WWE
ROM Date: 03/10/05
Radio Version: [blank]
Protocol Version: [blank]
ExtROM version: 1.40.176 WWE
but the ORIGINAL one that came with this device is:
I'm not sure if the info below is correct so I also provided the actual full filename of my update..
HA_VZW_13500_115_01140_WOC.exe
MODEL ID: PH20A3
ROM VERSION: 1.35.00
ROM DATE: not sure, since i don't have it installed atm
Radio Version: DM FAIL
Protocol Version: DM FAIL
ExtROM Version: 1.15
also do u happen to know how to bypass the NOT ALLOW UPDATE when using a SD card? I tried to do a radio dump first. but i get Radio stack fail (tm). also i think i messed aroud with some of the rroute rrouter settings, could u possibly tell me what the default/correct settings might be?
thanks lots..
oh yea, and also using xdatools, when I try to use them, It either says that my image is to big, or it says it's to small, or it says cannot connect to USB using Programme a
thanks again..
itsme said:
it means that i did not add code for your specific rom version to pnewbootloader.
what is the OS version you are using?
willem
Click to expand...
Click to collapse
Hello "itsme"... I have a little question to you...
It's posible to use 'pnewbootloader.exe' to flash any OS ROM offset using the '-o' and '-l' parameters?
Thanks :wink:
Hello toenailed / itsme..
Before I'm trying to change my bootloader to the 1.02 (and it can be a disaster some times) what are my advantages with a newer bootloader like 1.02 from 1.00. Now I'm sure before the SD flash restore from another JAM mine was 1.02. Do I have (with 1.02) a higher performance or bugfree or more support to hardware device? I have also notice one thing after this change to 1.00. Some time after soft-reset I will a "Unidentified USB device error" and it will prompt for correct USB driver and bluetooth will not work for sometime. But after 5 mins it will start working. This problem will not occur if I'm removing the main battery for a soft-reset.
Is this issue could be with bootloader version? Other than the OS booting and loading what else bootloader doooo??
zxvf: i don't think you are talking about a magician rom.
the 'not allow update' means that you restore a backup made with a different bootloader version. .... or that the sdcard contains an invalid signature.
MKS: in theory, yes, but for several locations in the ROM, the protection needs to be removed.
the protection is a list of values which specify where the non-flashable area of rom starts and ends.
pnewbootloader temporarily changes these non-flashable area's to something not in the ROM.
nishadks: there is no real need to upgrade your bootloader, it is more useful, to downgrade, since older bootloaders, usually have less protections built in.
Thanks a lot itsme for your help....
Itsme:
You are correct, I didn't pay attention to it being a bootloader for the magician, (eventhough it's bolded lol) anyways, I tried it ones again, with a rom that I KNOW is the same that I had, because before messing around with it, I made a backup with two different tools osupdate.exe and bootblaster.exe (the one from handhelds.org for unix flashing). So i have this files both as .bin files, but can't seem to use the l command AT ALL eventhough I have both of the passwords, (actually don't really know how to use mtty.exe) I can't get the concept on how u send the files.. because it timesout and says something like "the second computer timed out.." or something like that, it seems that I need to start some type of send transfer something similar like (tx, and rx) in unix.. but not really sure how to do this with mtty.exe, or do i actually need to have a serial cable, is it not possible with the cradle that came with the device? I was actually thinking on creating a cable since, I got a USB to Serial converter... so maybe that will work.. but havn't had much time to mess around with that...
I also tried every possible version that u said is supported in ur .cpp file and none will actually work with my device, they all just make my device screan white and it starts fading out to black, (or sometimes it starts with a diff color.)
so what should I do/try to get pnewbootloader.exe to work? or is there any software that I can use in Win mobile (on the pda) to just run it locally?
Cheers, and thanks again...
how to use pnewbootloader
hi mate would u plz like to to tell me how can i install b0otloader 1.02 on my magician. i hav tried to use pnewbootloader but cant find any help abt it how to use it. i hav 2 magicians 1 hav bootloader 1.02 and other 1.0.
the problem is i cant read my high speed sd card on magician with bootloader 1.0. but it works on magician with bootloader 1.02 both hav same versions of roms. i hav extracted my bootloader from newer one but dont know how to copy it on old 1.
if possible than email me on
[email protected]
thanks
bl*.nb
Please someone where I can download any version of the bootloader. I can not download on the link in post number 7
thanks, and sorry for my google translate.
same for me, page goes blank, and download never starts
After banging my head with the update utility and a bootsplash stuck universal for like hours, I did decrypt the bootloader 1.0... Will do some reverse engineering and post what I find... :lol:
Update: decrypted Bootloader 1.0 is attached...
ady,
if this is true... congratulations!!!
you may want to share your knowledge with buzz and the other specialists ;-)
have a good success
peter
hi ady,
GREAT!
could you please tell me how you did it?
thanx
buzz
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
very interesting approach... )))
buzz
Thanx buzz.
something which I observed earlier while looking at the string table:
It has multilevel password protection and the password for each level i.e update, erase, dump, debug is calculated at runtime.
Moreover the access level resets to lowest after a certain time which makes it almost unhackable
There are strings related to CID meaning there might be a method to change CID
updated first post to attach the decrypted bootloader 1.0 for those who are interested.
Also I succesfully flashed the 1.0 bootloader on a device which was previously updated with 1.01...
Of course if was after hacking the RUU.dll. By default it doesn't let you update to an older bootloader
ady I have been looking at the bootloader of the prophet and the interaction between the romupdate utility and the phone with a software logic analyzer which has revealed a lot of information including the commands that romupdate runs while upgrading the rom.
I am in the process of compiling a list of bootloader commands which may be usefull.
Did you dump the commands while downgrading the bootloader.
Pete
you can find a list of commands very easily. just look at the string table. however not all commands are allowed and that is the callenge
Some commands do not appear to be secured correctly.
For example the rbmc command.
If I run it without a password it says no pemission enter any password and then it will run fine.
The password issued by the romupdate tool seem to be based partly upon the results of the info 2 command as far as I can tell.
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Rymez2K said:
The main command I am struggling to figure out is the r2sd command which reads a key/password from the SD Card.
Click to expand...
Click to collapse
hi,
did you mean d2s command?
buzz
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
hdubli said:
r2sd command runs well when u hv CID unlocked..works for Prohet,wizard and charmer..typhoon
Click to expand...
Click to collapse
;o))) I thought, this is about Universal 1.00 bootloader...
buzz
According to some source of information there are 2 types of Universal. One with G3 and another with G4 chips. G3 bootroms have string "HW Version : 1.40h" in bootloader and its version is 1.xx, G4: "1.40j" and version numbers are 2.xx. Your ROM is for G3.
And bootrom can be decoded from nk.nbf with alpinenbfdecode.pl script
ady said:
By hacking the ruu.dll and running the upgradeut. I'm away at the moment. Will post it later
Click to expand...
Click to collapse
If this is correct , i hope, ...the nk.nbf of JASJAR bootloader can be decoded from bal66 tool and one can get.nba file.But I was not able to decode further with imgfs tools...it simply fails to do that....
@hdubli
bootloader image - nk.nba - is not an imgfs. you cannot use mamaich's imgfs_tools on it.
bal66's tool cannot decode bootloader nk.nbf to nk.nba either.
buzz
Attached is the file...pls check
hdubli said:
Attached is the file...pls check
Click to expand...
Click to collapse
yes, that file looks to be OK...
buzz
another thing:
lnb command doesn't work on 1.0 or 1.01. Another command wdata is used instead to update.
the difference between the two commands is that lnb needs to have an nb image i.e. lnb lnbtemp.nb whereas wdata transfers the image directly from host computer memory (more hack safe)
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
First of all I feel obliged to say I'm sorry for creating a new thread just for these basic questions.
I have read the FAQs and searched through the forum, and it's a bit messy hence this thread.
First of all I want to have the security to be able to revert to the stock ROM in case something goes wrong.
1) I do not find any SWE-rom in the collection thread though. My question is, can I (or someone help me to) dump my 1.43 SWE rom?
Edit: Just found this link by chance in duttys signature:http://rapidshare.com/users/258XUJ
And the swedish rom is included here. I wonder why this is not included in the sticky thread (..........)
2) If I flash to a custom ROM with SSPL, can I flash a stock ROM back with SSPL or do I really need to go through all the hassle with the gold card etc? Is there no easy way to flash an official ROM?
3) If I use HSPL to upgrade my bootloader, my warranty will be affected if I'm not mistaken. Could HTC (or whoever who performs service) deny my phone because I've used HSPL from here? If so, is there any way to revert to the state before using the HSPL, that is to say load the previous stock bootloader?
Once again, if you find this thread unnecessary please just ignore it and let it die or delete it.
I did some searching and still had these questions left, and I'm in the middle of studying for an upcoming exam while my HD2 is pissing me off since my last (and first) hard reset (the WiFi is really bugging out).
So I hope this will save me some time (and maybe other newbies)
I'm not sure if there's a way to actually back it up, but u should be able to get the official one off the htc support website. htc.com/support
using sspl is only for custom roms, but hard spl is now available. it let's you flash anything.g..custom or official.
Thx for the reply,
The swedish rom is not available there unfortunately. Hence my problem.
Regarding the HSPL, I have another question:
3) If I use HSPL to upgrade my bootloader, my warranty will be affected if I'm not mistaken. Could HTC (or whoever who performs service) deny my phone because I've used HSPL from here? If so, is there any way to revert to the state before using the HSPL, that is to say load the previous stock bootloader?
I'm not really sure about hard spl yet..I've not had a chance to read about it..or needed it.
i think you can revert to original spl by using goldcard method...and with this, your warranty still intact... but just read about it in sticky to be sure.
tshizzle said:
I'm not really sure about hard spl yet..I've not had a chance to read about it..or needed it.
i think you can revert to original spl by using goldcard method...and with this, your warranty still intact... but just read about it in sticky to be sure.
Click to expand...
Click to collapse
You don't mean reverting SPL but flashing official ROMs right?
I did not read anything about the goldcard changing SPL?
Now that question 1 & 2 have been answered only question 3 is left.
A way to revert the SPL in case something happens and I have to send it for repair.
Only way to remove the HSPL is to flash an original SPL from SD card.
- Take any "RUU_signed.nbh" from a ship ROM and copy it to SD card.
- Rename it to "leoimg.nbh"
- Reset the device while pressing the volume down button.
Click to expand...
Click to collapse
you're right...it is flashing original rom...but that removes hspl.
i think you should just read http://forum.xda-developers.com/showthread.php?t=611433cuz i haven't...and don't think I'm qualified to give advice..
tshizzle said:
you're right...it is flashing original rom...but that removes hspl.
i think you should just read http://forum.xda-developers.com/showthread.php?t=611433cuz i haven't...and don't think I'm qualified to give advice..
Click to expand...
Click to collapse
I see, that one I had missed. So it should be realitvely easy to restore both the SPL (by following the steps you quoted, no gold card needed) and the stock rom if one has HSPL, as long as one has the stock ROM (which I'm downloading atm )
In that case this is great news, I'll be ready to start flashing in no time
I dont get it. I downloaded the stock ROM from the link provided above, it is an exe-file. Just like an official rom release from HTC.
Does this mean that I can install a custom ROM with SSPL and revert to the stock ROM simply by running the exe-file while the phone is in ActiveSync, without any need of using goldcard/HSPL?
umiss said:
I dont get it. I downloaded the stock ROM from the link provided above, it is an exe-file. Just like an official rom release from HTC.
Does this mean that I can install a custom ROM with SSPL and revert to the stock ROM simply by running the exe-file while the phone is in ActiveSync, without any need of using goldcard/HSPL?
Click to expand...
Click to collapse
You need to extract the exe to get the nbh-file that you use to flash with SSPL. Just right klick and extract it, put nbh ans SSPL in a folder and run SSPL. Simple as that
Thanks alot for the help. I am ready to flash away
Confused....
Rather than creating a new thread I thought I'd post in here about a rom dump - and the troubles I'm having. (hope that's ok)
I'm trying to dump my official stock HD2 rom but something's not going right.....
I want to do this to have a backup before I start flashing custom roms and to also share it as I noticed it is not on the list in the sticky thread.
I'm using "dump my phone" which I found here:
http://forum.xda-developers.com/showthread.php?t=509708
Everything seems to run ok, but when I run the final part I get the following errors:
CopyTFFSToFile(0x0, 0x520000, Part01.raw)
ERROR: ITReadDisk: outbuf==NULL
- The device is not ready for use
CopyTFFSToFile(0x0, 0xdd80000, Part02.raw)
ERROR: ITReadDisk: outbuf==NULL
- The device is not ready for use
I found another site with details on how to backup the stock rom:
http://www.planete-htc.com/index.php?mod=forum&ac=voir&ref=30&cat=282&id=22438&debut=0
(It's in french but I could understand most of it) but I continue to get the exact same error as before.
I've tried on 2 different computers (XP & vista) but no joy. Can anyone please provide some advice on what could be causing the problem?
I'd really love to be able to backup this rom.
Thanks.
aushtcuser said:
I've tried on 2 different computers (XP & vista) but no joy. Can anyone please provide some advice on what could be causing the problem?
I'd really love to be able to backup this rom.
Thanks.
Click to expand...
Click to collapse
Hi, I successfully dumped my raw rom using this
http://forum.xda-developers.com/showthread.php?t=427507
process.
the thread reffers to the raphael, so the numbers that are generated during the process (the coloured ones) are different, but take it slow, its an easy step by step.
Once the raw files are dumped, you will, then need to figure out how to rebuild them, but i 'think' kitchens can be used for that.
Why don't you guys just download the officially released stock ROM? In my case there was none to download (or so I thought) hence I started the thread. Later on I found link to the official ROM so I started flashing immediately =P
umiss said:
Why don't you guys just download the officially released stock ROM? In my case there was none to download (or so I thought) hence I started the thread. Later on I found link to the official ROM so I started flashing immediately =P
Click to expand...
Click to collapse
hehe, and thats why i never got around to figuring out the converting of teh raw dumps, I found my stock rom.
what if you need a stock rom that hasnt been uploaded to the website??
I'm still interested personally in converting the raw dump to a .nbh installable via hspl.
chris_ah1 said:
what if you need a stock rom that hasnt been uploaded to the website??
I'm still interested personally in converting the raw dump to a .nbh installable via hspl.
Click to expand...
Click to collapse
Go have a read of the thread i linked above, as i said, I dumped the raw files easy enough, and the rest of the process of reconstructing should be the same, although of course you will have to use leo source files and what not.
samsamuel said:
Hi, I successfully dumped my raw rom using this
http://forum.xda-developers.com/showthread.php?t=427507
process.
the thread reffers to the raphael, so the numbers that are generated during the process (the coloured ones) are different, but take it slow, its an easy step by step.
Once the raw files are dumped, you will, then need to figure out how to rebuild them, but i 'think' kitchens can be used for that.
Click to expand...
Click to collapse
Thanks for the help......the methods in that thread are very similar to the ones I've already tried. I have everything copied correctly to my device, found my address codes, but whenever I run this line:
“pdocread -w -d DSK1: -b 0x800 -p Part00 0 0x31f000 Part00.raw”
I get the same error as I mentioned previously - the device is not ready.
I've tried enabling/disabling faster activesync connection but still the error occurs.
umiss said:
Why don't you guys just download the officially released stock ROM? In my case there was none to download (or so I thought) hence I started the thread. Later on I found link to the official ROM so I started flashing immediately =P
Click to expand...
Click to collapse
If I could find this exact version I would've done that by now, but I can't find it anywhere ROM version - 1.48.421.2 WWE
Hmm, three things to check,
1, the number 0x31f000 are you sure thats the right one, give as teh output of the "procread.exe -l" command? (Just checking you arent just copy/pasting teh thread commands)
2, are you using am external usb slot? i've found hspl doesn't instal over my usb slot in eth case of my machine, but does when i plug it into one of the slots directly on the motherboard, , maybe this is teh same?
3, is itsutils.dll running? is there a popup on your mobile with 'allow this program?' or something similar?
1 - I just copied/pasted what was in the thread, but I just ran the pdocread.exe again and it is the same address.
2 - I'm using a laptop but I've never had any connection issues with it previously.
3 - Not sure if that process is running. Nothing appears on the phone to confirm it.
Here's a really stupid question but am I meant to be doing this after I install HSPL? I haven't done that yet as I thought I could backup the rom beforehand.....
aushtcuser said:
1 - I just copied/pasted what was in the thread, but I just ran the pdocread.exe again and it is the same address.
2 - I'm using a laptop but I've never had any connection issues with it previously.
3 - Not sure if that process is running. Nothing appears on the phone to confirm it.
Here's a really stupid question but am I meant to be doing this after I install HSPL? I haven't done that yet as I thought I could backup the rom beforehand.....
Click to expand...
Click to collapse
No, no need for hspl here.
OK, you changed the HKLM\Security\Policies\Policies setting, you soft reset. (Power propperly off and back on), you copied over itsutils.dll and moved it to /windows.
Next step is opening command prompt, did you open it as administrator?
oh wait, in your command
“pdocread -w -d DSK1: -b 0x800 -p Part00 0 0x31f000 Part00.raw”
are you sure it is DSK1:?
Cos im failry sure mine came out at DSK7 or something, pretty sure it wasn't 1...
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.