DIY fail

[Markus Bauer]

Hello,

I get a drive where the client attempt a PCB swap and he also try to desolder the ROM chip. As he das no "fancy" hotair station on hand he wend with the mc gyver approach and used a hot air blower.

The result looks like that:

I dont want to try desoldering it anymore. So i will try to read it with spiderboard rippoff and what if that fails? is there anything I can do like genty heating, cooling, etc.?

I know sometime playing with temperature or voltage can help but in such case i am not sure what would be save. Or is there another approach?

[jol qwerr]

IMHO (from the way it looks) the chip is gone

To remove it you can use low melt solder

What drive are we talking about ?

[Markus Bauer]

It's a Seagate ST9500325AS (Momentus 5400.6).

On a WD one there is a way to recover the ROM from SA but on a Seagate I am not sure. 

[jol qwerr]

If you cant raad the adaptives its gonna b n expensive recovery

[jol qwerr]

read*

[Fraser Corrance]

What family is that drive from? 

There may be a way to rebuild the ROM. 

Fraser

On Friday, May 28, 2021 at 4:33:25 AM UTC-7 jol qwerr wrote:

read*

[Fraser Corrance]

I have had some success rebuilding the ROM on Seagate drives from the first half of the F3 generation. Grenada and later families don't seem to have these backup copies of the ROM files in the SA. Hepburn, Pharroh, and Muskie families have the easiest ROMs to rebuild using this method. If you take the PCB from a drive that meets the following matching criteria: 

• Model number

• Firmware version

• Country of origin 

Also, the date of manufacture should be as close as possible. 

Put the donor PCB on the patient drive and power it up. Read the ROM using The drive should be stuck in BSY and will not come ready. Go to the terminal screen, get a T> prompt and enter r1 to read the backup copy of the RAP from the SA. Open the Service information objects window by pressing Ctrl + Alt +1, select the YModem tab, and press OK. In the new tab that opens, left click anywhere in the HEX data, press Ctrl + A to select all of the HEX data, and control Ctrl + c to copy it to the clipboard. Select the Work with Flash ROM image and read the ROM over boot code. Open the RAP file, left click anywhere in the HEX data, and press Ctrl + v to paste the data from the clipboard into the RAP file, and write the data back to the drive's ROM. Repower the drive and see if it comes RDY. If it does not, you might need to find a donor that is a closer match or possibly repeat the process to recover the patient drive's SAP file using r3F to read it over YModem. 

I don't fully remember if the SAP file is 3F in other families so you may want to check the system file directory of your patient drive before moving the PCB to the patient drive. 

Good luck. 

Fraser

[$300 Data Recovery]

Wow, great info Fraser, thank you for sharing! Did not know this was possible.

[Markus Bauer]

It's a Wyatt - Momentus 5400.6.

Thanks for sharing - I will try that method.

[t...@desertdatarecovery.com]

Great and concise information Fraser.

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.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/ad077ea9-9edf-4e36-9758-f61c66d4769en%40googlegroups.com.

[pbzcbf...@gmail.com]

That's very interesting. I always thought that it was impossible (?) to reach the SA without the correct adaptives.

[TrumanHW]

Frasier,  even though I don't have that issue... I re-wrote out all of those instructions. 

By deliberately re-phrasing it slightly, I have to think through your intended meaning...

Both to create a catalog of solutions, and, in the hopes of 'rote' memory. 

Very detailed and generous of you. 

Truly, thanks.

--

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/c31d19b1-30a6-4b20-b62c-b120fe6bda75n%40googlegroups.com.

--

CONFIDENTIALITY NOTICE: 

The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.

[TrumanHW]

(Ha! That was even before I saw that it even impressed Brian C !) :-)

[Fraser Corrance]

I can't take all the credit for this. My fiend and former coworker, Marcos, deserves half the credit for this.

I had a drive in for recovery a few years back that had a failing ROM chip and parts of the ROM were simply not readable. I was never able to figure out a way to repair that drive because it was from a much newer family that did not contain backups of the ROM files in the SA. In the process of researching this I found that the families that came before Grenada have these extra copies located in the SA. If you compare drives that meet pretty much the same criteria that you use to match drives containing compatible reader heads and look through the AFH values for the zone that containing the SA, you will notice that they are pretty much the same. I figure since the SA has a much lower areal density than the UA zones, the AFH values don't need the same degree of fine tuning to get the heads to read it. Once you have access to the SA you will be able to rebuild the ROM used the backup copies. 

I have never had any luck at all modifying the ROM of drives from the Brinks family. I am guessing that it probably has something do with some check sums that probably need to be recalculated after the ROM is modified/repaired. 

And because of how much time was spent on this research, I have not seen a drive come in that I needed to use this method on....lol....Murphy's law, I suppose. It took a lot of trial and error to figure this out so if someone out there can benefit form this, please do. 

I have a few other theories about how it may be possible to rebuild pats the ROM from some of the newer families using terminal commands. Once I have a bit more time on my hands I plan on continuing research on this. These are some of the terminal commands I want to look further into:

/4k - Perform Resonance Identification (Similar to certtest) 

/7Nxxyy,aabb,m mnn - Adaptive Test 

xx - start point of tuning range for WP or left range for FC yy - total points in tuning range for WP or right range for FC aa - parameter select 01 - Write pre-compensations (WP) 02 - Boost frequency and Frequency cutoff (FCFB) bb - upper nibble:start zone, lower nibble:end zone mm - start point of tuning range (applicable for FCFB only) nn - total points in tuning range (applicable for FCFB only) mm and nn are only applicable to FCFB tuning. Tuned value is updated in RAM. F 

/7Oh,z,deff Read/Write Coarse Offset Calibration 

h - Head number (default = head 0) z - Zone number (default = all) if z = number of zones then calibration is done at the ID of the last zone. if z = number of zones +1 then OD of zone 0 is calibrated Tuning is done using the VGA mode. And ff indicates the de - first data rough gain to use ff - last data rough gain to use Best offset value is updated in RAM. 

/7dx,y,f Reset Adaptives to the Default Settings 

x - Zone Number (default = current zone) if x = number of zones then reset all zones 

y - Head Number (default = current head) if y = number of heads then reset all heads f - Flag. If f is entered, the head offset values are reset instead of the channel adaptives (default is channel adaptives).

If anyone out there has researched any of these commands, please do share your findings. :-) 

I hope somebody out there finds this helpful. 

Fraser

[$300 Data Recovery]

Again, thanks for the info! Hope I never need it :)

"(Ha! That was even before I saw that it even impressed Brian C !) :-)" --> LOL. Indeed! I didn't even know Seagate SA contained any parts of ROM.

[pbzcbf...@gmail.com]

F3RomExplorer should be able to recalculate checksums. I can do it, too, if you need help with this.

[Markus Bauer]

Hi. I have a PCB with right date (+ 1 month) and from the right factory (SU) but with the wrong firmware. It should work when I flash the ROM of that PCB with a ROM-dump of the right firmware. Or am I mistaken?

Thanks!

[Fraser Corrance]

Well,....there's really only one way to find out, try it. The drive might not come ready and it may even click a couple times. Spam <ctrl> + z when the drive starts up and try to issues r1 and see what it does. You may need to just find a couple donor ROMs and try those too if this one does not work.  If you don't have any other matches, post the matching criteria and I am pretty sure somebody in the group should have some that may be compatible. 

I double checked and Wyatt family does indeed keep copies of the RAP (r1) and SAP (r2F) in the SA. I guess we are about to find out if this method will work or not with this family.... :-)

[pbzcbf...@gmail.com]

I suspect that the SA would contain factory log files, just like WD's drives. If so, then it may be possible to reconstruct a SAP or RAP from the log data.

If someone could upload a complete SA dump, perhaps would could test this idea?

[Markus Bauer]

Here are some: https://firmware.hddsurgery.com/index.php?manufacturer=Seagate&family=Wyatt

[t...@desertdatarecovery.com]

Here are the first 10 or so in my database.

https://drive.google.com/file/d/1Y6mp9Zy2hj3P_4m4UM3IhiYKWHhAxb7b/view?usp=sharing

 

Tim Homer - Lead Engineer

Desert Data Recovery

t...@desertdatarecovery.com

www.desertdatarecovery.com

 

From: datarecovery...@googlegroups.com <datarecovery...@googlegroups.com> On Behalf Of Markus Bauer
Sent: Friday, June 4, 2021 4:04 PM
To: DataRecoveryCertification <datarecovery...@googlegroups.com>
Subject: Re: DIY fail

 

Here are some: https://firmware.hddsurgery.com/index.php?manufacturer=Seagate&family=Wyatt

--

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/a43585be-ed67-4e83-b85a-580a85cc67ebn%40googlegroups.com.

[pbzcbf...@gmail.com]

The only place I can see RAP, SAP and CAP data is in the ModDir directory.

The Sysfiles directory looks like a partial dump, if the following lists are any guide:

http://www.hddoracle.com/viewtopic.php?f=6&t=1853

[pbzcbf...@gmail.com]

They also exist in CPDir, but those look like they may have been extracted from the ROM rather than the SA???

[Fraser Corrance]

Ummmm,....so for some odd reason the r1 command dose not seem to work on this family. Or am I missing something here?

[pbzcbf...@gmail.com]

Does this help?

http://www.hddoracle.com/viewtopic.php?f=83&t=1455

[Fraser Corrance]

Sort of,..... It turns out I was missing something quite simple. 

Following the steps in the example using the PC3000 I get the following in terminal: 

F3 T>

e c r = 0 0 1

e c r = 0 1 0

e c r = 0 1 1

e c r = 1 0 0

e c r = 1 0 1

e c r = 1 1 0

F3 T>r1

Invalid Diag Cmd

I also tried opening  system files 1 and 2 and neither opens although they show in list of system files.  When I do so I get this in the log screen:

Rd Sys File: vol = 3, FID = 001, Copy = 000...

Unsupported by FW!

Rd Sys File: vol = 3, FID = 02F, Copy = 001...

Unsupported by FW!

I am able to open up modules 0006 (RAP) and compare it to the RAP in the ROM it's almost the same with the exception of 17 differences which are shown in the attached picture (ROM is on the left, Module0006 on the right). On a side note, to read Module0006 I had to use ATA indirect. ATA direct would not work.

So is there a way to read modules through terminal? 

I have to wonder if the differences in Module0006 and the RAP in the ROM would have any effect in the way the drive functions. 

Fraser

[Fraser Corrance]

I also compared Module0006 to DT0000 and found differences in the same vicinity as the differences in Module0006 and the RAP in the ROM. (see attached photo)

Not sure if it means anything or not, just thought I would share. ;-)

[pbzcbf...@gmail.com]

I have no idea what the differences mean, but I would think that you would need to specify the volume to be sure that you are reading what you think you are reading.

For example, volume 0x03 is the "System disc volume" and volume 0x0A "Serial Flash Volume".

There is also a "Disc root volume" (0x00) and a "Public disc volume" (0x06) . I have no idea what they are.

[Fraser Corrance]

I also tried using that method, as well. 

F3 T>r1,3,0

Invalid Diag Cmd

I guess the test drive I am using is a bit temperamental. I am able to read the RAP System File  using the utility but it sometimes takes a couple attempts. Still no love from the terminal command....

[pbzcbf...@gmail.com]

Isn't it the case that certain terminal commands are supported by the ROM code while others require a particular SA overlay?

[pbzcbf...@gmail.com]

FC356103.rpm is the sys file that contains the text strings pertaining to terminal commands. It appears to be the "Diag Cmd Processor Overlay". I suspect that that one would need to start the drive from a loader which would incorporate this overlay file and others. Then the diag commands may work.

[marcos]

+10 to both of you!

On 6/9/21 2:55 PM, pbzcbf...@gmail.com wrote:

FC356103.rpm is the sys file that contains the text strings pertaining to terminal commands. It appears to be the "Diag Cmd Processor Overlay". I suspect that that one would need to start the drive from a loader which would incorporate this overlay file and others. Then the diag commands may work.

--
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/2362b79b-5760-4693-8139-ff2fa27ca864n%40googlegroups.com.

[Fraser Corrance]

Hmmmm,...That might just be the solution. I can try that and see if it works and let you know how it turns out. 

I got hit yesterday with a couple emergency RAID recoveries so I may not be able to try this out till tomorrow. 

THANK YOU Frank! You are the best. 

Fraser

[pbzcbf...@gmail.com]

Would there be any point in transferring the donor's headstack as well as the ROM? This would at least ensure that the head adaptives and preamp were matched.