Hitachi HTS541075A9E630 NVRAM Download

[ddrecovery]

I have a drive in that has a very light ticking sound at power up, eventually becomes RDY but any interaction with it throws ABR errors. Cannot get into the PC3000 utility even with PCB only access. Tried swapping the NVRAM to a donor board, same thing. The donor board with donor NVRAM comes RDY almost immediately without the ticking sound (no access to utility presumably due to wrong NVRAM).

So I downloaded the NVRAM from both chips. The source drive starts with FF FF FF's and then has a repeating pattern. The donor drive just has the repeating pattern. Is the source NVRAM corrupt? Might replacing the corrupt bytes with the repeating pattern work?

Your advice would be appreciated.

Attachments

[pcimage]

Neither of those NVRAMs look at all right

[mr_spokk]

After it got RDY, does it still spinn?

[ddrecovery]

After it got RDY, does it still spinn?

Yes it does keep spinning.

[ddrecovery]

Neither of those NVRAMs look at all right

Sorry, my bad. I do have the correct dumps but cannot upload .bin or .hex files. How would you recommend I upload them?

[fzabkar]

ZIP them.

[pcimage]

Or RAR them

[ddrecovery]

Here you go. Thanks for the help.

Attachments

NVRAM Source.zip

(210 Bytes) Downloaded 258 times

NVRAM Donor.zip

(206 Bytes) Downloaded 343 times

[fzabkar]

Looks like rubbish to me. Are you using PC3K for these dumps, or are you reading the chips in a chip reader?

[ddrecovery]

Looks like rubbish to me. Are you using PC3K for these dumps, or are you reading the chips in a chip reader?

Hhhmm. Not sure what happened there. Rezipped.
It is a chip reader as I cannot get into the board on PC3K.

Attachments

NVRAM Source.zip

(125.15 KiB) Downloaded 370 times

NVRAM Donor.zip

(141.82 KiB) Downloaded 344 times

[fzabkar]

ISTM that the donor NVRAM dump may be from a HDS722020ALA330 (2TB DeskStar).

Donor:

Code:

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

00000DA0  10 B5 FF F7 8F FB C0 B2 10 BD 00 00 CB 31 AD 39  .µÿ÷.ûÀ².½..Ë1­9
00000DB0  32 32 30 32 30 41 4C 41 33 33 30 20 20 4D 69 63  22020ALA330  Mic
00000DC0  64 65 20 28 43 29 20 32 30 30 38 2C 20 48 69 74  de (C) 2008, Hit
00000DD0  61 63 68 69 20 47 6C 6F 62 61 6C 20 53 74 6F 72  achi Global Stor
00000DE0  54 65 63 68 6E 6F 6C 6F 67 69 65 73 2E 20 41 6C  Technologies. Al

Source:

Code:

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

00000F60  48 41 AD 39 48 78 78 35 34 31 30 78 78 41 39 45  HA­9Hxx5410xxA9E
00000F70  36 38 30 20 20 4D 69 63 72 6F 63 6F 64 65 20 28  680  Microcode (
00000F80  43 29 20 32 30 31 32 2C 20 48 47 53 54 2C 20 61  C) 2012, HGST, a
00000F90  20 57 65 73 74 65 72 6E 20 44 69 67 69 74 61 6C   Western Digital
00000FA0  20 63 6F 6D 70 61 6E 79 2E 20 41 6C 6C 20 72 69   company. All ri
00000FB0  67 68 74 73 20 72 65 73 65 72 76 65 64 2E 20 20  ghts reserved.


[Doomer]

Most likely the problem is not related to NVRAM
Probably system area damage

[ddrecovery]

ISTM that the donor NVRAM dump may be from a HDS722020ALA330 (2TB DeskStar).

Will check this out tomorrow, but the donor board was from a major supplier of donor parts. I may be a rank amateur, but even I can tell the difference between a 2.5" and a 3.5" LOL. I know with these types of boards they are sometimes not checked as well as they should be as they need a matching drive to fully test them.

[ddrecovery]

Most likely the problem is not related to NVRAM
Probably system area damage

Is there any way to get into this drive to correct the issue?

[Doomer]

Most likely the problem is not related to NVRAM
Probably system area damage

Is there any way to get into this drive to correct the issue?

Yes, there is

[ddrecovery]

Most likely the problem is not related to NVRAM
Probably system area damage

Is there any way to get into this drive to correct the issue?

Yes, there is

Would love to learn.....

[fzabkar]

ISTM that the donor NVRAM dump may be from a HDS722020ALA330 (2TB DeskStar).

Will check this out tomorrow, but the donor board was from a major supplier of donor parts. I may be a rank amateur, but even I can tell the difference between a 2.5" and a 3.5" LOL. I know with these types of boards they are sometimes not checked as well as they should be as they need a matching drive to fully test them.

The donor "NVRAM" dump looks like it occasionally drops 16-bit words. ISTM that there is a problem with your chip reader. In fact I have just recently been helping another person with a Hitachi chip reading problem. In his case it turned out to be a configuration problem with his reader.

OTOH, your patient's ROM dump looks OK at first glance. In fact I've extracted two copies of NVRAM data from the source ROM and they both checksum correctly. However, the donor's NVRAM contents do not.

Code:

C:\>xorchksm -16 NVRAM_Source_cut_1.bin
NVRAM_Source_cut_1.bin: XOR16 checksum = 0x0000

C:\>xorchksm -16 NVRAM_Source_cut_2.bin
NVRAM_Source_cut_2.bin: XOR16 checksum = 0x0000

C:\>xorchksm -16 NVRAM_Donor_cut_1.bin
NVRAM_Donor_cut_1.bin: XOR16 checksum = 0x983A

C:\>xorchksm -16 NVRAM_Donor_cut_2.bin
NVRAM_Donor_cut_2.bin: XOR16 checksum = 0x5F0D

C:\>xorchksm -16 NVRAM_Donor_cut_3.bin
NVRAM_Donor_cut_3.bin: XOR16 checksum = 0xBD39

C:\>xorchksm -16 NVRAM_Donor_cut_4.bin
NVRAM_Donor_cut_4.bin: XOR16 checksum = 0xBF0A

XOR checksum calculator:
http://www.alexsoft.org/viewtopic.php?t=80&p=4588#p4588

Attachments

NVRAM_cut.7z

(12.03 KiB) Downloaded 341 times

Last edited by fzabkar on November 13th, 2014, 0:02, edited 3 times in total.

[Doomer]

Would love to learn.....

Sorry, can't share

[ddrecovery]

OTOH, your patient's ROM dump looks OK at first glance. In fact I've extracted two copies of NVRAM data from the source ROM and they both checksum correctly. However, the donor's NVRAM contents do not.

Its probably a SA problem with the source as Doomer says

Would love to learn.....

Sorry, can't share

However I can feel hell freezing over....

[pcimage]

You have PM.