Anybody transfer ROM adaptives from WD1001FYYZ SAS drive ?

[Alandata Recovery]

Anybody transfer ROM adaptives from WD1001FYYZ SAS drive ?

Hi

I have a SAS drive with bad head 0

I swapped heads and can read H0 but really really slow.

We are using pc3000SAS

But it doesnt parse the rom

Maybe someone can do this by hand or has a tool

Fzakbar maybe ?

By the way

I hot swapped a sata board from an FYYG and could access the SA.

So maybe the SAS rom is not far different from the SATA rom

Here is a link to down load the roms.

 https://slack-files.com/T041AF3B4-F036KE4BZ6J-871fe773dd

Thanks

--

--

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, NAS, Linux, Tape, Disk, Forensics"

www.alandata.com   www.alandataRecovery.com

[pbzcbf...@gmail.com]

Wow! I like your hotswap trick.

BTW, the firmware in this drive is a new architecture (Arch 7). The adaptive section is at offset 0xB8000 and has a size of 0x8000 bytes.

The SAS ROM appears to have the same structure as a SATA Arch 7 ROM.

I have written a tool to analyse these ROMs:

http://www.hddoracle.com/viewtopic.php?f=3&t=2762&p=20670#p20670

http://www.users.on.net/~fzabkar/FreeBasic_W32/WD/WDnewROM2.bas

http://www.users.on.net/~fzabkar/FreeBasic_W32/WD/WDnewROM.exe

Unfortunately my tool needs a little reworking to account for some "strangeness" in these two examples.

BTW, do the pro tools now support WD Arch 7 firmware?

[pbzcbf...@gmail.com]

I think something is wrong with your ROM dumps. My tool produces the correct result if I delete the area between 0x40000 - 0x7FFFF. This area is filled with 0xFF.

[pbzcbf...@gmail.com]

My searches tell me that  WD1001FYYG is a WD RE SAS model, not SATA. :-?

https://www.hdstorageworks.com/datasheets/Hard-Drives/WD-RE-SAS-Specsheet.pdf

https://i.ebayimg.com/images/g/yFkAAOSwbahgLW~c/s-l500.jpg

https://www.disctech.com/SCASite/product_images/WD1001FYYG_1000-2.jpg

https://www.nix.ru/images/Western-Digital-WD1001FYYG-1509372245.jpg?good_id=150937&width=500&height=500&view_id=2245

https://img.ruten.com.tw/s1/5/98/29/21849187989545_506.jpg

[pbzcbf...@gmail.com]

WD1001FYYZ-01Y7B0 is a SATA drive.

I got only 1 hit in my Internet searches:

https://valid.x86.fr/mkkseg

The family code is Vulcan RE (Y7):

https://firmware.hddsurgery.com/index.php?manufacturer=Western%20Digital&family=Vulcan%20RE

Does this mean that a patient PCB from a Marvell ROYL architecture was able to access the SA in a SAS drive with the new Arch 7 firmware? !!!

Could you dump the ROM and SA resources from the FYYZ drive?

Could you dump the patient's Arch 7 SA modules and tracks after a hotswap?

[wayne horner]

yes

I should have said wd2000FYYZ

I hot swapped it to ne of the FYYG's and could read the SA completely 

Structure test

hdd info

just not data

I tried it with another FYYG and couldnt read anything

So I think adaptives are the issue

I will take pictures 

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/22cee761-b472-40ad-b87f-1aca790d80c3n%40googlegroups.com.

[pbzcbf...@gmail.com]

I'm assuming that Arch 7 is not yet supported by Ace and MRT. If so, then you have found a way to crack this firmware !!!

An SA dump of the SAS drive would be really enlightening.

Photos of the PCBs would help to determine what to look for.

[jol qwerr]

try mod47tool.exe

[Alandata Recovery]

This is SAS 1848

It would not hot swap

5025 would hotswap

Brian has pc3000 sas and I sent him the drive 5025

Here are some pics and the rom i read with a chip-clip

On Sat, Mar 12, 2022 at 3:10 PM jol qwerr <qjol...@gmail.com> wrote:

try mod47tool.exe

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAKfZW8WMTDM-1NV41MnYaBEiKtxQEZm0N9xqMzDQC2NNZ9ePqw%40mail.gmail.com.

--

Alandata Data Recovery -  (949)287-3282  

[Alandata Recovery]

here is a share to a folder

hi-rez pics

sata is 1079

sas is 5025

full resource backup of 1079

full resource bu of 5025 after I hotswapped sata board to the sas drive

I ran search for modules

then use dir in utility

then ran all the backups and reports that I could

https://drive.google.com/drive/folders/1mak8vReK09Z1RzAKyXXS4H1P9j-NcnVG?usp=sharing

[pbzcbf...@gmail.com]

I examined wd2000FYYZ1079-SATA_WD1001FYYG_SAS_5025hotswap.zip

I drilled down to WDC WD2000FYYZ-01UL1B1-01-01K02-WD-WMC1P0221079WD1001FYYG_SAS_5025hotswap\Data\SAAutoBackup\Modules\Copy0\

In module 0xC5 I found a reference to the "KOJN_RE" family.

In module 0x02 I found ...

• S/N = WD-WMC1P0065025
• M/N = WDC WD2000FYYZ-01ZY8B1
• manf date = 01-25-2014

WD's warranty status checker identifies S/N WMC1P0065025 as ...

• WD1001FYYG-01SL3W1
• VERDI_RE
• 7200 RPM
• 32M cache
• SAS-6
• 1.0TB
• 3HD
• RE (RAID EDITION) S
• expiry 21-Jun-2019

What is going on :-???

In ROM dump W2wd1001fyyg_sas_5025.BIN I see a model and serial that matches the warranty checker:

• WD-WMC1P0065025
• WD1001FYYG-01SL3W1
• WDC WD1001FYYG-01D5VW1

However, the ROM only parses correctly when the section in the range 0x40000 - 0x7FFFF is cut out. :-???

[pbzcbf...@gmail.com]

In ROM dump W2wd1001fyyg_sas_5025.BIN I can extract two copies of ROYL module 0x47. However, neither has a valid checksum.

I can see the microjogs:

Offset(h) 00   02   04   06   08   0A   0C   0E

00000240                                2811 4711
00000250  1F11 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A 0A0A

These are the preamp values:

Offset(h) 00   02   04   06   08   0A   0C   0E

00000220            1429 C510 1829 A60C 0F2B A510
00000230  0630 C614 0630 C614 0630 C614 0630 C614
00000240  0630 C614 0630 C614 0630 C614

[Alandata Recovery]

Ok so I booted the sata 

started the utility

it detects as the sata RE KOJN

put it in standby

hotswapped board

then searched SA for modules

It started finding modules which it saved in modules\fromimg

Those are for sure from the SAS drive

and anything timestamped after that point is also from the SAS drive

I am not sure when the  \SAAutoBackup\Modules\Copy0\ folder was generated

its possible its got an earlier timestamp and is from the sata drive

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/692240bd-d2df-4fcb-91f0-3e94ac50643dn%40googlegroups.com.

[Alandata Recovery]

its going to be hard to transfer the microjogs if we cant fix the checksum

[jol qwerr]

realc the CS is easy

the question is y is the CS corrupted in the first place

[pbzcbf...@gmail.com]

I get the same modules when I drill down to WDC WD2000FYYZ-01UL1B1-01-01K02-WD-WMC1P0221079WD1001FYYG_SAS_5025hotswap\Data\Modules\FromImg\

Also, module 0x109 contains a 512KB ROM image from an earlier Marvell ROYL architecture (not Arch 7). :-???

Is it possible that the VERDI_RE SAS drive is just a KOJN_RE SATA drive underneath???

FWIW, here are the SMART data:

 ID  Flg   Cur  Wor  Thr  Raw             Description
-----------------------------------------------------------------------------
  1   2F     1    1  200  00000000005ABF  Raw Read Error Rate
  2  *A4   100  253    0  00000000000000  Throughput Performance
  3   27   200  163    0  0000000000136F  Spin Up Time
  4   32   100  100    0  00000000000048  Start/Stop Count
  5   33   187  187    0  00000000000196  Reallocated Sector Count
  7   2E   200  200  200  00000000000000  Seek Error Rate
  8  *A4   100  253    0  00000000000000  Seek Time Performance
  9   32    16   16    0  0000000000F25B  Power-On Hours Count
 10   32   100  253    0  00000000000000  Spin Retry Count
 11   32   100  253    0  00000000000000  Drive Calibration Retry Count
 12   32   100  100    0  0000000000002A  Drive Power Cycle Count
180  *AE   200  200    0  00000000000000  Unknown Attribute
183   32   100  100    0  00000000000000  SATA Downshift Error Count
184  *B2   100  100    0  00000000000000  End to End Error Det/Corr Count
187  *B2     1    1    0  00000000022AC9  Reported Uncorrectable Errors
188  *B2     1    1    0  00001684A0FFFF  Command Time Out
190  *A2    63   50    0  00000000000025  Airflow Temperature
191  *B2    50   50    0  00000000000032  Shock Sense
192   32   200  200    0  0000000000001D  Emergency Retract Cycle Count
193   32   200  200    0  00000000000030  Load/Unload Cycle Count
194   22   113  100    0  00000000000025  HDA Temperature
195  *B6   200  200  200  00000000000000  ECC on the Fly Count
196   32     9    9    0  000000000000BF  Reallocated Sector Event
197   32   198  197    0  000000000003A8  Current Pending Sector Count
198   30   200  200    1  00000000000002  Offline Uncorrectable Sector Count
199   32   200  200    0  00000000000002  UltraDMA CRC Error Rate
200   08   200  200  200  00000000000004  Multi Zone Error Rate
240  *B2    22   22    0  0000000000DF6C  Head Flying Hours
241  *B2   200  200    0  00001DCCE2B03C  Total LBAs written
242  *B2   200  200    0  00003D684E2E78  Total LBAs read

     * = hidden attribute

[pbzcbf...@gmail.com]

If you run my new ROM parsing tool against the SAS ROMs (after cutting the area between 0x40000 - 0x7FFFF), the tool will extract the ROYL modules. If you examine them with a hex editor, you'll see why they don't look right. In fact it's hard to tell where each module ends. You can do the same thing by using a hex editor to look for "ROYL" test strings in the ROM dumps.

[Alandata Recovery]

yes i suspect the sas is mainly a board change

the drives look identical

i bet the heads might be the same - the hotswap worked....

module 108 of the sata contains 700J4

                              sas contains  700PD

it looks like the rom is compressed

the copy in 109 looks compressed also

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/6efed4ac-d9cf-4200-a069-972ed7a15d5fn%40googlegroups.com.

[pbzcbf...@gmail.com]

SATA uses ATA commands whereas SAS uses SCSI commands. These differences could be stored in the ROM and loader. Many of the other SA modules could be common to both. SCSI does have mode pages, though. SATA has SMART logs.

I wonder if we could use SAS modules 0x109 and 0x40 (-> 0x47) to regenerate a SATA ROM? Then you could write this ROM to a SATA PCB. Perhaps this will then enable access to the UA?

Are the above SMART data consistent with the SAS stats? For example, the Power-On Hours Count is 0xF25B (62043). That's 7.08 years.

[pbzcbf...@gmail.com]

Can you use PC3K to regenerate module 0x47 from SAS module 0x40? We could then examine the microjogs in module 0x47 to see if they match the microjogs in the SAS ROM. This will then give us some confidence in regenerating a SATA ROM.

[Alandata Recovery]

so I am looking at mod 02 in fromimg

that module was read from the sas drive

but it has the model number of the sata

and the serial number of the sas

how does that happen ?

On Sat, Mar 12, 2022 at 10:50 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Can you use PC3K to regenerate module 0x47 from SAS module 0x40? We could then examine the microjogs in module 0x47 to see if they match the microjogs in the SAS ROM. This will then give us some confidence in regenerating a SATA ROM.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/94e51b82-4584-4a96-af23-7b6105726151n%40googlegroups.com.

[pbzcbf...@gmail.com]

The model number suffix is not the same as the SATA drive, nor does the manufacture date correspond to either drive. That leads me to suspect that this is original data. Either that, or you messed up your folders somehow.

[pbzcbf...@gmail.com]

Does the SAS drive still ID correctly as before, or has it inherited a new ID?

[Alandata Recovery]

I dont have the sas drive that will hotswap 

I sent it to brian at 300

he has the pc3k-sas

he will need to answer some of these questions

After I did the hotswap - I never wrote anything to the sas drive using the sata board

I didnt want to risk corrupting it

it would be a good trick if we could convert a sata board to read a sas drive by adapting the rom

On Sat, Mar 12, 2022 at 11:08 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Does the SAS drive still ID correctly as before, or has it inherited a new ID?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/66d5064c-23c8-47a5-bf66-3a86fa7f86dbn%40googlegroups.com.

[pbzcbf...@gmail.com]

I'm wondering whether it was necessary to hotswap the SATA PCB. Did you try starting from the SATA PCB on the SAS drive?

[Alandata Recovery]

yes

powered sas with sata board and no access

i even tried loading loader and dir from files

no access

On Sat, Mar 12, 2022 at 11:29 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

I'm wondering whether it was necessary to hotswap the SATA PCB. Did you try starting from the SATA PCB on the SAS drive?

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/2fcae2c7-b163-4c39-9d1e-94b7a3044fb8n%40googlegroups.com.

[Alandata Recovery]

the picture of the sas drive is one of the sisters from the raid

1848 can be read but it has slow responding problem

less than 1mb/s

I tried hotswapping with several fyyz type wd drives

none would access sa

5025 is a sas drive that I need to image and the hotswap worked from sata-1079 to sas-5025

Brian has pc3k-sas

he says H0 is not reading well, like 1 sector/s

we did a head swap

we are hoping that the adaptives / microjogs can make it readable

just need to figure out how to adjust adaptives

thanks for your help

Awesome!

[pbzcbf...@gmail.com]

I know how to transfer 0x47 adaptives from one SAS ROM to the other. However, I can't find any checksum in the adaptives area of the ROM, so I'm thinking that there may not be any. What is stopping me from proceeding is my lack of confidence in the integrity of your ROM dumps. It seems to me that your programmer is reading 0x40000 bytes of data, then injecting 0x40000 bytes of 0xFF, then reading  0x40000 additional bytes of data, and so on. If Brian can provide a dump that tallies with my expectations, then I'll try an adaptives transfer.

[Alandata Recovery]

Here is a link to roms that Brian made

https://slack-files.com/T041AF3B4-F036KE4BZ6J-871fe773dd

Shouldnt you also be able to get room image from 109?

At least compare them

On Sun, Mar 13, 2022, 12:02 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

I know how to transfer 0x47 adaptives from one SAS ROM to the other. However, I can't find any checksum in the adaptives area of the ROM, so I'm thinking that there may not be any. What is stopping me from proceeding is my lack of confidence in the integrity of your ROM dumps. It seems to me that your programmer is reading 0x40000 bytes of data, then injecting 0x40000 bytes of 0xFF, then reading  0x40000 additional bytes of data, and so on. If Brian can provide a dump that tallies with my expectations, then I'll try an adaptives transfer.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/57ea2686-263b-49ff-a632-acbd5d80c65an%40googlegroups.com.

[pbzcbf...@gmail.com]

0x109 is a ROM image for a different architecture. That's what puzzles me.

Brian's ROM images don't seem right either. If you parse them with my tool, you'll see what I mean.

[Alandata Recovery]

What did you notice about the sas board from the picture

On Sun, Mar 13, 2022, 12:18 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

0x109 is a ROM image for a different architecture. That's what puzzles me.

Brian's ROM images don't seem right either. If you parse them with my tool, you'll see what I mean.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/515857f6-9e8d-4ab2-8d5a-c9d7806b4476n%40googlegroups.com.

[pbzcbf...@gmail.com]

The SATA PCB has twice as much RAM capacity, even though there is only one chip versus two on the SAS PCB..

W9712G6JB, Winbond, 128Mbit DDR2 SDRAM, 2M words ×4 banks ×16 bits, 1.8V, WBGA-84:
http://c1170156.r56.cf3.rackcdn.com/UK_WND_W9712G6JB-25_DS.pdf

NT5TU32M16DG-AC, Nanya, 512Mbit DDR2 SDRAM, 8M x 4 banks x 16, 1.8V, BGA-84:
https://www.datasheet.directory/pdfviewer?url=https%3A%2F%2Fdatasheet.iiic.cc%2Fdatasheets-1%2Fnanya_technology%2FNT5TU32M16DG-AC.pdf

Both PCBs use the same motor controller.

The label on the SATA drive has a DCX number which is consistent with a family code of ZY8. That matches the model number in SA module 0x02 of the SAS drive (WDC WD2000FYYZ-01ZY8B1).

The label on the SAS drive has a DCX number which is consistent with a family code of D5V.

[pbzcbf...@gmail.com]

This is what I mean about the ROM dumps being bad.

Bad (?) ROM dump

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

0003FFD0  3B B4 6E 60 F4 2B CE AA C7 7F C3 D9 C3 A5 42 0F
0003FFE0  C7 5B 10 E8 A8 B8 B8 1B 5A DB 85 89 1D 20 EE 1C
0003FFF0  5F 8E E8 65 9A 56 06 39 FB 0C A5 08 F5 4C 3B A2
00040000  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF --.
00040010  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   |
........                                                    | -- need to cut this block of 0x40000 x 0xFF bytes out of the ROM
0007FFE0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF   |
0007FFF0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF --'
00080000  78 78 2B EF 5F 77 73 B5 83 93 39 44 94 C2 A7 E7
00080010  BC FF 1C D7 0D E6 59 3F 20 6D 7F DA FE DB E4 ED
00080020  BC 30 E4 FF 4D 07 F9 71 A2 50 6D F7 62 23 8C 15

Repaired (?) ROM dump

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

0003FFD0  3B B4 6E 60 F4 2B CE AA C7 7F C3 D9 C3 A5 42 0F
0003FFE0  C7 5B 10 E8 A8 B8 B8 1B 5A DB 85 89 1D 20 EE 1C
0003FFF0  5F 8E E8 65 9A 56 06 39 FB 0C A5 08 F5 4C 3B A2
00040000  78 78 2B EF 5F 77 73 B5 83 93 39 44 94 C2 A7 E7
00040010  BC FF 1C D7 0D E6 59 3F 20 6D 7F DA FE DB E4 ED
00040020  BC 30 E4 FF 4D 07 F9 71 A2 50 6D F7 62 23 8C 15

Parsing "wd" headers and data blocks ...

ID Atts Next_wd  Curr_wd  RAMaddr  Decomprs Compress ???????? ???? ?? CS csum exp/actual
-- ---- -------- -------- -------- -------- -------- -------- ---- -- -- --------/--------
wd 0001 00006E84 00002260 0800B000 000061D4 00004C20 00000000 0000 00 A9 0027E7C1 0027E7C1  OK
wd 0001 0001C67C 00006EA4 FFE1D800 0001F32C 000157D4 00000000 0000 00 35 00B3ED8F 00B3ED8F  OK
wd 0001 00021320 0001C69C 00000000 00006190 00004C80 00000000 0000 00 31 00281224 00281224  OK
wd 0001 00023F50 00021340 000401E0 00003854 00002C0C 00000000 0000 00 6B 001702B4 001702B4  OK
wd 0001 00026E70 00023F70 081BC800 000070F8 00002EFC 00000000 0000 00 EA 0017DBAA 0017DBAA  OK
wd 0001 00026F48 00026E90 18016000 00000204 000000B4 00000000 0000 00 C8 00005439 00005439  OK
wd 0001 0004A448 00026F68 08063000 0002FF64 000234DC 00000000 0000 00 5A FFFFFFFF 0174D8A8  BAD  <-- before edit

After editing the ROM, this is what my tool produces:

Parsing "wd" headers and data blocks ...

ID Atts Next_wd  Curr_wd  RAMaddr  Decomprs Compress ???????? ???? ?? CS csum exp/actual
-- ---- -------- -------- -------- -------- -------- -------- ---- -- -- --------/--------
wd 0001 00006E84 00002260 0800B000 000061D4 00004C20 00000000 0000 00 A9 0027E7C1 0027E7C1  OK
wd 0001 0001C67C 00006EA4 FFE1D800 0001F32C 000157D4 00000000 0000 00 35 00B3ED8F 00B3ED8F  OK
wd 0001 00021320 0001C69C 00000000 00006190 00004C80 00000000 0000 00 31 00281224 00281224  OK
wd 0001 00023F50 00021340 000401E0 00003854 00002C0C 00000000 0000 00 6B 001702B4 001702B4  OK
wd 0001 00026E70 00023F70 081BC800 000070F8 00002EFC 00000000 0000 00 EA 0017DBAA 0017DBAA  OK
wd 0001 00026F48 00026E90 18016000 00000204 000000B4 00000000 0000 00 C8 00005439 00005439  OK
wd 0001 0004A448 00026F68 08063000 0002FF64 000234DC 00000000 0000 00 5A 0126F7D4 0126F7D4  OK  <-- after edit
wd 0003 00000000 0004A468 081B5800 000028D8 0000176C 00000000 0000 00 EC 000C108D 000C108D  OK

Extracting ROYL blocks from adaptive section at 0x78000 ...

  offset      size    ID
--------  --------  ----
000798DC  00001CCC  0047
0007B5A8  00000309  0E61
0007B8B1  00000239  0E00
0007BAEA  00001E6F  0E00
0007D959  00001CCC  0047
0007F625  0000028C  0E61
0007F8B1  0007874F  0E00

[Alandata Recovery]

Brian provided room dumps of patient and donor.

Do they show the same structure?

I think my rom dumps and Brian's are the same.

He may have created his with the pc3k sas utility.

If I saved the ROM after the hot swap then that would be the ROM of the SATA board, I would not have intentionally done that.

I read the ROM from the sas board with a chip clip. 

Thanks for all your analysis you are amazing.!

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/59b03489-1ff1-448a-b056-ea5620abecf5n%40googlegroups.com.

[Alandata Recovery]

Since you're interested in funny ROM facts and features....

I had a charger or Palmer spyglass USB board when I read the ROM it was 1 MB.

When I tried to write it to my SATA compatible version it refused because it was expecting a 512 meg ROM.

But I looked at the one mag ram and noticed that the first 512 seem to be a duplicate of the last 512 so I cut it in half and wrote it to the SATA and I board and it worked.

Another thing that I've encountered is Seagate ST 8000 DM boards.

If you read the ROM and generate a checksum then repower the drive and reread the ROM you will get a different check some.

But if you remove the board from the drive and repeat that you get the same consistent checksum.

So it appears the Seagate is rewriting the ROM every time the drive is repowered.

That seems like a really bad idea.

[pbzcbf...@gmail.com]

I have seen some Seagate SMR models that store data in the "extra space" at the end of the ROM. Some of these data are SMART attributes.

https://forum.hddguru.com/viewtopic.php?f=1&t=41678&p=293751#p293751

Other models modify the UDSBFW and CELOG (Critical Event Log) ROM segments.

I confess I don't understand why the ROMs don't make sense. I will just go ahead and patch the donor microjogs, preamp values and read channel adaptives into the patient ROM, using Brian's ROM dumps. In fact Brian's dumps and your dumps are the same.

It would be nice to see a full SA dump from PC3000 SAS. That would resolve the confusion relating to the funny model number in module 02.

BTW, the adaptives section in your SAS ROM is divided into two halves, each with a "WDFF" header. There are significant differences between the two halves, so I don't understand what is going on. Nevertheless I will patch the same microjogs, et al, into both halves. I don't see a checksum, so be prepared for failure.

[pbzcbf...@gmail.com]

Here is my analysis of your SATA ROM. The two halves are similar, but contain two different firmware versions, most probably due to an upgrade, either in the field or at the factory. Note that the first half has a boot block at offsets 0x0 - 0xFFF. The second half stores module 0x0D in the corresponding space, 0x80000 - 0x80FFF. I have no idea what module 0x0D does, or whether it is unique, or how to regenerate it if it is unique.

Analysing ROM_07-J2E_07-J4E_02-09_1079.bin ...

Searching for LDSCs and verifying PCMBlocks ...

LDSC   LDSC    Att   PCMBlock          RAM         size      PCMBlk CS
Start  ID CS        Start -  End     address     RAM / ROM    Exp/Act
-----  -- --   --   -----   -----   --------   ------ -----  ---------
    0  5A 75   04      20 -   FA1       1000      F80   F80  755E 755E   OK
 1000  01 FC   04    1120 -  37C4      12498     26A4  26A4    67   67   OK
 1020  02 90   0C    37C5 -  3DA5   88800000      5E0   5E0    94   94   OK
 1040  03 AF   01    3DA6 -  BF4A          0 c   A624  81A4    5C   5C   OK
 1060  04 33   01    BF4B -  C63F      11AF0 c    968   6F4    07   07   OK
 1080  05 FF   03    C640 -  C85C      80320 c    2D4   21C    F8   F8   OK
 10A0  06 94   03    C85D -  CB31   10174600 c    594   2D4    70   70   OK
 10C0  07 D1   01    CB32 - 265B2   101DB200 c  225DC 19A80    2A   2A   OK
 10E0  08 55   01   265B3 - 43533   1000B230 c  2CA1C 1CF80    09   09   OK
81000  01 FC   04   81120 - 837C4      12498     26A4  26A4    67   67   OK
81020  02 90   0C   837C5 - 83DA5   88800000      5E0   5E0    94   94   OK
81040  03 A7   01   83DA6 - 8BF46          0 c   A624  81A0    01   01   OK
81060  04 61   01   8BF47 - 8C667      11A94 c    99C   720    23   23   OK
81080  05 27   03   8C668 - 8C884      80320 c    2D4   21C    8D   8D   OK
810A0  06 C4   03   8C885 - 8CB5D   10174600 c    594   2D8    9C   9C   OK
810C0  07 BC   01   8CB5E - A666A   101DB200 c  22680 19B0C    9A   9A   OK
810E0  08 B1   01   A666B - C36B7   1000B230 c  2CB24 1D04C    AA   AA   OK

LDSC   = PM Loader Config String (32 bytes)
ID     = ID byte of LDSC (byte #0)
CS     = Checksum byte or word
Att    = Attributes
PCMBlk = Program Code Memory Block
Exp    = Expected checksum for PCMBLock
Act    = Actual checksum for PCMBLock
c      = compressed PCMBlock
size   = size of decompressed (in RAM) and compressed (in ROM) PCMBlock in bytes


ROYL directory module 0x000B found at 0x7FADE

Active directory flag = 0x05

Identifying SA regions ...

Reg#    Reg size     Reg loc
----  ----------  ----------
0x00  0x0005A000  0x00000000
0x01  0x0005A000  0x00078000
0x02  0x0005A000  0x000F0000
0x03  0x0005A000  0x00168000
0x04  0x0005A000  0x001E0000
0x05  0x0005A000  0x00258000

Verifying ROYL modules ...

 ID          Size (bytes)         Address    Checksum
 dir   hdr        dir       hdr
----  ----   --------  --------   --------   --------
0001  N/A    00003000  N/A        0002302D             N/A
000A  OK     0000004E  00000200   0007F000   00000000  OK
000B  OK     00000129  00000200   0007FADE   00000000  OK
020B  OK     00000129  00000200   0007EADE   00000000  OK
0030  OK     00000400  OK         000FF000   00000000  OK
0047  OK     00000600  OK         0007F4DE   00000000  OK
000D  OK     00000090  00000200   0007F04E   00000000  OK
004F  OK     00000400  OK         0007F0DE   00000000  OK
005D  OK     00001000  OK         00080000   00000000  OK

ROYL directory module 0x020B found at 0x7EADE

Active directory flag = 0x04

Identifying SA regions ...

Reg#    Reg size     Reg loc
----  ----------  ----------
0x00  0x0005A000  0x00000000
0x01  0x0005A000  0x00078000
0x02  0x0005A000  0x000F0000
0x03  0x0005A000  0x00168000
0x04  0x0005A000  0x001E0000
0x05  0x0005A000  0x00258000

Verifying ROYL modules ...

 ID          Size (bytes)         Address    Checksum
 dir   hdr        dir       hdr
----  ----   --------  --------   --------   --------
0001  N/A    00003000  N/A        00047F62             N/A
000A  OK     0000004E  00000200   0007E000   00000000  OK
000B  OK     00000129  00000200   0007FADE   00000000  OK
020B  OK     00000129  00000200   0007EADE   00000000  OK
0030  OK     00000400  OK         000FF000   00000000  OK
0047  OK     00000600  OK         0007E4DE   00000000  OK
000D  OK     00000090  00000200   0007E04E   00000000  OK
004F  OK     00000400  OK         0007E0DE   00000000  OK
005D  OK     00001000  OK         00080000   00000000  OK

dir  -  Module ID/Size as reported in directory module (0x20B or 0x0B)
hdr  -  Module ID/Size as reported in module's header
N/A  -  Not Applicable
BAD  -  Module has invalid checksum. This may be due to non-existent module.

ROM modules saved to Flash_00\000Bmods and Flash_00\020Bmods

Active directory is 0x0B

Analysing active 0x0A module ...

Head map checksum (Expected / Actual) = 0x0000 / 0x0000 - OK
Number of heads (physical / in use) = 6/6
Head map #1 = 0x003F / 0b0000000000111111
Head map #2 = 0x003F / 0b0000000000111111

DCM = | N | B X E U 8 Z D
      : : : : : : : : : :
      : : : : : : : : : unknown
      : : : : : : : : top VCM
      : : : : : : : ACA
      : : : : : : bottom VCM
      : : : : : HSA
      : : : : media
      : : : preamp
      : : latch
      : base
      spindle motor

Analysing active 0x0D module ...

Firmware Version = 01.01K02
World Wide Name = 50014EE25EC6340D
Model Number = WDC WD2000FYYZ-01UL1B1                  
Serial Number =                    


Analysing active 0x4F module ...

ROM version = 000700P2

Analysing active 0x47 module ...

Preamp values
-----------
0  03305418
1  032E7328
2  032E711A
3  052C5316
4  042E7414
5  062C4416
6  00000000
7  00000000
8  00000000
9  00000000

Microjogs
-------
0  1193
1  1102
2  10C9
3  112E
4  10A8
5  104E
6  0A0A
7  0A0A
8  0A0A
9  0A0A

Head/Media DCM = EX

[pbzcbf...@gmail.com]

Sorry, I meant 0x5D, not 0x0D. (Why doesn't this forum have an edit facility?)

[Alandata Recovery]

Perhaps the second half copy of the ROM is a fallback ROM in case it fails to boot or fails to upgrade during a ROM upgrade.

Thanks for doing that analysis and helping us with this You've got some amazing tools going there! 

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/8ba4c82c-8266-420c-9efd-7d19455b5d9an%40googlegroups.com.

[pbzcbf...@gmail.com]

I notice that module 0x32 (in the SAS drive) is full whereas module 32(1).rpm is clear. This suggests that a "slow responding" fix was applied to the drive. Was this fix actually written to the drive, or was it merely written to the dump folder? I don't see any 02(1).rpm file, so this is confusing. Module 02 would normally be affected by the same fix.

[pbzcbf...@gmail.com]

See attachment. Good luck. The patient ROM now contains both copies of ROYL module 0x47 from the donor, each with a size of 0xA00 bytes.

[Alandata Recovery]

I didn't write anything to the drive I was afraid it would corrupt the drive with an alien board so no writing

I may have opened the slow responding window just to see if it would interpret it correctly but I would have canceled it

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/73633d34-a8f1-470e-869f-ee02d5b5b18an%40googlegroups.com.

[pbzcbf...@gmail.com]

This version contains only the adaptive data, not the entire 0x47 modules.

[pbzcbf...@gmail.com]

Just FYI, there is a barometric pressure sensor at U7, to the left of the HDA pads. WD's documentation never mentions these devices. I have a theory that if you were to fiddle with the output of this sensor, you could fool the drive into lowering the fly height.

On Sunday, March 13, 2022 at 7:22:48 PM UTC+11 Alandata Recovery wrote:

[wayne horner]

Pressure interesting....

So if it adjust flying height according to pressure

At sea level would be maximum pressure

densist air

If you go up in elevation then the pressure drops

the air becomes thinner

so now the heads flying height would need to be raised

so maybe fooling it into reading higher pressure would trick it into lowering the heads.

I read that drones use these for altitude detection

and they can discern 1/4 inch

Thats amazing that it can detect that

I wonder if it could be a drop detector

although seems an accelerometer would be more appropriate

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/adb4c429-b283-4425-b0d1-7230f0e237a6n%40googlegroups.com.

[pbzcbf...@gmail.com]

Accelerometers are completely different devices.

Digital accelerometers in 2.5" HDDs:
http://www.hddoracle.com/viewtopic.php?f=100&t=2637

[wayne horner]

cool

thanks for the link

I

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/d138a630-bf7e-40d3-b7f5-9b215b8ee76fn%40googlegroups.com.

[pbzcbf...@gmail.com]

I have been examining a Dell D1R5 firmware update for the WD1001FYYG (and the 2TB/3TB/4TB versions). It mostly consists of firmware modules which don't appear in your SAS SA dump. :-?

Module 0xF04 is a copy of the ROM (excluding the adaptives). There is no discontinuity at offset 0x40000. :-?

Module 0xF05 looks "ROM-like". However, it is too large to fit within the ROM, so it must be an SA module.

Module 0x108 is some kind of overlay (OVL). Perhaps this is the SAS loader ???

https://www.dell.com/support/home/en-au/drivers/DriversDetails?driverId=X1XDC (D1R4, A03, 26 Jun. 2013, Western Digital (SX800M) SAS 1TB/2TB/3TB/4TB 7.2K RPM)
https://dl.dell.com/FOLDER01416289M/2/SAS-Drive_Firmware_X1XDC_WN32_D1R4_A03.EXE

https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=cktr9 (D1R5, A03, 15 Jul. 2013, Western Digital (SX800M) SAS 1TB/2TB/3TB/4TB 7.2K RPM)
https://dl.dell.com/FOLDER01552888M/3/SAS-Drive_Firmware_CKTR9_WN32_D1R5_A03.EXE
https://www.dell.com/support/driver/en-us/driversdetails?driverid=952nw

https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=064c2 (D1R7, A03, 29 Jun. 2018, Western Digital (SX800M) SAS 1TB/2TB/3TB/4TB 7.2K RPM)
https://dl.dell.com/FOLDER02731748M/2/SAS-Drive_Firmware_064C2_WN32_D1R7_A03.EXE

https://www.ibm.com/support/pages/ibm-online-sassata-hard-disk-drive-update-program-contains-lenovo-drives-v12300-windows-ibm-systems (WD1001FYYG-23S, WD2001FYYG-23S to XA39)
https://www.ibm.com/support/pages/critical-update-ibm-online-sassata-hard-drive-update-program-v11403-2-microsoft-windows-ibm-systems-and-lenovo-x86-servers (WD1001FYYG-23S, WD2001FYYG-23S, WD3001FYYG-23S,WD4001FYYG-23S to XA35)

[pbzcbf...@gmail.com]

As I see it, the "hotswap" archive is a SATA resource dump, not SAS. All the model numbers refer to FYYZ, not FYYG.

I think it's a case of the wrong finger on the wrong key.

[pbzcbf...@gmail.com]

Correct me if I'm wrong, but PC3000 SAS is unable to access the SA in WD drives. If not, then what can it do?

https://www.acelaboratory.com/scsi6.php

Specialized utilities

IBM, Maxtor-Quantum, Fujitsu, HGST and Seagate Special utilities allow to test SAS HDDs in technological mode, to check and recover the service information.

If any errors are detected, these utilities use additional Vendor code list. This list provides details about the root cause of the found error. In many cases this helps to exactly define all possible ways of repairing the HDD and recovering data from it.

The Specialized utilities are used for testing and recovery of service information, modules, and configuration pages; recalculating (regenerating) of translator; testing of magnetic heads and surfaces with physical parameters; clearing of SMART, reset the counter of power cycles and working hours, HDD firmware uploading.

[Alandata Recovery]

The first thing I did after the hot swap

Was search sa for modules including nested

It scanned the sa and found lots of modules.

I then told it to save all extracted mods

It saves those in the 

Modules\fromimg

Directory

Those modules can only be from the sas drive

I then told it to use the dir in utility

Then ran all the backups and tests that I could

There is no way those modules in fromimg

Can be from the sata drive

If you look at mod 108

It's different between SATA and sas drives

The structure test was good also

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/70793882-2040-4bed-84ba-cdb95a0ba5e2n%40googlegroups.com.

[Alandata Recovery]

I ran search sa for modules

If f04 was there shouldn't it have been found?

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/80363283-b724-4a97-b44a-27fb82fee429n%40googlegroups.com.

[pbzcbf...@gmail.com]

I'm really confused. :-(((

Let me just confirm that these two archives are SATA and SAS resources. Is that right?

WDC WD2000FYYZ-01UL1B1-01-01K02-WD-WMC1P0221079_Mar12-2022.zip --> SATA resources

wd2000FYYZ1079-SATA_WD1001FYYG_SAS_5025hotswap.zip --> SAS resources

Module 0x108 in each of those resources has the same structure. They both look like SATA modules. However, module 0x108 in the firmware update is not a ROYL module -- it has an OVL header, not ROYL.

Module 0xF04 in the firmware update looks like an SAS ROM image. I don't know if this is an SA module, or maybe it is the actual ROM code. None of the other 0xFnn modules exist in your SAS SA dump.

[Alandata Recovery]

Correct

I gave you both dumps for comparison

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/87368f39-ceb5-42ca-b63f-da161ffa75b4n%40googlegroups.com.

[pbzcbf...@gmail.com]

I must be going crazy. 

The SAImg.smd SA dump contains numerous references to WMC1P0065025. WD's warranty page says "WD1001FYYG-01SL3W1, VERDI_RE, 7200, 32M, SAS-6, 1.0TB, 3HD, RE (RAID EDITION) S, 21-Jun-2019".

The 0_000000_368640.smd dump contains numerous references to WMC1P0221079. Your photo identifies this as a WD2000FYYZ SATA drive.

Both SA dumps contain numerous references to KOJN_RE. That's a SATA model. There are no references to VERDI or FYYG (SAS), only FYYZ (SATA). I don't get it. :-???

[pbzcbf...@gmail.com]

Here is part of the microjog section of module 0x40 in the  SAImg.smd SA dump. Notice that there are 6 populated heads and 4 unpopulated ones. This is a 2TB drive. A 1TB drive would have 3 populated heads.

Offset(h) 00   02   04   06   08   0A   0C   0E   10   12

007B9EE0                      6C11 4C11 3811 3611 4811 3D11
007B9EF4  0A0A 0A0A 0A0A 0A0A 5F11 3E11 3211 2211 3B11 1F11
007B9F08  6A0A 6A0A 6A0A 6A0A 5911 3511 2911 1C11 3611 1811
007B9F1C  7206 7206 7206 7206 4F11 2B11 2211 1211 2911 0F11
007B9F30  6C06 6C06 6C06 6C06 4511 2111 1611 0A11 2111 0711
007B9F44  6606 6606 6606 6606

[Alandata Recovery]

I swapped the heads between 2 of the sas drive and I think it has  6 heads

I will double check tomorrow 

The sata drive that initialized the board was 2tb.

So I initialized the sata board and started the utility

Its ID'd as the sata wd and named the profile after it

WDC WD2000FYYZ-01UL1B1-01-01K02-WD-WMC1P0221079       

I swapped the board and exited the utility and then reentered the utility

its still ID'd as the sata drive

It wanted to open the profile for the sata_1079

I appended the sas model and serial number to create a new profile

WDC WD2000FYYZ-01UL1B1-01-01K02-WD-WMC1P0221079WD1001FYYG_SAS_5025hotswap

Everything in this zip came from the hotswapped SAS drive

Of course any ROM reading is still the sata board

I scanned the saimg file

found lots of 5025'

but funny thing it shows a model number of wd2000FYYZ

Also notice that both saimg files contain this same models table

So the sas drive has a models table that references sata drives

Thanks for all your analysis

You have a lot of understanding of this

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/bd74d76d-d6f2-49a6-9a48-fe7a3e2e5dc6n%40googlegroups.com.

--

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, NAS, Linux, Tape, Disk, Forensics"

www.alandata.com   www.alandataRecovery.com

[pbzcbf...@gmail.com]

The W2wd1001fyyg_sas_5025.BIN SAS ROM contains two copies of module 0x47. The microjogs section shows 3 populated and 7 unpopulated heads.

Offset(h) 00   02   04   06   08   0A   0C   0E

000B9B20                      2811 4711 1F11 0A0A
000B9B30  0A0A 0A0A 0A0A 0A0A 0A0A 0A0A

warranty status -> WMC1P0065025, WD1001FYYG-01SL3W1, VERDI_RE, 7200, 32M, SAS-6, 1.0TB, 3HD, RE (RAID EDITION) S, 21-Jun-2019
warranty status -> WMC160151848, WD1001FYYG-01SL3W1, VERDI_RE, 7200, 32M, SAS-6, 1.0TB, 3HD, RE (RAID EDITION) S, 21-Jun-2019
warranty status -> WMC160150531, WD1001FYYG-01SL3W1, VERDI_RE, 7200, 32M, SAS-6, 1.0TB, 3HD, RE (RAID EDITION) S, 21-Jun-2019

WD's warranty checker reports 3 heads for each of the 1TB SAS drives.

I found this head map data in the SAS ROM.

The DCM is |F|ZXCUNZCUU.

The head map is 0x0038 = 0b0000111000 (0x003F = 0b0000111111)

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

00000000  1F 49 0A 01 40 00 40 0D 04 06 03 00 00 03 7C 46  .I..@.@.......|F
                                     ^^ ^^ 6 physical heads, 3 in use

00000010  7C 5A 58 43 55 4E 5A 43 55 55 00 00 00 00 00 00  |ZXCUNZCUU......
00000020  00 00 00 00 86 FB 38 00 3F 00 00 00 38 00 53 00  ....†û8.?...8.S.
                            ^^^^^ ^^^^^       ^^^^^

[pbzcbf...@gmail.com]

Something is wrong with the serial number for the WMC1P0065025 drive. The other serial numbers both begin with "WMC160". In fact I found that all  WD1001FYYG (and all 2TB?) examples I found on the Internet begin with  " WMC160".

https://i.ebayimg.com/images/g/7x4AAOSwOeFe3Fun/s-l1600.jpg

https://www.disctech.com/SCASite/product_images/WD1001FYYG_1000-2.jpg

https://i.ebayimg.com/images/g/ZZMAAOSwwNRa55Gd/s-l1600.jpg

http://img.everychina.com/nimg/3c/09/05cc96007b18853e1f1fb9688dca-600x600-0/7200_rpm_wd1001fyyg_wd_re_sas_6_gb_s_3_5_inch_1_tb_32_mb_hard_drive.jpg

https://78.img.avito.st/640x480/6297182978.jpg

Did this drive begin life as a 2TB, 6 head, SATA model, and was it subsequently recertified as a 3 head SAS model? If so, then this still doesn't explain why we can't find those specific SAS firmware modules that appear in the SAS firmware update.

[pbzcbf...@gmail.com]

Mystery solved?

Here is a WD2000FYYZ:

https://i.ebayimg.com/images/g/UG4AAOSwHPNbH93Y/s-l1600.jpg

The serial number begins with WMC1P0.

[pbzcbf...@gmail.com]

The SATA drive that was the basis for the hotswap was a 2TB model, presumably with a head map of 0b0000111111. The recertified SAS drive has a head map of 0b0000111000, but originally it was a SATA drive with a head map of  0b0000111111. This means that the patient drive originally had an SA on physical heads 0 and 1. Those are the heads that are being dumped by the 2TB SATA donor after a hotswap. The invisible SAS firmware modules are in the SAS SA on physical heads 3 and 4.

Does this make sense?

[pbzcbf...@gmail.com]

I just realised that my ROM patch won't work. That's because the donor and patient ROMs have different head maps.

Patient -> 0x38 -> 0b0000111000

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

000BB110                                            1F 49                .I
000BB120  0A 01 40 00 40 0D 04 06 03 00 00 03 7C 46 7C 5A  ..@.@.......|F|Z
000BB130  58 43 55 4E 5A 43 55 55 00 00 00 00 00 00 00 00  XCUNZCUU........
000BB140  00 00 86 FB 38 00 3F 00 00 00 38 00 53           ..†û8.?...8.S

Donor -> 0x1C -> 0b0000011100

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

000BB110                                            1F 49                .I
000BB120  0A 01 40 00 40 0D 04 06 03 00 00 03 7C 46 7C 42  ..@.@.......|F|B
000BB130  45 45 55 38 42 44 55 55 00 00 00 00 00 00 00 00  EEU8BDUU........
000BB140  00 00 DC FB 1C 00 3F 00 00 00 1C 00 48           ..Üû..?.....H

[pbzcbf...@gmail.com]

I think I can transfer the donor's adaptives for heads 3 and 4 into the same heads for the patient. That would leave only head #5 unmatched. Maybe tomorrow ...

[wayne horner]

This makes sense.

Brian mentioned 3 heads

That he could read 1 2

But 0 is very slow.

I am going to try the hot swap again

And test whether I can read sa from other heads

You are Sherlock Holmes

Good job

On Mon, Mar 14, 2022, 4:32 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

I think I can transfer the donor's adaptives for heads 3 and 4 into the same heads for the patient. That would leave only head #5 unmatched. Maybe tomorrow ...

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/4f1a5912-cf81-4794-a71e-ddb2ed730e9an%40googlegroups.com.

[Alandata Recovery]

Ok so I tried the hotswap again with SAS_1848 which would not hot swap

This time I tried SA search in all 6 SA regions

None of them would read

So maybe 5025 is an outlier.

One thing disk drive companies can do is downsize drives that dont pass

So maybe the drive was built to be a 2tb 6 head sata

but after testing they decided some of the heads or platters were weak

so they recertify it as a 3 head 1tb

When I first started working I was with a minicomputer company that

was buying priam 14 inch winchesters and rodime drives

We noticed that the 70gb drive had just as many heads and platters as the 36gb drive.

So we swapped the 70gb rom to the 36 gb drive and it worked.

We stopped ordering the 70gb drives...

Priam eventually figured it out and wasnt to happy with us.

Same trick worked with the rodimes.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/CAJEn65paFbfibawyPEpHuJ5FmwooDoqYASBOQBfDaeBw%2B_1BaA%40mail.gmail.com.

[pbzcbf...@gmail.com]

SMART module 0x21 in the SATA SA reports a Power On Time of 7+ years. This would suggest that the drive was returned from the field.

BTW, I think you mean MB, not GB, for the Priam and Rodime capacities.

[Alandata Recovery]

right MB

10 20 40 mb rodimes

they used a steel band and stepper motor to move the heads

one of the drives back then had a glass strip with the tracks etched into the glass

it used this as the positioner

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/f9996cbb-c61a-400e-8aa3-7baba494b793n%40googlegroups.com.

[Alandata Recovery]

just heard from brian and ace

Since SAS doesn't support WD, I can't provide any data from it (SA, ROM, etc).

I also heard back from Ace that it's not supported, nor can they help move microjog (or anything else). :(

So if we can move the microjogs then we are surpassing ace !

[pbzcbf...@gmail.com]

This is what I'm seeing in the two ROMs.

Donor head adaptives - head map 2,3,4

Offset(h) 00   02   04   06   08   0A   0C   0E

000B9B00  1C2B 8510 1729 A508 172D A60C 0630 C614
000B9B10  0630 C614 0630 C614 0630 C614 0630 C614
000B9B20  0630 C614 0630 C614 9010 3E11 4111 0A0A

000B9B30  0A0A 0A0A 0A0A 0A0A 0A0A 0A0A

Donor preamp values

1C2B 8510  logical head #0 / physical head #2
1729 A508  logical head #1 / physical head #3
172D A60C  logical head #2 / physical head #4
0630 C614
0630 C614
0630 C614
0630 C614
0630 C614

Donor microjogs

9010  logical head #0 / physical head #2
3E11  logical head #1 / physical head #3
4111  logical head #2 / physical head #4

0A0A
0A0A
0A0A
0A0A
0A0A
0A0A

0A0A


Patient head adaptives - head map 3,4,5

Offset(h) 00   02   04   06   08   0A   0C   0E

000B9B00  1429 C510 1829 A60C 0F2B A510 0630 C614
000B9B10  0630 C614 0630 C614 0630 C614 0630 C614
000B9B20  0630 C614 0630 C614 2811 4711 1F11 0A0A

000B9B30  0A0A 0A0A 0A0A 0A0A 0A0A 0A0A

Patient preamp values

1429 C510  logical head #0 / physical head #3
1829 A60C  logical head #1 / physical head #4
0F2B A510  logical head #2 / physical head #5
0630 C614
0630 C614
0630 C614
0630 C614
0630 C614

Patient microjogs

2811  logical head #0 / physical head #3
4711  logical head #1 / physical head #4
1F11  logical head #2 / physical head #5

0A0A
0A0A
0A0A
0A0A
0A0A
0A0A

0A0A

[wayne horner]

the head we are having trouble  with is 0

so it should be able to init itself using the current values for head 1

we have imaged heads 1 and 2

so if we can tweak just h0 to read then that would be awesome!

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/e23a14b9-a4cf-48fc-bb9a-d1fab4d4c50bn%40googlegroups.com.

[pbzcbf...@gmail.com]

Since physical heads #3 and #4 are common to both head maps, let's compare them.

Preamp values

Head    Donor       Patient
----   ---------   ---------
3      1729 A508   1429 C510
4      172D A60C   1829 A60C

Microjogs

Head    Donor      Patient
----    -----      -------
3       3E11       2811
4       4111       4711

It seems to me that the microjogs are very close, but the preamp values for physical head #3 (= logical head #0) differ significantly. Remember that the data are probably little-endian.

Note that the head numbering in module 0x47 is logical, not physical. At least that's the only interpretation that makes sense to me.

[pbzcbf...@gmail.com]

There is a third set of adaptives, but they're "read channel adaptives". I don't know if we should touch those. It could be that they are associated with the media or the read channel circuitry on the PCB, but I really don't know.

[wayne horner]

you are the expert 

You can build a couple of versions for us to test if you lie.

Thanks

Alandata Data Recovery -  (949)287-3282  
"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

On Mon, Mar 14, 2022 at 1:12 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

There is a third set of adaptives, but they're "read channel adaptives". I don't know if we should touch those. It could be that they are associated with the media or the read channel circuitry on the PCB, but I really don't know.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/954dd3d7-77b7-4597-b665-c3b396cac0b2n%40googlegroups.com.

[pbzcbf...@gmail.com]

Here is the patched patient ROM. I have not touched physical head #5 because there is no adaptive data for this head in the donor ROM. This attempt only modifies the preamp values and microjogs for physical heads #3 and #4.

[Alandata Recovery]

Awesome

Crossing fingers

On Mon, Mar 14, 2022, 3:19 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Here is the patched patient ROM. I have not touched physical head #5 because there is no adaptive data for this head in the donor ROM. This attempt only modifies the preamp values and microjogs for physical heads #3 and #4.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/30fae9f1-f4c7-4ace-8421-597dd4097288n%40googlegroups.com.

[Alandata Recovery]

ok so Brian tried the patched rom and here is what he said

We looked at the heads under the microscope and don't see any signs of crashing.

Tried. Still works, but h0 still seems the same (first sector bad, but reading in reverse ~1 sect/sec). I'm skipping 1000000 sectors on errors/loss of readiness in case there are good "spots" on the platter. But, I suspect platter damage. Especially since we now know this was essentially a refurbished SATA drive. Could take out platters and inspect them all (since we don't really know which belongs to h0 at this point), but the end result will be the same without doing this (that is: not getting back sectors from h0).

I'll check back in tomorrow to let you know if any parts of h0 read quickly.

--

Alandata Data Recovery -  (949)287-3282  

[pbzcbf...@gmail.com]

These are the read channel adaptives. Would it be worth trying to patch these? 

Patient

E0 2B 26 80 74 10 0F 0E 0F 0D 04 8A 0C 00 57 00 00 DA 65 80 01 03 03 23 56 06 0F 00 03 01 02 05 D0 09 00 00 00 84 3B 00 80 08 00 00 00 00 00 40 00 00  log head #0 / phy head #3
E0 2B 24 80 74 03 0F 0D 0F 0C 04 8A 0C 00 57 00 00 DA 61 80 01 03 04 23 56 04 0C FF 02 01 02 04 D0 09 00 00 00 84 38 00 80 08 00 00 00 00 00 40 00 00  log head #1 / phy head #4
B0 2B 1E 80 74 12 0F 0D 0E 0D 04 8A 0C 00 57 00 00 DA 53 80 00 02 02 1E 56 01 0E FF 03 FF 12 05 D0 09 00 00 00 84 29 00 80 08 00 00 00 00 00 40 00 00  log head #2 / phy head #5
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00

Donor

E0 2B 22 80 74 11 0F 0B 0D 0A 04 8A 0C 00 57 00 00 DA 4A 80 01 04 05 23 56 06 0B FF 02 00 02 05 D0 09 00 00 00 84 3A 00 80 08 00 00 00 00 00 40 00 00  log head #0 / phy head #2
E0 2B 28 80 74 01 0F 0D 0F 0B 04 8A 0C 00 57 00 00 DA 5F 80 01 04 06 23 56 10 0F 02 02 01 02 05 D0 09 00 00 00 84 39 00 80 08 00 00 00 00 00 40 00 00  log head #1 / phy head #3
E0 2B 28 80 74 01 0F 0A 0E 0A 04 8A 0C 00 57 00 00 DA 5D 80 02 05 07 28 56 08 0D FF 02 01 02 04 D0 09 00 00 00 84 3A 00 80 08 00 00 00 00 00 40 00 00  log head #2 / phy head #4
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00
C0 2B 20 80 74 00 0F 05 0F 05 04 8A 0C 00 57 00 00 DA 80 80 03 04 08 2D 56 0A 05 03 01 01 02 00 D0 09 00 00 00 84 20 00 80 08 00 00 00 00 00 40 00 00

[pbzcbf...@gmail.com]

Done.

[Alandata Recovery]

Thanks !

We will give them a try

Looks like you figured out the checksum issue

On Tue, Mar 15, 2022 at 10:42 AM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Done.

On Wednesday, March 16, 2022 at 4:34:57 AM UTC+11 pbzcbf...@gmail.com wrote:

These are the read channel adaptives. Would it be worth trying to patch these? 

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/4d484ff9-4c27-400f-a697-3f714e424d8en%40googlegroups.com.

[pbzcbf...@gmail.com]

There is no checksum in the adaptives section of the ROM.

[pbzcbf...@gmail.com]

The only other possibility I can think of would be to write the patched patient ROM into the donor PCB, and then use the donor PCB on the patient. Then you would have the donor's preamp and read channel circuitry as well as the donor's adaptives for physical heads 3 and 4.

[pbzcbf...@gmail.com]

I found one additional adaptive section, but I don't know what it does. It exists in module 0x4F in a SATA ROM. This is not one of those cases where 0x4F is "unique".

This is the relevant part in your WD2000FYYZ SATA ROM. There are two sets of parameters. Each set consists of 10 words, one word per head. In this case there are 6 used heads, 4 unused.

6213 7513 2712 B212 9013 A112 0010 0010 0010 0010

BD37 8737 843B CA39 3C37 013A 8743 8743 8743 8743

These are your WD1001FYYG 3-head patient and donor ROMs:

7E12 B412 0513 0010 0010 0010 0010 0010 0010 0010

6D3A C639 D038 8743 8743 8743 8743 8743 8743 8743

7612 1E13 6612 0010 0010 0010 0010 0010 0010 0010

863A 8438 BA3A 8743 8743 8743 8743 8743 8743 8743

[pbzcbf...@gmail.com]

Here is another adaptive section in module 0x47 of the 2TB SATA drive. Each row corresponds to one head.

C413 92EA 63FE 8CF9 7DFF DE00 F8FF F5FF 5C00 11FF
55EA 48EE A601 70F8 5301 8100 87FF 31FF 2B00 6400
4603 97EE 5F01 B6FB 33FF CAFF DD00 7B01 1DFE 48FF
E7F6 66F8 70FF 64FA 1601 CEFF 7FFF BB00 EBFF A9FF
D10F CFE3 19FE 3FFB F1FF BE00 8DFF EBFF 4BFF CE00
15F8 7ED4 2A01 5EFD 4700 4B00 C400 6900 3100 0C00

This is the same section in both 1TB patient and donor. It is identical in both drives. I have no idea what these adaptives do, or why they are so different between SATA and SAS.

0000 24E4 0000 93FB 0000 0000 0000 0000 0000 0000
0000 24E4 0000 93FB 0000 0000 0000 0000 0000 0000
0000 24E4 0000 93FB 0000 0000 0000 0000 0000 0000

[pbzcbf...@gmail.com]

Is it possible that the SMART data in module 0x21 of head #0 of the patient was updated from the SMART data present in the PCB RAM after the hotswap? In other words, are we reading the patient's own SMART data from when it was a SATA drive, or are we seeing the SMART data transferred from the hotswap donor? This could cause serious problems if the SAS SA were on the same head.

[pbzcbf...@gmail.com]

There are several copies of a ROYL module with an ID of 0xE00 in your SAS 1TB ROM. The module consists of records which seem to mimic SA module 02 in a SATA Marvell ROYL architecture. I found two words in a different Arch 7 ROM that appear to reflect the default 7 second TLER read/write error recovery timeouts. Unfortunately your ROM doesn't appear to have the same parameters.

I suspect that one or more of the parameters may be able to switch off error recovery or sector sparing or SMART. Another parameter may be a PUIS setting (Power Up In Standby). I expect that one or more of the capacity parameters would change if a HPA were set.

In short, I think there is potential to experiment with these parameters to simulate a "slow responding" hack.

I explain the structure of this module here:

https://www.hddoracle.com/viewtopic.php?f=3&t=2762&p=22405#p22405

Rec#  Typ  Siz  Data (hex + ASCII) ...

----  --   --   ----------------------
0064  60   08   B0 6D 70 74 00 00 00 00 --> 1953525168 user LBAs --> 1TB capacity
0068  60   08   B0 6D 70 74 00 00 00 00 --> 1953525168 user LBAs --> 1TB capacity
0083  20   01   00
0000  60   08   50 00 0C 0F 01 E2 C9 AC --> WWN --> 50000C0F01E2C9AC
0001  60   14   57 44 2D 57 4D 43 31 50 30 30 36 35 30 32 35 20 20 20 20 20 --> "WD-WMC1P0065025     "
000D  20   01   03
0002  20   01   02
0003  20   01   02
0004  20   01   02
0005  20   01   01
0006  60   28   57 44 31 30 30 31 46 59 59 47 2D 30 31 53 4C 33 57 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 --> "WD1001FYYG-01SL3W1                      "
0007  60   28   57 44 43 20 57 44 31 30 30 31 46 59 59 47 2D 30 31 44 35 56 57 31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 --> "WDC WD1001FYYG-01D5VW1                  "
0008  60   08   B0 6D 70 74 00 00 00 00 --> 1953525168 user LBAs --> 1TB capacity
0050  60   08   00 00 00 00 00 00 00 00
000A  20   01   00
000B  20   01   00
000C  60   04   30 4B 07 00
0030  60   14   20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 --> "              "
0032  20   01   01
0045  20   01   01
007A  60   02   14 00
003C  20   01   01
003D  20   01   02
003E  20   01   07
003F  20   01   0D
0040  20   01   00
0041  20   01   03
0042  20   01   00
0043  20   01   00
0044  20   01   22
00BC  20   01   00
001D  60   08   57 44 20 20 20 20 20 20 --> "WD      "
006C  60   08   8B 24 E9 70 00 00 00 00
0060  20   01   00
007C  60   08   FF FF FF FF FF FF FF FF
007F  60   08   B0 6D 70 74 00 00 00 00 --> 1953525168 user LBAs --> 1TB capacity
0074  20   01   01
0076  20   01   00
0077  20   01   00
008A  60   02   01 00
0089  60   02   01 00
0086  20   01   00
0098  60   02   01 00
0099  60   02   3C 00 --> 60
0075  20   01   00
009C  20   01   00
0081  20   01   00
0079  20   01   01
0095  20   01   01
001C  60   04   56 52 30 37 --> "VR07" --> firmware version
00E3  20   01   01
00E4  20   01   00
00D1  60   02   20 1C --> 7200 --> RPM ?
002D  60   02   30 37 --> "07" --> day (?) of manufacture
002C  60   02   30 38 --> "08" --> month (?) of manufacture
002B  60   04   32 30 31 34 --> "2014" --> year of manufacture
0090  20   01   01
0091  20   01   01
0092  20   01   01
00C9  20   01   00
0063  60   08   B0 6D 70 74 00 00 00 00 --> 1953525168 user LBAs --> 1TB capacity

FFFF  FF   FF   FF --> terminator record

[wayne horner]

I have a second one of these with a slow responding problem.

Thts amazing analysis that you do,

thanks for sharing

Alandata Data Recovery -  (949)287-3282  

"Cleanroom Data Recovery of RAID, VMware, Network Attached Storage, Linux, Tape, Disk, Forensics"

www.AlanData.com   www.AlanDataRecovery.com

--

Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/136d2b11-0f05-4051-9ab5-fc507ce57e29n%40googlegroups.com.

[pbzcbf...@gmail.com]

Rec#  Typ  Siz  Data (hex + ASCII) ...
----  --   --   ----------------------

006C  60   08   8B 24 E9 70 00 00 00 00 --> number of user LBAs at 528 bytes per sector

[pbzcbf...@gmail.com]

I expect that those parameters which have a single data byte with a value of 00 or 01 are most likely disabling or enabling certain features.

[pbzcbf...@gmail.com]

If you upload the ROM of a "slow responding" test case, I could flip each of those 01 parameters to 00, and upload a different ROM image for each attempt. There are 9 possibilities. Don't be surprised if one ROM causes the drive to remain in standby. That could be the PUIS setting.

[pbzcbf...@gmail.com]

One more idea. When you are hotswapping, it might be worth modifying the adaptives on the hotswap donor so that they more closely match the patient. I'm proposing that we average the patient and donor adaptives and write them to the donor.

[Alandata Recovery]

You are awesome - I appreciate that

We have been able to image the needed drive 99.4%, with that and the one good drive we should have a good recovery

and the slow responding drive , we were able to read enough to find that it is stale and not needed.

Good to know that you have possible solutions.

Thanks

 

On Fri, Mar 25, 2022 at 1:02 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

One more idea. When you are hotswapping, it might be worth modifying the adaptives on the hotswap donor so that they more closely match the patient. I'm proposing that we average the patient and donor adaptives and write them to the donor.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/67a20632-3cc6-4560-9316-2488ac15c45an%40googlegroups.com.

--

Alandata Data Recovery -  (949)287-3282  

[pbzcbf...@gmail.com]

Are you going to try accessing the SAS SA on heads 3 and 4? If you could succeed with that, then you would make a name for yourself. I would be keen to dissect the modules.

I have been trying compare PCBs using the different architectures with a view to finding those HDAs that could possibly accept both PCBs. They would need to have the same HDA pinout (obviously), and preferably the same motor controller. I would be concerned that there may be cases where the motor would spin backwards.

[Alandata Recovery]

I can do some experiments when I get the drives back in a week or so

On Fri, Mar 25, 2022 at 2:28 PM pbzcbf...@gmail.com <pbzcbf...@gmail.com> wrote:

Are you going to try accessing the SAS SA on heads 3 and 4? If you could succeed with that, then you would make a name for yourself. I would be keen to dissect the modules.

I have been trying compare PCBs using the different architectures with a view to finding those HDAs that could possibly accept both PCBs. They would need to have the same HDA pinout (obviously), and preferably the same motor controller. I would be concerned that there may be cases where the motor would spin backwards.

--
Data Recovery Certification Group / for issue with google group please email sc...@myharddrivedied.com
---
You received this message because you are subscribed to the Google Groups "DataRecoveryCertification" group.
To unsubscribe from this group and stop receiving emails from it, send an email to datarecoverycertif...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/datarecoverycertification/ab332a95-a6ff-4a59-a39d-f643ad72d1cbn%40googlegroups.com.

[pbzcbf...@gmail.com]

My Arch 7 ROM parsing tool (WDnewROM2a.bas) now extracts the head map and DCM, and it now correctly handles those ROMs which have discontinuities at offset 0x40000.

[pbzcbf...@gmail.com]

Here is another Arch7 ROM:

http://files.hddguru.com/download/PC-3000-UDMA%20Support/WDC%20HPA%20family%20utility/Hilo/WD3001BKHG-70T36X0-R660xX_WD-WXB1E81KTFH7.rar

This one uses an older head map format (which requires another update to my tool), but it has an even weirder ROM structure in regard to the blank areas ("discontinuities"). The first half of the ROM is filled with 0xFF. When I strip off this part, I then find that there is an additional empty block of 0x4000 x 0xFF bytes before the adaptive section. This results in the adaptives being offset by 0x4000 bytes. If I now cut out this block and append an empty block to the end of the ROM, my tool then correctly parses the ROM sections. However, there is only one copy of the adaptives, whereas other ROMs have two copies, each with a "WDFF" header.

It seems as if WD's programmers are intentionally obfuscating the blocks.