Hi, maybe someone could have any grate thought about my problem. I now have 2 of these hdd non responsive.
I have had one HDD that stoped spining, after some tests i understand that PCB went bad. i got other identical HDD (exept serial number of course), and switched 25FU40 flash chip form old drive to new pcb, and put new pcb on old HDD, no spinning.
then i made same with new hdd, puting old PCB with new BIOS and new HDD worked just fine so not a PCB issue, i have put that same old PCB with NEW bios to old drive, and bingo, it begins to spin, but ofcourse no recognision and so on (of course different bios and hdd data).
Now i read both new and old hdd bios to compair, see some interesting differences, but have too little experiance in HDD to see what is bad. but to make situation worse, i try to rewrite NEW BIOS (read new hdd bios, write that same bios back ) Guess what? i have now two non spining non working hdd, but unable to understand why, as i have read and write same type flash memory many times before in other computer parts like routers and so on.
any help on my topic would be grate.
i add both BIOS readed, many thanks

Does the PCB have a ROM and NVRAM IC?

_________________
Death is nothing, but to live defeated and inglorious is to die daily.
Data Recovery Cape Town

nop, only one flash MCU. 25V40 i presented dumps i have read. other MCU only, main procesor, as i understand without internal eeprom, motor driver and of course RAM chip.
as i see in stucture that flash holds NVRAM area and full FW. one thing i can not understand is exesive difference from two same FW read flash chips. NVRAM diference okey, but why FW area differs too? and what i have done wrong to stop new hdd working? bad read?

no one to help ?

Could anyone help recalculate cheksum for this hitachi file? many thanks.

@andrius, are you using a chip programmer to read/write your flash memory in-circuit? If so, did you not save the original copies of each of your ROMs?

AIUI, there are some circumstances under which a donor ROM/NVRAM is partially reprogrammed when the donor PCB is installed on a patient drive, rendering the donor drive inoperable. I'm not a data recovery professional, but I suspect that is what may have happened.

I have written a tool for calculating Hitachi's XOR16 checksums.

XOR16 checksum calculator for Hitachi NVRAM:
http://www.hddoracle.com/viewtopic.php?f=22&t=80&p=4588

I have extracted the primary and secondary copies of the NVRAM from each of your ROMs at offsets 0x2000 - 0x2FFF and 0x3000 - 0x3FFF. FWIW, there is also an E2CH block at 0x7000 - 0x7FFF. All have zero checksums.


Your edited NVRAM has a checksum of 0x9032.



I'm not certain, but I believe that the checksum bytes may be located at 0xFFA - 0xFFB, in which case the new checksum bytes would be 0xFFFF XOR 0x9032 (little endian).

To identify the location of the checksum bytes, I would obtain a working donor and read the ROM before and after enabling Power Up In Standby (PUIS). The PUIS flag plus the checksum bytes should be the only differences in the before-and-after comparison.

_________________
A backup a day keeps DR away.

many thanks for reply. for my knowledge there is definetely XOR type cheksum at the end, but it is not XOR16 of hole dump for sure. it seams to be XOR16, because all bytes XOR to 0, but same result would be if it is XOR8, or 3 cheksums of different area XOR16 algo. would you guid me, how to enable options on hdd like Power Up In Standby? i would do reasearch on cheksums many thanks

my skype: greenfox1

PUIS can be enabled and disabled using tools such as HDAT2 or hdparm.

XOR8 is a special case of XOR16. For example, is the XOR16 checksum is 0x1234, then the XOR8 checksum is 0x12 XOR 0x34. Essentially the algorithm computes a parity for each bit.

XOR16 checksum bit #0 = [(bit #0 of word #0) + (bit #0 of word #1) + ... + (bit #0 of word #n)] modulo 2

...

XOR16 checksum bit #15 = [(bit #15 of word #0) + (bit #15 of word #1) + ... + (bit #15 of word #n)] modulo 2

_________________
A backup a day keeps DR away.

yes, i understand perfectly what the numeber near XOR mean (bytes count), in fact in most cases CRC cheksum may give same result as XOR function, nethermind that CRC ha ROL ROR functions, and anditional XOR parameters. i know cheksum calculation very well. i have been working or reverse engineering CAR ECU, dash, cheksums and so on. when i get my equipment to read write that flash memory, on 20-22 of March, i will try to investigate is that realy XOR16 and could the area be located for the cheksum, and if other cheksum are present i have scanned hole NVRAM area for XOR8, XOR16, XOR24, XOR32, XOR40 cheksums and posible cheksum residue. but none were found.
So maybe someone already know what area are those 3 cheksums in the end of file belong to?

Well, it appears that you have much more experience with checksums than I do. I'll be very interested in your findings. BTW, you might like to examine the resource dumps for those other Hitachi models where the "ROM" (SPI flash) and "NVRAM" (microwire EEPROM) are implemented as separate ICs.

http://files.hddguru.com/index.php

You may find the following tool useful:

http://fsumfe.sourceforge.net/



Best of luck.

_________________
A backup a day keeps DR away.