Seagate ST6000NE0023 ROM "contains critical damaged objects"

[crashpcberlin]

Hello everyone,

we got two ST6000NE0023 2EX110-500 (Makara Plus) Drives in. It's a RAID-0.

One of the drives shows LED:0x000000BB FAddr:0x0000425B after power-on with PC3K. No spin on, only "Busy"-LED is shining.

When i read the ROM, the PC3K shows immediately that the RAP module is damaged (Error-Message see below).

So i extracted the RAP-module from the other healthy drive and write it to the patient-ROM. Then the drive spins on, gets ready and gets ID (but with 0 MB) and i could read the complete SA without any error. So now i tried to fix the translator to get the right size, but without success... error message:

SIM FileFD=FC34E035 ErrorCode=43110081 DiscLBA=0000000000031FDB Duration=00000755 ms
PrgF
LED:0x000000BD FAddr:0x00007453

I tried all possible ways to recalculate the translator, but without any success.

ACE-Support provided me a repaired ROM, but drive doesn't spin on and shows BB Error aswel with it.

I attached the patient and the donor ROM. Is there anybody, who is able to fix the RAP module in the patient ROM or can give any other hints?

Thanks alot, guys!


Error-Log:

WARNING!
ROM image contains crytical damaged objects
[RAP]



Parsing container segment....... Flash ROM image
WARNING! Segment header check sum is invalid!
Segment: GLOB_FLASH_DIR
Parsing segment....... GLOB_FLASH_DIR
End parsing segment... GLOB_FLASH_DIR
Segment: BOOTFW_CONT_0
Parsing container segment....... BOOTFW_CONT_0
Segment: BOOTFW_DIR
Parsing segment....... BOOTFW_DIR
End parsing segment... BOOTFW_DIR
Segment: GENERAL_DATA
Parsing segment....... GENERAL_DATA
End parsing segment... GENERAL_DATA
Segment: PROG_INQ_DATA
Parsing segment....... PROG_INQ_DATA
End parsing segment... PROG_INQ_DATA
Segment: BOOTFW
Parsing segment....... BOOTFW
End parsing segment... BOOTFW
Segment: IAP
Parsing segment....... IAP
End parsing segment... IAP
End parsing container segment... BOOTFW_CONT_0
Segment: SFW
Parsing segment....... SFW
End parsing segment... SFW
Segment: SAP
Parsing segment....... SAP
End parsing segment... SAP
Segment: GLOB_FLASH_DIR
Parsing segment....... GLOB_FLASH_DIR
End parsing segment... GLOB_FLASH_DIR
Segment: BOOTFW_CONT_1
Parsing container segment....... BOOTFW_CONT_1
Segment: BOOTFW_DIR
Parsing segment....... BOOTFW_DIR
End parsing segment... BOOTFW_DIR
Segment: GENERAL_DATA
Parsing segment....... GENERAL_DATA
End parsing segment... GENERAL_DATA
Segment: PROG_INQ_DATA
Parsing segment....... PROG_INQ_DATA
End parsing segment... PROG_INQ_DATA
Segment: BOOTFW
Parsing segment....... BOOTFW
End parsing segment... BOOTFW
Segment: IAP
Parsing segment....... IAP
End parsing segment... IAP
End parsing container segment... BOOTFW_CONT_1
Segment: SHELL
Parsing segment....... SHELL
End parsing segment... SHELL
Segment: RAP
Parsing segment....... RAP
WARNING! Segment whole space check sum is invalid!
WARNING! Segment used space check sum is invalid!
End parsing segment... RAP
Segment: CAP
Parsing segment....... CAP
End parsing segment... CAP
Segment: UDS_BFW
Parsing segment....... UDS_BFW
Segment: BOOTFLOADER
Parsing segment....... BOOTFLOADER
End parsing segment... BOOTFLOADER
End parsing container segment... Flash ROM image

Attachments

Donor_ROM.zip

donor ROM

(632.78 KiB) Downloaded 872 times

Patient_ROM.zip

patient ROM

(462.35 KiB) Downloaded 830 times

[fzabkar]

Try the attached repaired ROM.

Attachments

ROM_ZAD2TJRK_A3E582E5_repaired.7z

(368.31 KiB) Downloaded 795 times

[crashpcberlin]

Try the attached repaired ROM.

THANK YOU VERY MUCH! That worked! I only had to rewrite the previosly saved translator back to the drive and got the full size ID and sector access.

How did you recalculate the CRC of the RAP? I tried it with F3 ROM Explorer, but got antother result...

[fzabkar]

I used my own tool to find all possible candidates for single-bit errors. Then I used F3ROMExplorer to decompress the LZMA payload. The solution does not require that the CRC be recalculated.

[Lardman]

Strange that Ace support didn't catch this, you'd have expect it to be routine for them.

@crashpcberlin can you attach the ROM ace sent you so we can see what they actually did.

[DeVlL]

I used my own tool to find all possible candidates for single-bit errors. Then I used F3ROMExplorer to decompress the LZMA payload. The solution does not require that the CRC be recalculated.

Its usefulness for Seagate looks very interesting. I have been using your WD utility to repair corrupted bios for several years now, and it is very good. But your Seagate Utility didn't know about it. Can you share it? What version of F3romExplorer do you use? The version I have is F3romExplorer_free_1.0.9

[fzabkar]

I use the same free version of F3RomExplorer.

This is my tool (STROMFIX_2):

https://www.hddoracle.com/viewtopic.php?p=22181#p22181

It finds all possible candidates for a single-bit error in a Seagate ROM segment.

[SWM]

http://www.users.on.net/~fzabkar/FreeBa ... Mfix_2.exe

Internode Members Webspace End of Life

The Internode Members Webspace service has reached End of Life has closed.

This complimentary service provided 50MB of webspace to create a non-commercial website under customer usernames on the Internode domain, e.g. "users.on.net/username".

[fzabkar]

The Internode Members Webspace service has reached End of Life has closed.

This complimentary service provided 50MB of webspace to create a non-commercial website under customer usernames on the Internode domain, e.g. "users.on.net/username". :(

The link I provided has a local copy of my tool.

https://www.hddoracle.com/download/file.php?id=9609

[fzabkar]

Strange that Ace support didn't catch this, you'd have expect it to be routine for them.

@crashpcberlin can you attach the ROM ace sent you so we can see what they actually did.

I previously repaired a ROM that Ace was unable to fix. In that case the ROM contained two identical copies of the bad segment. I simply used the good copy to repair the bad one. Easy.

I suspect that there is a vast chasm between Ace's tech support staff and their RE team. I wouldn't be surprised if Ace simply recalculated the CRC without addressing the content. I'm curious, too.

If there is any interest, I'll write a tutorial about this particular case.

[SWM]

fzabkar, thank you.

[DeVlL]

Strange that Ace support didn't catch this, you'd have expect it to be routine for them.

@crashpcberlin can you attach the ROM ace sent you so we can see what they actually did.

I previously repaired a ROM that Ace was unable to fix. In that case the ROM contained two identical copies of the bad segment. I simply used the good copy to repair the bad one. Easy.

I suspect that there is a vast chasm between Ace's tech support staff and their RE team. I wouldn't be surprised if Ace simply recalculated the CRC without addressing the content. I'm curious, too.

If there is any interest, I'll write a tutorial about this particular case.

Thanks for sharing its usefulness.

I am interested in your tutorial on this case.

[crashpcberlin]

Strange that Ace support didn't catch this, you'd have expect it to be routine for them.

@crashpcberlin can you attach the ROM ace sent you so we can see what they actually did.

Exactly my thoughts. They provided me the ROM attached.

After i told them, that this didn't work, they told me (with the note: this is last attempt) i should try to transfer CAP+RAP+SAP+IAP adaptives from patient rom to the donor one: https://i.imgur.com/XOna2im.jpg. So yes, writing the defective RAP module from patient to donor ROM: thanks for nothing.

Attachments

ROM_ZAD2TJRK_A3E582E5-fix.rar

(367.52 KiB) Downloaded 757 times

[crashpcberlin]

Strange that Ace support didn't catch this, you'd have expect it to be routine for them.

@crashpcberlin can you attach the ROM ace sent you so we can see what they actually did.

I previously repaired a ROM that Ace was unable to fix. In that case the ROM contained two identical copies of the bad segment. I simply used the good copy to repair the bad one. Easy.

I suspect that there is a vast chasm between Ace's tech support staff and their RE team. I wouldn't be surprised if Ace simply recalculated the CRC without addressing the content. I'm curious, too.

If there is any interest, I'll write a tutorial about this particular case.

I have to say again, THANK YOU very much for your continuous support and helpfulness in this forum and above, fzabkar.

[fzabkar]

Ace changed the "csiD" (Disc) header from this ...

Code:

Offset(h) 00       04       08       0C

00000000  FC0E0000 F0080000 00000000 E69B0400  ................
00000010  63736944 03003416 087F0000 20FFFFFF  csiD............

.. to this:

Code:

Offset(h) 00       04       08       0C

00000000  FC0E0000 F0080000 00000000 C9D10400  ................
00000010  63736944 030051E0 087F0000 20FFFFFF  csiD............

... and they simply recomputed the CRC of the RAP segment, from this ...

Code:

Offset(h) 00       04       08       0C

000BF7F0                    A2420000

... to this:

Code:

Offset(h) 00       04       08       0C

000BF7F0                    385D0000

They obviously missed the fact that the RAP is compressed ("LZMA" compression), which means that every byte after the single-bit error will become gibberish when the segment is decompressed.

Code:

Offset(h) 00       04       08       0C

00061000  01C09F17 00000000 4C5A4D41 C0A60200  ........LZMA....
                                                       ^^^^

That's really, really dumb.

[fzabkar]

I think I could automate the repair process if I could understand how this checksum word is calculated:

Code:

Offset(h) 00   02   04   06   08   0A   0C   0E

00000000  FC0E 0000 F008 0000 0000 0000 E69B 0400
                                        ^^^^

I know how it is calculated for those ROMs without a csiD header, but this ROM is different. Does anyone know?

[fzabkar]

Locating a single-bit error in a compressed Seagate F3 ROM segment:

https://www.hddoracle.com/viewtopic.php?p=23828#p23828

[pepe]

I tried all possible ways to recalculate the translator, but without any success.

this, by theory, just cannot work when you use foreign RAP.
and even if it did, you wouldn't be able to read a single sector anyway. RAP is CRITICAL.

But it's nice Franc was able to fix the bit-flip

[DeVlL]

Locating a single-bit error in a compressed Seagate F3 ROM segment:

https://www.hddoracle.com/viewtopic.php?p=23828#p23828

Great, thanks for sharing your tutorial. I'm going to study it.

[RAJOO]

I used my own tool to find all possible candidates for single-bit errors. Then I used F3ROMExplorer to decompress the LZMA payload. The solution does not require that the CRC be recalculated.

SIR,

we need F3 rom explorar licence / paid version ?

please