MultiDrive – free backup, clone & wipe disk utility from Atola Technology

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 5 posts ] 
Author Message
 Post subject: ST1000DM003, original ROM dead: donor ROM = SimErr
PostPosted: Yesterday, 15:15 
Offline

Joined: Yesterday, 14:39
Posts: 2
Location: Poland
Hi all. This is my own drive, with data that has value to me, but I'm still willing to gamble on it, hence my DIY approach - learning a lot along the way and enjoying it too.
What I'd like to know is whether there is any realistic way forward without the original ROM, and which direction is worth the effort. I've read a lot of threads here and on the PC-3000 forum and tried what I could, but none of it succeded.
While understand that without original ROM this a difficult case, I also have a feeling I may be missing something that is obvious to people who do this every day.

The drive:
ST1000DM003, PN 1CH162-305, FW CC47 (cannot exactly recall if it was ever upgraded from stock), PCB 100717520 REV B.
A likely power surge killed the PCB, leaving black arcing/burn marks throughout the laminate and also damaging the ROM chip (W25Q40BW). The ROM reads all zeros with no ID on a programmer that reads other 1.8 V chips fine. So no native ROM and no backup.

What I have:
- a working replacement PCB of the same board number with a fresh flash chip
- a healthy donor ST1000DM003-1CH162-510 CC47 + a full ROM dump from it
- and additionally found a ROM image from another 1CH162-305 CC47 on this forum.
- No PC-3000/MRT/DFL, just a TTL adapter, PuTTY and a programmer.

What I've seen so far:

1. The replacement PCB with the freshly programmed donor ROM works perfectly on the donor HDA (T>, ready, Windows sees the drive). So the board, the flash chip and the dump are fine. The problem only appears on my HDA.
2. Donor ROM on the patient stops in BootFW, byte-identical on six boots:
Code:
Boot 0x40M

Spin Up
RECOV Servo Op=0100 Resp=0005[LBA=0x000042F9]N01020C20o0o0o0o0o0o0o0o0[LBA=0x000042F9]NO1111
RECOV Servo Op=0155 Resp=0005[LBA=0x00066E3B]N02010C10o0o0o0o0o0o0o0o0[LBA=0x00066E3B]NO1111
RECOV Servo Op=0055 Resp=0005[LBA=0x00028F1D]N01010C10o0o0o0o0o0o0o0o0[LBA=0x00028F1D]NO1111
RECOV Servo Op=0155 Resp=0005[LBA=0x0008BA5F]N01010C10o0o0o0o0o0o0o0o0[LBA=0x0008BA5F]NO1111

SimError - Remaining in BootFW
Perform a double download without a power cycle

3. The -305 ROM from the other drive: same four LBAs, same Resp=0005, same SimError. Only the retry counters after each LBA differ (N01010C10 / N01010C10 / N01010C10 / N02020C20).
4. Hot-swap (that same PCB booted on the donor HDA, HDD spun down, then moved live to the patient) gives a full T> on the patient.
Head resistance (7>X) looks healthy: H0 0x0122 / H1 0x0129 against the donor's 0x0108 / 0x010F. 4>k gives a steady VGA readback and the servo counters advance, so the heads do see the platters. But the servo never settles on a track: every seek ends RECOV Servo Op=0055/0155 Resp=0005 and every read fails, SA or user area, either head. Almost always 43110081, a couple of times C3160080 (at cylinder 0x31000 and at a zone boundary).
One more thing that may mean something: after the first failed seek the drive stops trying. Further seeks return instantly with no RECOV and no retry at all, until I do 3>b0 / 3>b1, and then I get exactly one more attempt.
RRO/ZAP mode flags, seek offsets, load/unload cycles: no change in the result. 7>I shows the adaptives but is display-only, 7>r fails.

My questions:
1. Is there something obvious I've missed? A known trick for Grenada with a foreign ROM, a command, a flag, a different way to get the adaptives in?
2. Is adapting a donor ROM to a foreign HDA without the native ROM feasible at all (the "remove everything unique from the donor" idea I've read about)? I'd be willing to try it but need pointing in the right direction, can post both dumps, SAP/RAP/CAP exports and the full terminal logs.
3. If the ROM road is closed, is a donor head stack (donor ROM + donor heads on my platters) the realistic DIY route for a 1 disc/2 head drive, or is that hopeless without the original adaptives too?

All suggestions welcome, thanks.


Top
 Profile  
 
 Post subject: Re: ST1000DM003, original ROM dead: donor ROM = SimErr
PostPosted: Yesterday, 18:00 
Offline

Joined: November 24th, 2011, 21:48
Posts: 258
Location: Canada
I think your situation is challenging for most labs -

A Seagate ROM contains "RAP" (Read Adaptive Parameters) which has unique alignment, head adaptive parameters, and other data necessary for the drive to read its own Service Area (SA) from the platters. The terminal output you provided confirms this.

I doubt that rebuilding RAP is something a DR company is going to share.


Top
 Profile  
 
 Post subject: Re: ST1000DM003, original ROM dead: donor ROM = SimErr
PostPosted: Yesterday, 18:21 
Offline

Joined: October 3rd, 2005, 0:40
Posts: 4815
Location: Hungary
unfortunately you are pretty much busted without the original rom. There are families i can recover the adaptives for, but this version of Grenada is not one of them. I can recover SAP and most of RAP but one set of params is still missing, rendering the recovery impossible at the moment.

_________________
Adatmentés - Data recovery


Top
 Profile  
 
 Post subject: Re: ST1000DM003, original ROM dead: donor ROM = SimErr
PostPosted: Today, 5:43 
Offline

Joined: Yesterday, 14:39
Posts: 2
Location: Poland
Thanks both. That's the most efficient demolition of six years of hope I have ever
received, and I mean it as a compliment, at least i know where I'm at :D.

But not walking away just yet, this is as much a learning project
as a recovery, the drive isn't going anywhere, and I'd rather run out of options than wonder
about them.

1. @pepe You said you can recover SAP and most of RAP, but one set is still
missing. Can you say what kind of data it is? I'm not asking for your method - I'm trying to
understand whether it's something measurable from the drive itself, something strictly
per-unit, or something that could be shared across a production batch. Is it the serpentine
formula, or something else?
Is there a measurement worth running on a drive in exactly this state (live F3 T> on the patient via hot-swap, but no original ROM)?

2. A sibling. Since posting I found a used drive that is about as close to mine as I think
is physically possible:

Code:
mine:  ST1000DM003 1CH162-305 CC47, SN Z1D5V7W5, date code 14033
other: ST1000DM003 1CH162-305 CC47, SN Z1D5VXNC, date code 14034


Same site, five matching serial characters, consecutive production days. Does that distance
mean anything for adaptives, or are they per unit regardless of how close two drives were born?

3. The HSA question, asked more precisely. I've read the Grenada head
swap cases here where donor heads went in without importing head adaptives and the drive read
fine. But in those the ROM still matched the platters and only the heads were foreign. Mine
breaks both relationships at once.

So if I put the sibling's whole HSA into my drive (heads, preamp, actuator) and run the
sibling's own ROM, then the ROM matches the hardware it was written for and only the platters
are foreign. Is that something that can read a Service Area, or is the ROM-to-platter
relationship the one that actually matters, in which case I'd just be relocating the mismatch?


Top
 Profile  
 
 Post subject: Re: ST1000DM003, original ROM dead: donor ROM = SimErr
PostPosted: Today, 6:10 
Offline

Joined: October 3rd, 2005, 0:40
Posts: 4815
Location: Hungary
Quote:
Can you say what kind of data it is?

critical timing data on a per zone basis. Not saying it is impossible but at least very hard to reproduce even one of them. I have theoretical ideas about such process but it would require some moths of work i suppose.

No point replacing the head stack, you only risk messing it up even more. These adaptives are not for the heads, they are for the platter format, which is obviously unique for each drive.

_________________
Adatmentés - Data recovery


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: Google [Bot] and 280 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group