Data recovery and disk repair questions and discussions related to old-fashioned SATA, SAS, SCSI, IDE, MFM hard drives - any type of storage device that has moving parts
December 3rd, 2010, 11:56
BlackST wrote:Jono, you are asking too much...
I don't think so. Nothing is to difficult for our friend fzabkar.
December 3rd, 2010, 12:43
jono-ats wrote:BlackST wrote:Jono, you are asking too much...
I don't think so. Nothing is to difficult for our friend fzabkar.

I agree he has an answer for everything I am sure he can do it.
December 3rd, 2010, 12:51
The answer to the universe, life and everything is TVS... ooops, is 42 !!
December 3rd, 2010, 14:57
Kindergarten style cat-calling ? Whats the matter with you all? Dont tell me u got the hit of the Benjamin Button disease and reverting in age. Very unprofessional.
December 3rd, 2010, 18:07
jono-ats wrote:The drive will spin up fine with non-native NVRAM. We've yet to see one with a checksum error, but it would be easy to test if this would prohibit the drive from starting the motor.
Franc, why don't you corrupt an EEPROM and let everyone know what you find out?
Jono
Everything you've written supports my analysis. Non-native NVRAM is OK because it has a valid checksum. In fact that's why I qualified my statements as follows:
"This assumes that the NVRAM is original, and that it has not been reprogrammed. Does the HD still have its original PCB?"
As for corrupting an EEPROM, all you would probably need to do is to lift its data or clock pin.
Why don't
you corrupt an EEPROM, or are you afraid of what you will find?
December 3rd, 2010, 18:59
There is no need to fight
NVRAM can have corrupted data and good CS
December 3rd, 2010, 21:47
fzabkar wrote:jono-ats wrote:The drive will spin up fine with non-native NVRAM. We've yet to see one with a checksum error, but it would be easy to test if this would prohibit the drive from starting the motor.
Franc, why don't you corrupt an EEPROM and let everyone know what you find out?
Jono
Everything you've written supports my analysis. Non-native NVRAM is OK because it has a valid checksum. In fact that's why I qualified my statements as follows:
"This assumes that the NVRAM is original, and that it has not been reprogrammed. Does the HD still have its original PCB?"
As for corrupting an EEPROM, all you would probably need to do is to lift its data or clock pin.
Why don't
you corrupt an EEPROM, or are you afraid of what you will find?
A corrupted eeprom that will be fixed in 2 minutes or even less if someone else does it for you. Can you ?
December 4th, 2010, 1:41
BlackST wrote:A corrupted eeprom that will be fixed in 2 minutes or even less if someone else does it for you. Can you ?
Everything you do seems to require only 2 minutes. Yet when I asked you to perform a simple measurememt with a multimeter, I waited for 2 weeks while you consulted with colleagues, and in the end I had to show you how to do it. So you'll have to excuse me if I don't believe any of your self indulgent stronzate. I'm not impressed with chest beating, nor by people who blow their own trumpets. I don't care who you are, or who you think you are -- if you make a claim, then be prepared to back it up if someone questions or challenges it.
As for how I would test the idea that a corrupted NVRAM, with a bad checksum, would prevent the motor from spinning up, I suggest you make two copies of the NVRAM, one with PUIS enabled, and the other with it disabled. Compare the two images. I expect that there would a difference in one particular bit corresponding to the PUIS flag, plus a second difference either at the start or at the end, corresponding to the checksum. I suggest you then take the PUIS-enabled image (which prevents the drive from spinning up), and then flip the PUIS flag, while leaving the checksum untouched. This will corrupt the NVRAM without corrupting the data. If the MCU executes the code without regard to the checksum, then it should spin up the drive. If it examines the checksum, then the drive won't spin.
As for the suggestion that it is possible to corrupt the data without invalidating the checksum, I have read that in some drives the MCU will rewrite the NVRAM if the board is swapped to a different HDA.
December 4th, 2010, 4:29
You showed WHAT?AHAHAHAHAHAHAHAHAHAHAHAHAHAHAH... ROTFLMAO... If the idea is to have valuable info to spread elsewhere and not give something reallyt useful in return and not at google reach- whoever has it - is another badly ended attempt , for me.
P.s. If there's one who is shooting 'stronzate' it's not me. And this is not Far West not Wikileaks... Live with it.
December 4th, 2010, 6:59
agree
Doomer wrote:There is no need to fight
NVRAM can have corrupted data and good CS
You will have to use a Flash Device Programmer to kill checksum as PC3k uses auto recalc E2PR write command
But I think we all know what will happen
December 4th, 2010, 10:46
Not all, just one or three
December 6th, 2010, 5:12
thank you all for replying , special thanks to fzabkar ( the guy who is trying to HELP ),
the hard drive has its original PCB and original NVRAM is not reprogrammed.
i will try te features tool , however i dont think it will be readas its not by BIOS, but i hope it works and disable PUIS

).
and if not , wouldnt replacing a new NVRAM from another same model works ? and if its not the NVRAM what could it be ?
regards.
December 6th, 2010, 6:51
The question is:
Did sombody put this PCB on onother drive for test or other reason?
Most likely the answer is "YES" and we got a typical E2PR corrupted NVRAM...
Powered by phpBB © phpBB Group.