Does this help?

http://forum.acelaboratory.com/viewtopic.php?t=8612

_________________
A backup a day keeps DR away.

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.

_________________
A backup a day keeps DR away.

_________________
A backup a day keeps DR away.

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

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

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.

_________________
A backup a day keeps DR away.

Attached is a CC49 loader (I hope).

_________________
A backup a day keeps DR away.