WD5000BUCT-63PUZY0 \ ROM damage

[fzabkar]

I have found what I believe are the locations of the ROYL modules within the patient and donor ROMs. They are similar in structure to a regular WD ROM (eg WD5000BEVT-60ZAT1), but the data are gibberish. However, the gibberish does not appear to be random.

Comparison of ROYL module headers of patient and donor ROMs at specified offsets:

3F1D3
00 1C 82 00 00 00 1C 00 38 00 00 01 94 C5 66 10
00 1C 82 00 00 00 1C 00 38 00 00 01 1E E1 06 04

3F5D3
00 1C 82 00 00 00 1C 00 18 00 00 00 68 80 24 01
00 1C 82 00 00 00 1C 00 18 00 00 01 F0 88 29 06

3F9D3
00 1C 82 00 00 00 1C 00 10 00 00 01 01 23 87 48
00 1C 82 00 00 00 1C 00 10 00 00 01 30 01 E1 90

3FA63
01 1C 82 00 00 00 1C 00 40 00 00 00 04 46 F7 24
03 1C 82 00 00 00 1C 00 40 00 00 00 03 37 C0 84

3FE63
00 1C 82 00 00 00 1C 00 08 00 00 00 87 FC 91 64
00 1C 82 00 00 00 1C 00 08 00 00 00 D8 02 7F F2

3FFB2
00 E4 20 80 00 07 1C 00 00 00 00 01 CB 18 E0 32
00 E4 20 80 00 07 1C 00 00 00 00 01 6A 78 E1 04

ROYL headers from WD5000BEVT-60ZAT1 ROM:

52 4F 59 4C 04 00 1E 00 0D 00 01 00 E2 3D 8C 11
52 4F 59 4C 01 00 1E 00 47 00 02 00 2B 6B 09 CA
52 4F 59 4C 04 00 1E 00 4F 00 01 00 24 B6 AE 65
52 4F 59 4C 01 00 1E 00 30 00 02 00 7C 50 E6 4A
52 4F 59 4C 04 00 1E 00 0B 00 01 00 01 F0 65 A3
52 4F 59 4C 04 00 1E 00 0A 00 01 00 E1 C3 CC 4C

Comparison of 0x0A modules from patient/donor/WD5000BEVT-60ZAT1:

Code:

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

0003FFB0        00 E4 20 80 00 07 1C 00 00 00 00 01 CB 18    .ä €........Ë.
0003FFC0  E0 32 04 08 20 41 02 04 20 40 00 81 08 00 00 00  à2.. A.. @......
0003FFD0  00 08 00 00 00 1C 00 01 78 03 C0 80 00 C5 80 10  ........x.À€.Å€.
0003FFE0  08 20 00 00 00 00 00 00 00 00 00 00 00 00 1F F3  . .............ó

0003FFB0        00 E4 20 80 00 07 1C 00 00 00 00 01 6A 78    .ä €........jx
0003FFC0  E1 04 08 10 20 41 02 04 20 40 20 00 04 00 00 00  á... A.. @ .....
0003FFD0  00 08 00 08 02 18 00 01 78 27 81 80 00 84 00 03  ........x'.€.„..
0003FFE0  01 80 00 00 00 00 00 00 00 00 00 00 00 00 0F 9F  .€.............Ÿ

0002FFB0        52 4F 59 4C 04 00 1E 00 0A 00 01 00 E1 C3    ROYL........áÃ
0002FFC0  CC 4C 30 30 58 31 30 30 30 32 06 12 09 00 00 00  ÌL00X10002......
0002FFD0  20 00 00 04 04 0F 00 00 7C 7C 7C 35 53 42 4A 44   .......|||5SBJD
0002FFE0  35 35 00 00 00 00 00 00 00 00 00 00 00 00 93 FC  55............“ü

[jono-ats]

SD toys having problems??

[eng.mas]

finnally,,
I read the ROM content via external Programmer

I'm sure are correct because, I read the Donor ROM by working HDD and by the externall Programmer
I cmpare the the both file amd the result is Identical

Attachments

Donor.rar

(246.2 KiB) Downloaded 247 times

patient.rar

(240.14 KiB) Downloaded 244 times

[fzabkar]

The patient ROM code checksums OK. I haven't yet checked its ROYL modules, though. However, the donor ROM is from an incompatible drive (WDC WD7500BPVT-75HXZT3). ISTM that it's a different family (HXZ vs PUZ), with 4 heads versus 3 and obviously a different head map (0b00001111 vs 0b00001110).

ISTM that the patient ROM is incompatible with the donor HDD, and that may be the reason that a ROM transfer failed to spin up the drive.

If it is a PUIS issue, then the PUIS flag would be in MOD 0D. FWIW, there are genuine differences at offsets 0x3E, 0x83, and 0x8D, but I could be barking up the wrong tree.

Patient 0D

Code:

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

00000000  52 4F 59 4C 04 00 1E 00 0D 00 01 00 CE 52 9F 47  ROYL........ÎRŸG
00000010  30 30 30 31 30 30 30 30 00 00 00 00 00 00 00 01  00010000........
00000020  30 31 2E 30 31 41 30 31 00 00 03 02 00 00 50 01  01.01A01......P.
00000030  4E E6 01 F4 13 2A 00 01 FE FF 00 00 00 00 02 00  Næ.ô.*..þÿ......
00000040  01 01 00 01 00 00 57 44 43 20 57 44 35 30 30 30  ......WDC WD5000
00000050  42 55 43 54 2D 36 33 50 55 5A 59 30 20 20 20 20  BUCT-63PUZY0   
00000060  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
00000070  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
00000080  20 20 00 00 00 00 00 00 32 00 00 00 00 02 02 00    ......2.......

Donor 0D

Code:

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

00000000  52 4F 59 4C 04 00 1E 00 0D 00 01 00 C1 32 F4 7B  ROYL........Á2ô{
00000010  30 30 30 31 30 30 30 30 00 00 00 00 00 00 00 01  00010000........
00000020  30 33 2E 30 31 41 30 33 01 00 03 02 00 00 50 01  03.01A03......P.
00000030  4E E2 5C B4 1A 4D 00 01 FE FF 00 00 00 00 42 00  Nâ\´.M..þÿ....B.
00000040  01 01 00 01 00 00 57 44 43 20 57 44 37 35 30 30  ......WDC WD7500
00000050  42 50 56 54 2D 37 35 48 58 5A 54 33 20 20 20 20  BPVT-75HXZT3   
00000060  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
00000070  20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
00000080  20 20 00 0E 00 00 00 00 32 00 00 00 00 00 02 00    ......2......

I would examine the original PCB and perform some voltage measurements.

[jermy]

ISTM that it's a different family (HXZ vs PUZ)

the middle char. on the second part doesn't indicate a different family, a matter of fact there are many HDDs with diff. middle char. on the second part and they are the same family, furthermore, there are HDDs with completely different. M/N and they are the same family

and obviously a different head map (0b00001111 vs 0b00001110).

this is a problem

[fzabkar]

AIUI, the BUCT drive is an AV model whereas the BPVT is a regular laptop drive. Can these still be members of the same family?

AV applications often configure their drives to power up in standby, so could this be the "problem"? That's something that could easily be determined with HDAT2 or a similar tool.

[jermy]

AIUI, the BUCT drive is an AV model whereas the BPVT is a regular laptop drive. Can these still be members of the same family?

my reply wasn't specific for this case, it's in general

[eng.mas]

fzabkar,jermy,and Spildit thank you very much for your corporation and analysis,

ISTM that it's a different family (HXZ vs PUZ)

the middle char. on the second part doesn't indicate a different family, a matter of fact there are many HDDs with diff. middle char. on the second part and they are the same family, furthermore, there are HDDs with completely different. M/N and they are the same family

and obviously a different head map (0b00001111 vs 0b00001110).

this is a problem

yes, They may be different family, but I didn't want use the Donor ROM instead the Patient one, Just I put it for compare, becouse I use the Donor's PCB
all, I want to know, If the Patient ROM Structure is correct, and doesn't has any corrupted.

Sorry for the delay in the reply.
Your patient ROM dump is ok.

rom.png

Try to write that on the donor PCB using the same method (programmer) you used to dump the ROM and DO NOT use the SD tool to write that back.

If it still doesn't spin the drive try to insulate the head stack contact from the pcb. If the drive spins then the pre-amp inside the drive is shorted.

Dear Spildit, I'll do this steps as you said

and I'll tell you the result very soon.

Really Thanks ALL,,

[fzabkar]

I notice that some WD drives will switch on the -5V supply to the preamp soon after power-on, and then switch it off again within a second or two. Maybe that would tell us something about the problem.

[eng.mas]

Try to write that on the donor PCB using the same method (programmer) you used to dump the ROM and DO NOT use the SD tool to write that back.

If it still doesn't spin the drive try to insulate the head stack contact from the pcb. If the drive spins then the pre-amp inside the drive is shorted.

I applied that without any change, the drive still doesn't spin.

Ok.
If it still dowsn't spin up the drive - this ROM on a new donor PCB - then get a copy of HDAT2 and a DON boot disk and running from native DOS use HDAT2 /W to attempt to wake up drives in PUIS (power on in standby) mode.

I'll try to apply this part and tell you if seccess.

Thanks,

[eng.mas]

If it still dowsn't spin up the drive - this ROM on a new donor PCB - then get a copy of HDAT2 and a DON boot disk and running from native DOS use HDAT2 /W to attempt to wake up drives in PUIS (power on in standby) mode.

Dear Spildit,

I have a little confused to do this, May you explain how to do this
just clarify

What do mean by HDAT2 /W? , Is this avaliable on HDAT2 V4.9.2
Can I use it from hiren's boot 15.2

[jermy]

since we are talking on pure dos, everything (in dos) is done by commands
so, the command is: HDAT2 /W <enter>

[eng.mas]

Thanks jermy and Spildit

Time for clean room work

[Amarbir[CDR-Labs]]

Hello Eng.mas ,
You can remove the pcb from the hda and then hook to salvation data tool .In a Few minutes the PCB will enter " Kernel Mode " . Then you can definately read rom .You can also enter kernel mode ASAP by setting jumpers into the board .I would highly suggest anns books for wdc salvation data tool you will be amazed to know what you can do with that tool after reading her manuals try it

[Amarbir[CDR-Labs]]

Hello Eng.mas ,
You can remove the pcb from the hda and then hook to salvation data tool .In a Few minutes the PCB will enter " Kernel Mode " . Then you can definately read rom .You can also enter kernel mode ASAP by setting jumpers into the board .I would highly suggest anns books for wdc salvation data tool you will be amazed to know what you can do with that tool after reading her manuals try it

His ROM dumps are just fine when done with proper external progerammer.
The problem is with SD programming unit ...

Well,
Fully understand that spildit .I am sure he can read with SD just fine with the way i suggested instead of the external programmer .

PS : What Tool is This That You Use and post so many times in the forum also .BTW i had a small try at sediv today .Seems interesting

[Amarbir[CDR-Labs]]

PS : What Tool is This That You Use and post so many times in the forum also .BTW i had a small try at sediv today .Seems interesting

It's the wdROMvfy

A tool coded by @fzabkar to check WD ROM intergity :

http://www.hddoracle.com/viewtopic.php?f=22&t=1235

Very Nice ,
BTW i have a small post for frank in the research section .Might be you could also read and comment .