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
August 24th, 2018, 11:57
I have a USB hard drive WD10JMVM-11S5XS0 with
PCB: 2060-771801-002 REV. A and I tried to put a
PCB: 2060-771823-000 REV. A and when I transferred the ROM, the PCB
does not respond
Does anyone know any compatibility with this PCB?
Thanks in advance
August 24th, 2018, 12:47
I correct:
The plates are comparables in fact carry the same MCU and motor controller the problem lies in reading the ROM.
When I read the rom with the programmer everything works fine, but if I record the ROM read with the MRTLAB directly from the USB HDD, the ROMs are different.
I put the 2 readings of the USB disk ROM.
- Attachments
-
- ROM.rar
- (475.12 KiB) Downloaded 413 times
August 24th, 2018, 16:11
Very strange. It appears that MRT inserts (not overwrites) 0x400 bytes of zeros at offset 0x400-0x7FF. :? :? :?
You might like to try a HDDSuperTool script:
http://www.sdcomputingservice.com/hddsupertoolhttp://www.sdcomputingservice.com/hddsupertool/scripts/wd_royl_read_rom?attredirects=0&d=1
August 24th, 2018, 17:00
When I finish recovering the HDD I will try again to read the ROM by USB.
I have a dilemma:
Now I am reading from a HDD 3 of 4 heads. But if the head that does not read is scratching my plate I will irreversibly lose data.
The same thing happens with a HDD that is not recognized, try first to see if it is firmware and if I do not see the heads.
At the moment I will make the determination of whether a HDD has taken a hit and does not read well, open it and watch the heads before doing anything.
I do not know if it's right or not, but the damage that a bad head can cause can be irreversible.
I will look at the links you have put me. Thank you.
August 24th, 2018, 17:35
It is quite interesting. I will test how the patch mod2 and mod32 work.
Also try to read the ROM with WDMarvell.
August 24th, 2018, 17:42
If it's your own drive you can freely decide to risk data. If drive belongs to a client you should stop destroying data now. Client expects you to take all precautions to secure data. So the choice is easy.
August 24th, 2018, 17:52
digisupport wrote:If it's your own drive you can freely dicide to risk data. If drive belongs to a client you should stop destroying data now. Client expects you to take all precautions to not damage data. So the choice is easy.
+1
If I have a HDD that has taken a hit.
Did you open the HDD and scan, or connect and browse?
I am opting to open and observe. It is only a decision of your own.
I think we always try to make the right decision, although in the end it is the wrong one. Time tells us.
Forgive the expressions. I always use the google translator
Last edited by
mhp666 on August 24th, 2018, 17:57, edited 1 time in total.
August 24th, 2018, 17:54
digisupport wrote:If it's your own drive you can freely decide to risk data. If drive belongs to a client you should stop destroying data now. Client expects you to take all precautions to secure data. So the choice is easy.
+1
Good luck but sounds like experimenting on clients drives to me
August 24th, 2018, 18:08
mhp666 wrote:digisupport wrote:If it's your own drive you can freely dicide to risk data. If drive belongs to a client you should stop destroying data now. Client expects you to take all precautions to not damage data. So the choice is easy.
+1
If I have a HDD that has taken a hit.
Did you open the HDD and scan, or connect and browse?
I am opting to open and observe. It is only a decision of your own.
I think we always try to make the right decision, although in the end it is the wrong one. Time tells us.
Forgive the expressions. I always use the google translator
It takes so little time to inspect heads and drive under microscope, then you know whats going on.
I check internal even if a TVS is shorted. The full story can be hard to get, and a dropped drive typically gets checked by a "specialist" who blows the TVS.
August 24th, 2018, 18:14
pcimage wrote:It takes so little time to inspect heads and drive under microscope, then you know whats going on.
+1
August 24th, 2018, 18:34
For example what I do with a broken PCB board.
1. Short-cycle TVS. I assume it is about tension and I change it.
2. Some other component, even a simple fuse or resistance. I move the PCB.
In principle, in none of these cases do I open a disc. But in one case I did not do it, the heads were burned, and the plates were scratched (maybe the plates were already scratched, but I assume I scratched them).
August 25th, 2018, 5:03
I am looking for the HEAD and MEDIA value in the 0x47 module of this HDD and it seems that it is in the offset 0x10 and 0x2F (for this particular model), is there any pattern to identify these values in any HDD?
August 25th, 2018, 12:57
Module CHECKSUM
00 00 00 01
01 00 02 03
00 01 00 00
CHECKSUM = FD FC FD F9 It jumps in the calculation of sum.
02 02 00 02
00 00 00 00
................
00 00 00 00
-----------------
SUM = [S3 S2 S1 S0] = [03 03 02 05]
PRE_CHECKSUM = [00 00 00 00] - [S0 S1 S2 S3] = [00 00 00 00] - [05 02 03 03] =[F9 FD FC FD] = [P3 P2 P1 P0]
CHECKSUM = [P0 P1 P2 P3] = [FD FC FD F9]
Surely it can be simplified. I have not tried it much but I think it can be that.
I do not know if it's correct.
August 25th, 2018, 14:19
The checksum is computed by summing all the little-endian dwords in the module. The sum should be 0x00000000.
0x00000001 + 0x03020001 + 0x00000100 + 0xf9fdfcfd + 0x02000202 + 0x00000000 = 0xFF000001
See the source code for Pete Disdale's checksum calculator.
WD & Samsung Module CheckSum Calculator :
http://www.hddoracle.com/viewtopic.php?f=22&t=80
August 25th, 2018, 14:44
The first one does not seem to match the pattern.
But actually that calculation is what should be and not what I have tried to find out.
August 25th, 2018, 15:21
mhp666 wrote:The first one does not seem to match the pattern.
But actually that calculation is what should be and not what I have tried to find out.
Sorry. That should have been ...
0x01000000 + 0x03020001 + 0x00000100 + 0xf9fdfcfd + 0x02000202 + 0x00000000 = 0x100000000
August 25th, 2018, 15:47
Thank you very much for the link. I'm going to use it to try to understand the issue of checksum.
A cordial greeting.
August 25th, 2018, 16:22
mhp666 wrote:I am looking for the HEAD and MEDIA value in the 0x47 module of this HDD and it seems that it is in the offset 0x10 and 0x2F (for this particular model), is there any pattern to identify these values in any HDD?
I have written a tool for parsing WD ROMs:
http://www.hddoracle.com/viewtopic.php?f=22&t=1235I have included my source code. Hopefully you can make sense of it. (BTW, I'm not a programmer, so my coding is poor.)
Powered by phpBB © phpBB Group.