Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
July 31st, 2017, 1:44
Does this help?http://forum.acelaboratory.com/viewtopic.php?t=8612
Test : Edit HDD ID (ROM)
Parsing container segment....... Flash ROM image
Parsing segment....... BOOTFLOADER
End parsing segment... BOOTFLOADER
July 31st, 2017, 17:11
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.
August 3rd, 2017, 14:43
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.
August 31st, 2017, 8:07
Well Frank And Ali ,
Here You Go With The Details Ali Wanted
Package Version: PH0G2D.CCD4.JQ019Y.CC49 , Package P/N: 100664709, Package Builder ID: P9,
Package Build Date: 03/07/2011, Package Build Time: 11:03:14, Package CFW Version: PH0G.CCD4.00337218.P900,
Package SFW1 Version: D289, Package SFW2 Version: ----, Package SFW3 Version: ----, Package SFW4 Version: ----
Controller FW Rev: 03071103, CustomerRel: CC49, Changelist: 00337218, ProdType: PH0G.CCD4, Date: 03/07/2011, Time: 110314, UserId: 00410638
Servo FW Rev: D289
RAP FW Implementation Key: 10, Format Rev: 0001, Contents Rev: A1 0A 1B 03
i get full id with proper capacity but any access to hdd makes it busy
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.
September 1st, 2017, 2:51
Attached is a CC49 loader (I hope).
- (178.46 KiB) Downloaded 64 times
Powered by phpBB © phpBB Group.