seagate 2GB st2000dm001 dead

[fzabkar]

What is the part number of the chip?

Here is the header section:

Code:

Offset(h) 00       04       08       0C

00000020  16480000 15500000 0E500200 10600600
00000030  06C8B001 04D84402 05E84602 03009702
00000040  0B00EF03 00000004

AFAICT, there are several modules within the ROM. Some constitute code, while others are adaptives (CAP, SAP, etc).

The header appears to define each module's ID (?) plus its location. The last entry appears to define the ROM's size, namely 0x40000 bytes.

ID offset

16 000048
15 000050
0E 000250
10 000660
06 01B0C8
04 0244D8
05 0246E8
03 029700
0B 03EF00
00 040000

Each module appears to have a 16-bit checksum at the end (and perhaps elsewhere).

[michael chiklis]

I splitted the rom in 2 parts to compare them.
I found that second half is not really a copy of first half (but similar).

The rom posted by Jano952 has the second half about the same of the first half.

Anelito rom splitted in 2 files:

ROM split.rar

(361.85 KiB) Downloaded 561 times

Jano rom split:

Jano split rom.rar

(366.96 KiB) Downloaded 691 times

[fzabkar]

That's interesting. I confess that I don't understand what is going on here. Is your tool (MRT Lab?) able to validate the ROM?

Otherwise I would carve out each of the ROM's modules and see whether the differences are confined to the adaptive sections. If there are differences in the code sections, then that could be of some concern.

[michael chiklis]

That's interesting. I confess that I don't understand what is going on here. Is your tool (MRT Lab?) able to validate the ROM?

I think not, however i was not able to make detect the rom in MRT. The only way i was able to detect and backup the rom was by unsoldering the chip and read it via eprom programmer.

Otherwise I would carve out each of the ROM's modules and see whether the differences are confined to the adaptive sections. If there are differences in the code sections, then that could be of some concern.

I hope that some pro can help us to understand this.
Should the 2 rom pieces have to be exactly the same?
Is Seagate doing this on 7200.14 drives for rom backup purpose in case of corruption??

[fzabkar]

Jano's ROM was OK, so the differences appear to be normal. Give me some time to carve out the sections and to compare and analyse them.

[michael chiklis]

thank you

[fzabkar]

I don't know whether I've introduced a red herring, but FWIW I found differences in 3 sections.

Code:

ID  offset range       comparison

    000000 - 00004F -- identical headers
15* 000050 - 00024F -- diff
0E  000250 - 00065F -- no diff
10  000660 - 01B0C7 -- no diff            code ?
06  01B0C8 - 0244D7 -- no diff            Read Adaptive Parameters (RAP)
04* 0244D8 - 0246E7 -- diff               Controller Adaptive Parameters (CAP)
05  0246E8 - 0296FF -- no diff            Servo Adaptive Parameters (SAP)
03* 029700 - 03EEFF -- diff               code ?
0B  03EF00 - 03FFFF -- no diff

AIUI, each section has a checksum word at the end. At the risk of introducing another red herring, the checksum word for the "15" section is 0x316B in both halves of the ROM, even though the two sections differ significantly.

[fzabkar]

AIUI, each section has a checksum word at the end. At the risk of introducing another red herring, the checksum word for the "15" section is 0x316B in both halves of the ROM, even though the two sections differ significantly.

It seems that it was in fact a red herring. Jano's ROM has the same 0x316B "checksum" even though its "15" section differs considerably.

I'm wondering whether there is a simpler explanation for the error message. Perhaps the donor board has damaged traces. It would be interesting to see whether the error message remains the same now that the ROM has been removed.

[michael chiklis]

I found on hddgurufiles more similar rom, here:
http://files.hddguru.com/download/PC-30 ... 3/Grenada/

download ST1000DM003-9YN162-CC4B-S1D3ZCKF

here, i already have split this ROM in 2 half so that is more easy for you to look inside:

VLA15 ROM split.rar

(351.08 KiB) Downloaded 556 times

[fzabkar]

I'll try to write a program to automate my analysis. However, I would still check the terminal log to see whether the MCU specifically recognises that the ROM is missing (no ID), or whether it just blindly performs checksum tests whether or not the ROM is present.

[michael chiklis]

Thank you Frank, i hope writing this program is not to tough

[AesEbu]

I don't know why, but I am not surprised it doesn't work.



Maybe you can clean up the resistor near eeprom, and solder eeprom properly? (Already done?)

If needed, here is a dump from a ST2000DM001.

ST2000DM001
sn: S1E02h0E
pn: 9YN164-302
fw: CC4C
Date : 12392 site: SU

Attachments

ST2000DM001_aesebu.tar

(513.5 KiB) Downloaded 774 times

[fzabkar]

I don't think a program is necessary yet.

The two halves of AesEbu's ROM differ only in the header (0x00 - 0x4F).

The two halves of Jano's ROM differ in the header and in the first section ("15"). The same is true for the VLA15 ROM.

However, the two halves of anelito's ROM differ in sections 15, 04, and 03, but the headers are identical.

I confess that I don't understand what is going on.

Unfortunately I haven't been able to work out Seagate's checksum algorithm, so I am unable to perform an integrity check of the ROM. That said, I'm very surprised that a tool such as MRT Lab cannot verify a ROM image.

[michael chiklis]

as they told me even pc3000 cannot verify rom image

[fzabkar]

ISTM that you first need to determine whether the "bad checksum" error is due to ROM corruption or a fundamental inaccessibility problem. If it's a case of corruption, and if your tool provides no other way, then I would try a MacGyver approach.

I would obtain a donor PCB with a similar ROM structure, ie one with identical address ranges for each of the sections, and I would remove the ROM and replace it with an IC socket adapter. Then I would patch sections 03, 04, and 15 from your patient ROM into the donor, one section at a time, and see which, if any, of these sections is responsible for the checksum error. The next step would depend on what you find and would involve patching the ROM.

[fzabkar]

Instead of waiting for a second donor PCB, why not test the existing donor by flashing a different known good donor ROM image into a spare ROM, and then installing this ROM onto the existing donor PCB? This will tell us whether the board is functional. If the PCB proves to be OK, then this would suggest that the original ROM is corrupt.

In the case of a corrupt ROM, I would copy the first half of anelito's ROM to both halves of the donor ROM and then see whether we still get a checksum error. If not, then perhaps this will be enough to enable access to the data. If we still get a checksum error, then we could copy the second half of anelito's ROM to both halves of the donor ROM and try again. In the unfortunate case where there is corruption in both halves of the ROM, we could use my earlier suggestion to narrow down the offending section(s).

[michael chiklis]

Thank you Frank, i have to talk with anelito first because he has the drive at the moment. I wait that he brings again the drive to me so i can work more on it.
I let you know...

[danao]

Hi, if you have a prescription for FW SC47 ST2000DM001 1E6164-570.
The contents of my winbond 25Q40 is faulty and HDD is dead. Before reading the engine was shaking, and now after loading this ROM most of GuruHDD, the drive is dead, and the reading of hyperteminal: a Flash boot code checksum failure!
SEA4 Boot ROM. That's why I need DUMP 25Q40 FW SC47. If someone would be so kind as to lend me this ROM, you will return the favor.
Best Regards Danao.

[pcimage]

Hi, if you have a prescription for FW SC47 ST2000DM001 1E6164-570.
The contents of my winbond 25Q40 is faulty and HDD is dead. Before reading the engine was shaking, and now after loading this ROM most of GuruHDD, the drive is dead, and the reading of hyperteminal: a Flash boot code checksum failure!
SEA4 Boot ROM. That's why I need DUMP 25Q40 FW SC47. If someone would be so kind as to lend me this ROM, you will return the favor.
Best Regards Danao.

It won't do you any good, all ROMs for these Seagate drives are 100% unique.

What do you mean by "the contents of my winbond 25Q40 is faulty"? How did you arrive at this conclusion?

[danao]

The content of my winbond 25Q40 was damaged, can I send dump in the Annex. Damaged same 25q40 can not delete or write. My guess is that the Seagate flashy content are unique but maybe if I got out of such a model, after uploading I would be able to improve to rip the data from it. There is an option to run for test drive? Can I buy a board for $ 50 but do not have the proper flash to translate it ... What do you advise?
Best Regards
Danao.