ROM DECLINING SPIN UP

[shahij]

Here is ROM that's declining spin up

@fzabkar, Can you please have a look into this?

http://files.hddguru.com/download/Other ... SASROM.zip

[fzabkar]

Seagate's warranty checker tells me this is a ST1200MM0088 ROM (serial number S4010X8B, Thunderbolt, SAS)

F3ROMExplorer is telling us that the RAP segment at offset 0x60000 has a bad CRC.

I extracted this segment and ran my STROMfix tool against it. This tool is only useful if there is an error in a single bit. Assuming this is the case, my tool identifies the following possibilities:

Code:

C:\>STROMfix_2.exe 00060000_DL_RAPM.bin

Expected / Actual CRC16 = 0x0000 / 0x2D16

Searching for flipped bits in 00060000_DL_RAPM.bin ...

Possible cold bit #1 at offset 0x133  (0x90 -> 0x92)
Possible cold bit #0 at offset 0x1133  (0xA8 -> 0xA9)
Possible hot bit #7 at offset 0x212C  (0x98 -> 0x18)
Possible hot bit #6 at offset 0x312C  (0x52 -> 0x12)
Possible cold bit #5 at offset 0x412C  (0x9A -> 0xBA)
Possible hot bit #4 at offset 0x512C  (0x76 -> 0x66)  <-- looks promising after decompression
Possible hot bit #3 at offset 0x612C  (0x9C -> 0x94)
Possible hot bit #2 at offset 0x712C  (0x4F -> 0x4B)
Possible hot bit #1 at offset 0x812C  (0x4F -> 0x4D)
Possible cold bit #0 at offset 0x912C  (0x40 -> 0x41)
Possible hot bit #7 at offset 0xA12D  (0xFF -> 0x7F)  <-- OK
Possible hot bit #6 at offset 0xB12D  (0xFF -> 0xBF)  <-- OK
Possible hot bit #5 at offset 0xC12D  (0xFF -> 0xDF)  <-- OK
Possible hot bit #4 at offset 0xD12D  (0xFF -> 0xEF)  <-- OK
Possible hot bit #3 at offset 0xE12D  (0xFF -> 0xF7)  <-- OK

Number of possible bit flips is 15

The usual failure mode of flash memory is that a bit flips from 0 to 1, where 1 is the erased state. Therefore the most likely candidates are the hot bits. The last 5 results are quickly eliminated by visual inspection as they occur in areas filled with 0xFF. This leaves 6 hot candidates.

These candidates are difficult to assess by simple visual inspection since the RAP segment is compressed (LZMA).

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00060000  01 C0 BF 03 FF FF FF FF 4C 5A 4D 41 74 63 00 00  ........LZMA....
00060010  30 00 03 00 5D 00 00 01 00 30 00 03 00 00 00 00
00060020  00 00 00 FF FC D6 C4 DD 5D 18 19 C2 4F FC 64 86

Instead, we edit the ROM according to each candidate and then decompress the RAP segment using F3ROMExplorer.

Only one location (0x6512C) produces a decompressed result that looks valid, ie the resulting data has a large 0xFF filled area at the end.

The edited ROM is 7936_512c.bin in the attachment.

Attachments

ST1200MM0088_ROM_repair.7z

(266.57 KiB) Downloaded 243 times

[shahij]

Let's test it, thanks for the analysis.

I have a reference ROM, I can share this one also if it helps as well

[fzabkar]

The reference ROM would be useful for comparison.

Here is my STROMfix_2 tool:

http://www.hddoracle.com/viewtopic.php?f=22&t=3076

[fzabkar]

deleted - wrong thread

[shahij]

Here is the referece

Attachments

reference rom.zip

(363.34 KiB) Downloaded 246 times

[fzabkar]

After decompression, the reference RAP looks the same as the repaired RAP. I think the repaired ROM is OK.

[shahij]

Unfortunately, didn’t work.
Still no spin up

[fzabkar]

I'm positive that the RAP has been repaired correctly. You can compare the two decompressed RAPs in the attachment.

The UDSBFW segment looks relatively empty when compared to your reference ROM, plus it does not have a "UDS" header. Perhaps you could patch this reference segment into your patient ROM?

Are you sure the PCB is OK? Does the reference ROM spin up your drive?

Attachments

ST1200MM0088_RAP_unLZMA.7z

(47.89 KiB) Downloaded 233 times

[fzabkar]

After looking at other ROMs from different models, it does look like the UDSBFW segment is corrupt. However, it's not just a few bits that are bad, it's almost everything. Compare the two files in the attachment.

Attachments

ST1200MM0088_UDSBFW.7z

(11.94 KiB) Downloaded 227 times

[fzabkar]

Are you aware that this model requires both +5V and +12V, even though it is a 2.5" drive?

https://www.seagate.com/www-content/product-content/enterprise-performance-savvio-fam/enterprise-performance-10k-hdd/ent-perf-10k-v8/en-us/docs/100746003d.pdf

[shahij]

After looking at other ROMs from different models, it does look like the UDSBFW segment is corrupt. However, it's not just a few bits that are bad, it's almost everything. Compare the two files in the attachment.

Do you find UDSBFW is unique or can be patched using donor segment?

PCB is okay, reference ROM does work and spins up normally

I also believe RAP segment is repaired successfully

[fzabkar]

I have patched your reference UDSBFW segment into the patient ROM. I don't know if this is a legitimate thing to do, though.

Attachments

7936_512c_patched_UDSBFW.7z

(252.05 KiB) Downloaded 223 times

[fzabkar]

Another edit, this time replacing the reference SN with patient SN in UDSBFW segment.

Attachments

7936_512c_patched_UDSBFW_with_patient_SN.7z

(252.08 KiB) Downloaded 224 times

[fzabkar]

FWIW, I have attached the payload and individual segments from a Dell TT31 firmware update. The FWH file is a Seagate LOD file with a Dell header.

TT31_LOD_part02.bin is the BFWCTNR segment. It matches both halves of the ROM.

https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=kknkx (Dell TT31 update)

Attachments

Dell_TT31_FW_update.7z

(890.89 KiB) Downloaded 226 times

[fzabkar]

I notice that the ROM has a full CELog segment (Critical Error Log), but I don't believe this is of any consequence insofar as spin-up is concerned.

Is there any output from the terminal port?

[shahij]

Thanks for all the hard work

We gave up the case

[fzabkar]

In light of similar cases since this thread (eg https://forum.hddguru.com/viewtopic.php?p=306720#p306720), I have had another look at the subject ROM and found that the Extra_Space at offset 0x80000 has been initialised as an NVCache. I suspect that there would be corresponding diagnostic messages in the terminal log.

Normally this region contains full or partial copies of the RAP, SAP and CAP. However, when the drive experiences an unexpected power loss, pending write transactions are saved to the NVCache in ROM. Presumably these transactions are replayed at power-up.

This is the NVC header:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  48 4E 76 43 F5 00 48 08 B6 81 F9 01 00 00 00 00  HNvC............
00000010  00 00 00 00 6E 00 73 DE 00 00 00 00 00 00 00 00
00000020  00 00 00 00 00 00 00 00 12 02 03 05 68 18 00 03
00000030  88 1C 00 04 A8 D0 00 05 C8 E8 00 01 00 00 00 00
00000040  00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF

There are several " DaT" regions:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00001860                          20 44 61 54 03 01 C5 64           DaT....
00001870  00 00 00 00 00 00 6F 00 48 01 00 00 00 00 00 00

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00001C80                          20 44 61 54 04 01 EB 7B           DaT....
00001C90  00 00 FF FF 87 CE 76 00 94 1B 00 00 00 00 00 00
00001CA0  00 00 00 00 00 00 00 00 0C 52 4C 45 04 66 02 00  .........RLE....

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000D0A0                          20 44 61 54 05 01 FB 65           DaT....
0000D0B0  00 00 FF FF 00 00 80 00 00 00 00 00 00 00 00 00
0000D0C0  00 00 00 00 00 00 00 00

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

0000E8C0                          20 44 61 54 01 01 31 BD           DaT....
0000E8D0  00 00 FF FF 2E A8 00 01 20 00 00 00 00 00 00 00
0000E8E0  00 00 00 00 00 00 00 00 20 4C 6F 47 6E 00 80 00  ........ LoGn...

I think that the drive is detecting some problem in this area and is refusing to spin up. I expect that one crude solution would be to patch the CELog, UDSBFW and Extra_Space segments from a donor into the patient ROM.

[fzabkar]

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  48 4E 76 43 F5 00 48 08 B6 81 F9 01 00 00 00 00  HNvC............
00000010  00 00 00 00 6E 00 73 DE 00 00 00 00 00 00 00 00
00000020  00 00 00 00 00 00 00 00 12 02 03 05 68 18 00 03
                                              ^^^^^^^^^^^  DaT segment #3 at offset 0x001868 in NvCache

00000030  88 1C 00 04 A8 D0 00 05 C8 E8 00 01 00 00 00 00
          =========== +++++++++++ ***********
               |           |         DaT #1 @ 0x00E8C8
   DaT #4 @ 0x001C88   DaT #5 @ 0x00D0A8

00000040  00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00001C80                          20 44 61 54 04 01 EB 7B           DaT....
                                              ##
                                              DaT #4

00001C90  00 00 FF FF 87 CE 76 00 94 1B 00 00 00 00 00 00
00001CA0  00 00 00 00 00 00 00 00 0C 52 4C 45 04 66 02 00  .........RLE....

[fzabkar]

Here is the NvC header from an ST8000AS0002 (with 5 DaT sections):

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00080CF0  50 4E 76 43 61 3E CE 64 CC 95 9F 0E 00 00 00 00  .NvC............
          ^^
          size of NvC header = 0x50 bytes

00080D00  00 00 00 00 0A 00 16 80 00 00 00 00 00 00 00 00
00080D10  00 00 00 00 00 00 00 00 0A 02 03 06 70 18 00 03
00080D20  90 1C 00 04 B0 5C 01 05 D0 74 01 06 F0 84 01 01
00080D30  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00