What is the part number of the chip?

Here is the header section:


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).

_________________
A backup a day keeps DR away.

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:


Jano rom split:

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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.

_________________
A backup a day keeps DR away.

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.


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??

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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.

_________________
A backup a day keeps DR away.

thank you

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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



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.

_________________
A backup a day keeps DR away.

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.

_________________
A backup a day keeps DR away.

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:

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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.

_________________
A backup a day keeps DR away.

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

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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.

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.

_________________
A backup a day keeps DR away.

as they told me even pc3000 cannot verify rom image

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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.

_________________
A backup a day keeps DR away.

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).

_________________
A backup a day keeps DR away.

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...

_________________
My firmware database:
https://mega.nz/folder/O01DkBRI#MxP2J6ZNqXDcrX40I8MoQQ

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?

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

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.