Alternative ways to reflash ROM with SA-generated modules

[fzabkar]

Do the donor heads still work in the donor drive?

[transitNFCtech]

When I acquired the donor HDD on eBay (https://web.archive.org/web/20220718191644/https://www.ebay.ca/itm/393385823939), seller clearly indicated that the HDD is only for parts, not diagnosed, and assumed to be non-functional.

Here's what it's like when I just opened the S/A modules window with the donor HDD:

Displayed SERVO_ERROR_CODE_BASE_SvirCalRRO_Hd2

Here's what it's like after checking for ROM modules:

Like patient HDD, module 20 is highlighted red.

[fzabkar]

The donor is not functional, either. I can't understand why it's only reading the same module 0x20, though (the other modules are in the ROM). Can you upload module 0x20?

[transitNFCtech]

The donor is not functional, either. I can't understand why it's only reading the same module 0x20, though (the other modules are in the ROM). Can you upload module 0x20?

How do I dump 0x20, especially with WDMarvel Demo? Is it a file that I save?

[transitNFCtech]

I don't understand how you came to the conclusion that the original heads were bad. Anyway, that's a moot point now.

My tool requires SA modules 0x102 - 0x107 and 0x109. These modules contain the ROM components. However, these components are tuned to the patient's heads, so using them to rebuild the ROM is now pointless.

Another question regarding your tool and SA modules.

Since the modules are tuned to the patient's heads, if I used a donor's head to obtain the SA modules and then swapped back to the patient's heads, would your tool still view the obtained SA modules as if it's tuned to the patient's heads?

I recently obtained a functional donor HDD with working heads:

Functional Donor HDD

[transitNFCtech]

The donor is not functional, either. I can't understand why it's only reading the same module 0x20, though (the other modules are in the ROM). Can you upload module 0x20?

How do I dump 0x20, especially with WDMarvel Demo? Is it a file that I save?

0x20 is the SMART related module on the PLATTER and you won't be able to read it with heads that don't read the platter or if other modules are not properly loaded.

Please do outsource this drive to a reputable data recovery firm if data is needed.

Continuing to "play" with it will kill it for good (if the head swap didn't kill it for good already).

The 2 links that i posted is to explain how to gain access to SA on drives with BAD SA but with working heads.

That SMART module is on the platter and if the heads are gone it will not be readable and it would be the least of you problems.

If you follow the procedures on the links and heads are still working you should be able THEN to read the modules on the platters including that 0x20 one. But if heads are bad it won't work.

You are not supposed to get that module at all if you can't get the others on the platters as well.

Best regards.

I see, however, I am doing HDD repair more like a hobby side project. I cannot afford to outsource any professional data recovery firm even if the facility is nearby. I am prepared for the outcome where I am unable to successfully repair the HDD. I recently obtained a new donor HDD, and tested and verified that it has functional heads.

Attachments

Donor HDD

S/N: WCAU40802263
MDL: WD10EAVS-00D7B0
DATE: 25-JUN-2008
DCM: DHRNHT2MFB
R/N: 701537

[transitNFCtech]

Sorry, all I'm saying is that the original problem may have been solved simply by removing the shorted 12V TVS diode (on the patient PCB). Of course, that is moot now.

You need to access the SA and dump the required modules. Hopefully, WDMarvel and your donor PCB can do this. WDMarvel should also be able to regenerate the ROM. However, when I went through this process with another user, we found that WDMarvel had a bug. Instead, I wrote my own tool to rebuild the ROM.

http://users.on.net/~fzabkar/FreeBasic_W32/WD/wdROMreg.bas
http://users.on.net/~fzabkar/FreeBasic_W32/WD/wdROMreg.exe

When I obtained the modules from WDMarvel, this is what it looks like:

Screenshot of folder content

This is what I attempted so far on another computer with a new folder location and after renaming the .mod files:

Code:

Microsoft Windows [Version 10.0.22621.1555]
(c) Microsoft Corporation. All rights reserved.

C:\Users\ostkk>J:

J:\>cd WD_ROM_Tool

J:\WD_ROM_Tool>wdROMreg.exe

This program regenerates a WD ROM using SA modules 0x102, 0x103, 0x104, 0x105, 0x106, 0x107 and 0x109.
The user must specify the source directory for the SA modules and the name of the ROM output file.
The program will look for SA file names and extensions such as 0109, 109, .rpm, .mod and .bin.

Usage:  WDROMREG dir=module_dir_path[\] romfil=rom_file_name

Example1:  WDROMREG DIR=C:\downloads\wd\firmware romfil=ROM.bin
Example2:  wdROMreg dir="d:\wd firmware\" ROMFIL="ROM 1.bin"


J:\WD_ROM_Tool>wdROMreg dir="J:\WD_ROM_Tool\Patient - WCAU40285619\Copy from SA" ROMFIL="WCAU40285619.bin"
SA module 0x102 not found -- program aborted.


J:\WD_ROM_Tool>wdROMreg dir="J:\WD_ROM_Tool\Patient - WCAU40285619\Copy from SA" ROMFIL="WCAU40285619.bin"
SA module 0x102 found at 102.mod
SA module 0x103 found at 103.mod
SA module 0x104 found at 104.mod
SA module 0x105 found at 105.mod
SA module 0x106 found at 106.mod
SA module 0x107 found at 107.mod
SA module 0x109 not found -- program aborted.


J:\WD_ROM_Tool>

Since the program is looking for [0]10# (e.g. 0109.mod/109.mod), what is module 109? Is it a .mod file or is it a different file type instead?

[fzabkar]

Module 0x109 is basically a copy of the ROM code with templates for the adaptive components.

Can you upload the other 0x10? modules? We may be able to find a compatible 0x109 in other resource dumps.

[transitNFCtech]

Module 0x109 is basically a copy of the ROM code with templates for the adaptive components.

Can you upload the other 0x10? modules? We may be able to find a compatible 0x109 in other resource dumps.

I see. Anyway, I used a different method. I went back to WDMarvel and, with the donor head, I reobtained the SA modules via S/A operations >> Modules operations. The previous method I used to obtain the modules was from ROM >> Modules in ROM which the modules weren't in the 010#/10# filename format when I just read them and were saved in the PZU/Copy from SA folder. The new method works better for me as they were in the 010# filename format when I just read them, I got the 0109.mod file, all the required modules were saved in the Modules folder, and I was able to create a regenerated ROM file with the .mod files:

Code:

Microsoft Windows [Version 10.0.22621.1555]
(c) Microsoft Corporation. All rights reserved.

C:\Users\ostkk>J:

J:\>cd WD_ROM_Tool

J:\WD_ROM_Tool>wdROMreg.exe

This program regenerates a WD ROM using SA modules 0x102, 0x103, 0x104, 0x105, 0x106, 0x107 and 0x109.
The user must specify the source directory for the SA modules and the name of the ROM output file.
The program will look for SA file names and extensions such as 0109, 109, .rpm, .mod and .bin.

Usage:  WDROMREG dir=module_dir_path[\] romfil=rom_file_name

Example1:  WDROMREG DIR=C:\downloads\wd\firmware romfil=ROM.bin
Example2:  wdROMreg dir="d:\wd firmware\" ROMFIL="ROM 1.bin"


J:\WD_ROM_Tool>wdROMreg dir="J:\WD_ROM_Tool\Patient - WCAU40285619\Modules" ROMFIL="WCAU40285619.bin"
SA module 0x102 found at 0102.mod
SA module 0x103 found at 0103.mod
SA module 0x104 found at 0104.mod
SA module 0x105 found at 0105.mod
SA module 0x106 found at 0106.mod
SA module 0x107 found at 0107.mod
SA module 0x109 found at 0109.mod
Analysing SA module 0x109 -- J:\WD_ROM_Tool\Patient - WCAU40285619\Modules\0109.mod

Regerated ROM saved to WCAU40285619.bin


J:\WD_ROM_Tool>

After creating the ROM file and testing it, here is the test result:

ROManalysis.txt

Analysis text result

(3.31 KiB) Downloaded 203 times