How to verify ROM backup of SMT5600?

geminix2 · Mar 31, 2010

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.

tobbbie · Apr 3, 2010

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.

geminix2 · Apr 3, 2010

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.

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.

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.

Thanks. Good to know.

Something apparently went wrong somewhere because I didn't get that report but I'll try again.

tobbbie · Apr 3, 2010

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.

geminix2 · Apr 4, 2010

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.

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

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!

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.

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.

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?

tobbbie · Apr 4, 2010

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...

geminix2 · Apr 5, 2010

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

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...

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.

tobbbie · Apr 5, 2010

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.

geminix2 · Jan 24, 2011

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.

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.

tobbbie · Jan 24, 2011

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.

geminix2 · Jan 24, 2011

tobbbie said:
Hey that thread has a long history - what happened in the meantime?

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?

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.

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.

tobbbie · Jan 24, 2011

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.

geminix2 · Jan 24, 2011

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.

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.

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.

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.

Topics

Topics

How to verify ROM backup of SMT5600?

geminix2

Member

tobbbie

Senior Member

geminix2

Member

tobbbie

Senior Member

geminix2

Member

tobbbie

Senior Member

geminix2

Member

tobbbie

Senior Member

geminix2

Member

tobbbie

Senior Member

geminix2

Member

tobbbie

Senior Member

geminix2

Member

Similar threads

Top Liked Posts

New posts