Re: Tempered HDD Or Overlay Failure [ ST500DM002 ]

I compared the official CC49 PH0G2D section (offsets 0x38 - 0x60A47) with the client's and found a block of differences in the range 0x1BBD3 - 0x1D01F.

0x1d01f - 0x1bbd3 = 0x144C (5196)

As an experiment, I took a large text file (http://www.gutenberg.org/files/1257/old/1musk10.zip) and changed a single bit somewhere in the middle of the file. I then used WinRAR to separately compress each file. Comparing the two RARs with a hex editor showed differences in a block of approximately 0x8000 bytes in the middle of the RARs. These leads me to suspect that the client's PH0G2D section could have a difference in only a single byte, and this difference may reflect the enabling or disabling of a particular feature.

Re: Tempered HDD Or Overlay Failure [ ST500DM002 ]

5. For 7200.12 ST3500413AS, we need to write JC49 firmware, not CC49 firmware for most 7200.12 disk.

There is common fault of this disk, it can easily be in fake ready status when there is firmware problem. In this case, it is in ready status, but cannot enter terminal mode with capacity shown as 3.8GB.

As shown in figure:

In this fake ready status, we can fix it by writing factory firmware JCXX.

Re: Tempered HDD Or Overlay Failure [ ST500DM002 ]

September 1st, 2017, 2:28

Your drive's CFW (PH0G2D.CCD4.JQ019Y.CC49) and SFW (D289) package versions are consistent with Seagate's official Pharaoh CC49 firmware update (PH0G2D.CCD4.JQ019Y.CC49.D289). The only difference is a small section of the SFW1 (PH0G2D) component. I suspect that this difference may only amount to 1 or 2 bytes in the uncompressed code.

The fact that you encounter an "Unable to load Diag Cmd Processor Overlay" error when you invoke a terminal command would suggest that the user did not apply the CC49 update. I say this because the LOD file that is packaged with the update contains overlay 04, which AIUI is the Diag Cmd Processor Overlay. If you invoke a terminal command that is not supported by the ROM code, this overlay must then be loaded from the SA (it is not required for the normal operation of the drive). If the user had applied the CC49 update, then there would be no incompatibility.

ISTM that some DR shop patched the native adaptives into a CC49 ROM (with a patched SFW1 component), but did not update the SA overlay(s). The MRT Lab post suggests to me that CC49 factory (?) firmware is commonly used to gain access to the SA to circumvent firmware problems. Furthermore, MRT Lab appears to be saying that JC49 firmware, rather than CC49, should be used for this particular model.

ISTM that you could start with a CC49 loader and dump the SA. Then you could implement any necessary firmware fixes. Alternatively, use a JC49 ROM and loader.