WD2500JB ROM Question

[ddrecovery]

This drive was subject to a significant power surge. The ROM is corrupt so cannot be used (maybe rebuilt?). There is not much info on lost ROM's for this type of drive in the PC-3000 manual. So first I wanted to check the ROM version in case the same version would work as a replacement. However I cannot find it on the ROM. Can anyone point out the right line of hex the firmware might be detailed on?

Attachments

Sample ROM.zip

(123.26 KiB) Downloaded 883 times

[fzabkar]

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00015D30                                      38 30 30 2E              800.
00015D40  44 32 38 30                                      D280

"800.D280" looks like a firmware version.

Otherwise I've worked out the structure of the ROM and its checksums, so I could check your corrupt ROM, if you like.

[data-medics]

What's the full model of the drive including after the dash? I can check to see if it has a copy of ROM in the service area.

[ddrecovery]

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00015D30                                      38 30 30 2E              800.
00015D40  44 32 38 30                                      D280

"800.D280" looks like a firmware version.

Otherwise I've worked out the structure of the ROM and its checksums, so I could check your corrupt ROM, if you like.

Many thanks. Just looked at the patient ROM and it is the same version. However not sure if any specific adaptives are stored on this ROM (I don't think so as its an old Cyl32), but if you could take a look it would be great

What's the full model of the drive including after the dash? I can check to see if it has a copy of ROM in the service area.

If you do have one its certainly worth a try WD2500JB - 00GVC0 - 800.D280 Many thanks to both of you.

Attachments

WD2500JB ROM.zip

(123.14 KiB) Downloaded 943 times

[fzabkar]

This appears to be the head map module in Sample ROM.zip:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0001FFD0  20 06 00 06 06 3F 00 00 00 00 00 00 00 00 00 00
0001FFE0  00 00 FF 0F 00 00 00 00 00 00 00 00 00 00 81 FE
0001FFF0  5A 5A FF FF FF FF FF FF FF FF FF FF 00 00 A9

This is the same module in WD2500JB ROM.zip:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0001FFD0  20 01 00 06 06 3F 00 00 00 00 00 00 00 00 00 00
0001FFE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 94 FF
0001FFF0  5A 5A FF FF FF FF FF FF FF FF FF FF 00 00 A9

AISI, the last byte should be the checksum of the preceding bytes.

In "Sample ROM" the checksum is 0xA8.

In "WD2500JB ROM" the checksum is 0xA9.

So this would suggest that the "sample ROM" is corrupt but the patient is OK.

Note also that, in both cases, the first 0x1F bytes sum to 0x00. This would suggest that the 0xFE byte should be 0xFF.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0001FFD0  20 06 00 06 06 3F 00 00 00 00 00 00 00 00 00 00
0001FFE0  00 00 FF 0F 00 00 00 00 00 00 00 00 00 00 81

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0001FFD0  20 01 00 06 06 3F 00 00 00 00 00 00 00 00 00 00
0001FFE0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 94

[fzabkar]

I checksummed the full ROM dumps and got 0xF2 for the Sample ROM and 0xF3 for WD2500JB ROM.

I also get 0xF2 for the ROM checksums in the following resources (WD1600JB-00GVC0-08.02D08 and WD1200JB-00GVC0-08.02D08):

http://files.hddguru.com/download/PC-30 ... 563682.rar

http://files.hddguru.com/download/PC-30 ... 80/ROM.rar

ISTM that both the OP's ROM dumps have checksum problems, either in the head map module or the very last byte. It appears that the last byte is the checksum byte for the entire ROM, and that its value should be chosen so that the ROM checksum is 0xF2.

[ddrecovery]

I checksummed the full ROM dumps and got 0xF2 for the Sample ROM and 0xF3 for WD2500JB ROM.

I also get 0xF2 for the ROM checksums in the following resources (WD1600JB-00GVC0-08.02D08 and WD1200JB-00GVC0-08.02D08):

http://files.hddguru.com/download/PC-30 ... 563682.rar

http://files.hddguru.com/download/PC-30 ... 80/ROM.rar

ISTM that both the OP's ROM dumps have checksum problems, either in the head map module or the very last byte. It appears that the last byte is the checksum byte for the entire ROM, and that its value should be chosen so that the ROM checksum is 0xF2.

Thanks for your work on this. The sample ROM was taken from the PC-3000 database. Not sure why this should also be corrupt. I will try to correct the original ROM. Many thanks for the advice.

[pcimage]

Firstly, what leads you to believe the original ROM is corrupt? Unless I'm missing something, I don't see the symptoms of your problem.

Secondly, you should be able to use a ROM from a drive with a similar serial number,. There's nothing especially unique in these ROM's, some head microjog info but should still work well enough for a recovery.

[fzabkar]

I have adjusted the checksums in both ROM dumps in accordance with my analysis.

Each ROM is divided into 11 sections. The last byte of each section is the checksum for that section. The last byte of the ROM appears to be the overall checksum byte for the ROM. I'm assuming this checksum should always be 0xF2, but I could be wrong.

Attachments

WD2500JB.rar

(246.45 KiB) Downloaded 1091 times

[ddrecovery]

I have adjusted the checksums in both ROM dumps in accordance with my analysis.

Each ROM is divided into 11 sections. The last byte of each section is the checksum for that section. The last byte of the ROM appears to be the overall checksum byte for the ROM. I'm assuming this checksum should always be 0xF2, but I could be wrong.

Many thanks. Really appreciate the support. How do you test the checksum? I would be keen to learn. See below.

Firstly, what leads you to believe the original ROM is corrupt? Unless I'm missing something, I don't see the symptoms of your problem.

Secondly, you should be able to use a ROM from a drive with a similar serial number,. There's nothing especially unique in these ROM's, some head microjog info but should still work well enough for a recovery.

Drive came to me from a computer store who had tried a DIY ROM chip swap. Looks like they didn't use heat, just a pair of pliers. Managed to get the ROM to read in a reader. Wrote to donor board but PC3000 status lights were all over the place. Tried a second donor board with same ROM, same result. Used the second donor with matching family ROM and the drive clicks but comes RDY in Kernel mode.

I have tried several matching ROM's but the drive still clicks and shuts down (with new heads). So after Fzabkar's hard work on the original ROM I think there must be SA damage. I have another donor due in next week to try a hot swap and see how we get on. Any other advice you have would be appreciated.

[fzabkar]

Are you saying that the drive did not spin up with the original ROM? Did it spin up with the ROM from the PC3K database?

[ddrecovery]

Are you saying that the drive did not spin up with the original ROM? Did it spin up with the ROM from the PC3K database?

That is correct.

[fzabkar]

Are you saying that the drive did not spin up with the original ROM? Did it spin up with the ROM from the PC3K database?

That is correct.

If my edited ROM spins up the drive, then that would be VERY suspicious. How likely is it that only the very last bit of the ROM would flip from 0 to 1?

If the edited ROM works, and if the corruption is due to sabotage, then one would have to wonder if any additional damage was done.

I'll try to write up my analysis of your ROM structure when I get a chance, but I first need to know if my edit was valid.

[ddrecovery]

Are you saying that the drive did not spin up with the original ROM? Did it spin up with the ROM from the PC3K database?

That is correct.

If my edited ROM spins up the drive, then that would be VERY suspicious. How likely is it that only the very last bit of the ROM would flip from 0 to 1?

If the edited ROM works, and if the corruption is due to sabotage, then one would have to wonder if any additional damage was done.

I'll try to write up my analysis of your ROM structure when I get a chance, but I first need to know if my edit was valid.

Yes you edit was valid The drive does spin up.

[pcimage]

If the drive clicks with a good PCB and ROM from same model, then it's likely the preamp is blown by the surge.

These drives are notoriously difficult to change heads in without a LOT of jiggery-pokers.

They almost never startup on their own with non-native heads, just click and spin down. Take two working drives and switch the heads and you'll see!

[ddrecovery]

If the drive clicks with a good PCB and ROM from same model, then it's likely the preamp is blown by the surge.
These drives are notoriously difficult to change heads in without a LOT of jiggery-pokers.
They almost never startup on their own with non-native heads, just click and spin down. Take two working drives and switch the heads and you'll see!

I know how difficult they can be (and the BB version). Thats why I think another donor and a hot swap may be the best chance.

[fzabkar]

This is the beginning of the ROM:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  5A 26 8D 01 00 8D 01 00 C0 01 00 00 66 C1 00 66  Z&......À...fÁ.f
00000010  C1 B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 91  Á°§æ^.....i296A‘
00000020  01 26 69 23 00 69 23 00 4D 03 00 00 41 C1 00 41  .&i#.i#.M...AÁ.A
00000030  C1 B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 79  Á°§æ^.....i296Ay
00000040  02 26 31 0E 00 31 0E 00 B6 26 00 22 20 C1 22 20  .&1..1..¶&." Á"
00000050  C1 B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 6E  Á°§æ^.....i296An
00000060  03 21 E4 B5 00 AF FA 00 E7 34 00 00 00 C0 FF FF  .!äµ.¯ú.ç4...Àÿÿ
00000070  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 24  ÿ°§æ^.....i296A$
00000080  04 21 85 00 00 01 04 00 CB EA 00 00 FC C0 FF FF  .!….....Ëê..üÀÿÿ
00000090  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 03  ÿ°§æ^.....i296A.
000000A0  05 11 53 4E 00 C9 6E 00 50 EB 00 00 00 23 FF FF  ..SN.Én.Pë...#ÿÿ
000000B0  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 2F  ÿ°§æ^.....i296A/
000000C0  06 11 86 23 00 C5 2C 00 A3 39 01 00 80 23 FF FF  ..†#.Å,.£9..€#ÿÿ
000000D0  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 14  ÿ°§æ^.....i296A.
000000E0  09 90 2F 00 00 2F 00 00 D0 FF 01 D0 7F 23 FF FF  ../../..Ðÿ.Ð.#ÿÿ
000000F0  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 1C  ÿ°§æ^.....i296A.
00000100  0B 50 26 00 00 26 00 00 29 5D 01 06 F4 29 FF FF  .P&..&..)]..ô)ÿÿ
00000110  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 34  ÿ°§æ^.....i296A4
00000120  0C 50 06 02 00 06 02 00 4F 5D 01 2C F4 29 FF FF  .P......O].,ô)ÿÿ
00000130  FF B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 45  ÿ°§æ^.....i296AE
00000140  07 13 AD 9F 00 09 DD 00 55 5F 01 00 00 22 C4 86  ..­Ÿ..Ý.U_..."Ć
00000150  22 B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 75  "°§æ^.....i296Au

There are 11 sections. Each section has a 32-byte header (LDSC).

For example, here is the first LDSC:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  5A 26 8D 01 00 8D 01 00 C0 01 00 00 66 C1 00 66  Z&......À...fÁ.f
00000010  C1 B0 A7 E6 5E 00 00 00 00 00 69 32 39 36 41 91  Á°§æ^.....i296A‘

The structure of each LDSC appears to be as follows:

Code:

Byte #   Value         Description
-----------------------------------------------------------------------------------
00       0x5A          ID --> 5A indicates boot from flash ??
01       0x26          attribute ? (bit 0 indicates whether section is compressed ?)
02-04    0x00018D      size of section
05-07    0x00018D      size of decompressed section ?
08-0A    0x0001C0      address of section in ROM
0B-0D    0xC16600      load address of section in RAM ?
0E-10    0xC16600      second RAM address ???
11-14    0x5EE6A7B0    date/time stamp ???
15-19    zeros         ?
1A-1E    "i296A"       MCU ID ?
1F       0x91          checksum of bytes 0x00 - 0x1E


Here is the first section in ROM:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

000001C0  D1 80 E6 EE 00 02 E0 15 7E D9 F6 F5 B4 F0 7F D9
000001D0  E6 F5 20 00 F6 F5 40 C2 E6 08 00 FC CC 00 E6 00
........
00000330  F3 F6 52 C2 E1 07 46 F2 FF FF 3D 03 47 F6 FF 00
00000340  2D 02 EC F3 EC F2 DB 00 CC 00 01 00 C4

If we add all the bytes from address 0x1C0 to 0x34B, the result is 0xC4. This corresponds to the value at address 0x34C. Therefore the last byte is the checksum byte.

I use the checksum calculator within HxD (freeware hex editor).

[ddrecovery]

Thanks for taking the time to explain that. It really is very useful to know how that stuff works. Again thanks

[fzabkar]

It really is very useful to know how that stuff works.

If I apply the above analysis to your PC3K sample ROM, then section 09 has a bad checksum. All other sections are OK, though. :?

BTW, it might help to see the original damaged PCB. The nature of the damage may point to whether the surge came via the +5V or +12V supply. If the overvoltage was confined to the +12V input, then there would be less chance of a preamp failure.

Is this your PCB?

http://ep.yimg.com/ay/yhst-144375849714 ... sfer-3.gif

[Amarbir[CDR-Labs]]

I have adjusted the checksums in both ROM dumps in accordance with my analysis.

Each ROM is divided into 11 sections. The last byte of each section is the checksum for that section. The last byte of the ROM appears to be the overall checksum byte for the ROM. I'm assuming this checksum should always be 0xF2, but I could be wrong.

Many thanks. Really appreciate the support. How do you test the checksum? I would be keen to learn. See below.

Firstly, what leads you to believe the original ROM is corrupt? Unless I'm missing something, I don't see the symptoms of your problem.

Secondly, you should be able to use a ROM from a drive with a similar serial number,. There's nothing especially unique in these ROM's, some head microjog info but should still work well enough for a recovery.

Drive came to me from a computer store who had tried a DIY ROM chip swap. Looks like they didn't use heat, just a pair of pliers. Managed to get the ROM to read in a reader. Wrote to donor board but PC3000 status lights were all over the place. Tried a second donor board with same ROM, same result. Used the second donor with matching family ROM and the drive clicks but comes RDY in Kernel mode.

I have tried several matching ROM's but the drive still clicks and shuts down (with new heads). So after Fzabkar's hard work on the original ROM I think there must be SA damage. I have another donor due in next week to try a hot swap and see how we get on. Any other advice you have would be appreciated.

Hi ,
You Said " Wrote to donor board but PC3000 status lights were all over the place. " .Is This a IDE Drive If Yes Have You Installed Master Jumper To This .I am saying this is its a IDE not if its a SATA .