Swapping PCB on Samsung HD204UI?

[ruli]

Hello,

I recently had a 2TB Samsung HD204UI HDD fail on me. The gory details can be seen at http://hardforum.com/showthread.php?t=1798169, but basically I was physically replacing a HDD in my ZFS array, and when I turned the server on I smelled something burning: it seems like a voltage surge occurred, and a different HDD suffered. The details can be seen in the attached picture (which shows the damaged PCB side-by-side with a working one), it is exactly the same damage as shown at http://forum.hddguru.com/viewtopic.php?t=24676, where it was identified as being an STJ009 MOSFET.

Now I happen to have an identical drive with the same PCB (the codes match: BF41-00314A 00), so I'm thinking I should be able to perform a PCB swap. However, I read from http://www.donordrives.com/hard-drive-pcb-donor-match, specifically for Samsung drives, that "Chip transfer / swap or similar services could be required for newer models".

My questions are:

1) Does anyone know if for this particular instance I will need to perform this chip transfer/adaptation? Or can I just swap the PCBs?

2) If indeed some specific data is required from the ROM/BIOS chip(?) from the original drive, does anyone know specifically what the data contains? The reason I ask is because the working PCB comes from the same ZFS raidz1 array, and has identical GPT geometry, so if the information required was just the disk/partition geometry, I was wondering if I might be lucky enough that the two PCB boards also store the same information. Or is there some special unique device-specific information that is necessary?

3) Finally, if the chip transfer/adaptation was indeed required, what would happen if I just swapped the PCBs over without performing the chip transfer, and trying to see if I could recover the data? Would permanent write damage occur as a result, or would it simply not work, but leave the data on disk intact?

Many thanks in advance for any input!

Attachments

Samsung HD204UI

[ShaneWard]

If that component had burned out like that, I am sure others suffered the same fate as well as the Pre-amp inside the drive. Just swap the pcb boards with the good one and see if the drive spins up. If it does you can go on from there. If not then it might be a job for a data recovery company.

Shane

[ruli]

If that component had burned out like that, I am sure others suffered the same fate as well as the Pre-amp inside the drive. Just swap the pcb boards with the good one and see if the drive spins up. If it does you can go on from there. If not then it might be a job for a data recovery company.

Shane

I *must* be due a bit of good luck, as I've just bitten the bullet and gone ahead with the PCB swap, and lo and behold, it worked as perfectly as I could hope for! I am resilvering my array as I type. Fingers crossed it all runs smoothly. When it's done, I'll have to think about even more redundant set-ups, and of course, a good backup policy!

The great thing is I didn't have to do any chip transfer, I just swapped over the PCB. I don't know if this would have worked if the disks had different partition/geometries.

Thanks for the encouragement, Shane, it was just what I needed

[fzabkar]

Congratulations.

AIUI, you only need to match the firmware and ensure that the patient and donor have the same number of heads. The firmware on the PCB has to match the MOVLY001 firmware module in the System Area on the platters. There are no "adaptives" on the PCB.

Analysis of Samsung SpinPoint F3 ROM:
http://malthus.zapto.org/viewtopic.php? ... 681&p=1992

Analysis of MOVLY001 SA module in SpinPoint F3:
http://malthus.zapto.org/viewtopic.php? ... 698&p=2150

[ruli]

Thanks for the info fzabkar, that's good to know.
BTW, the links you provided seem to be dead...

[fzabkar]

Thanks for the info fzabkar, that's good to know.
BTW, the links you provided seem to be dead...

Yes, some lowlife keeps trying to take the server down. :x

[fzabkar]

There are no "adaptives" on the PCB.

Actually, I think that statement may be wrong, but I don't know why.

The serial flash memory chip (aka "ROM") has a size of 512KB. A firmware update appears to rewrite the entire first half of the chip, so this would suggest that the there is no unique information in the first 256KB. The second 256KB is mostly blank, with a very small "FIPS" section. The FIPS data appear to be generated by the Burn-In process, so one would expect that it would be the place for any adaptives. That said, the FIPS section is sometimes corrupted, resulting in a no-spin symptom. When this happens, the solution is to rewrite the FIPS with zeros, or to transplant FIPS data from a donor. Neither solution appears to affect the functioning of the drive, so this leaves me wondering under what circumstances a ROM transfer would be necessary. Is it simply a case of matching the ROM with certain SA modules such as MOVLY001, GEO_00? Are there circumstances when the FIPS data are important?

[David Phan]

replacement rom from pcb patient to pcb donor

[friken]

Reviving an old thread a bit, as I have the same drive and just did a pcb swap w same pcb firmware/model/etc. bios and windows sees the drive fine, but win8 stoarge space thinks it is a new drive. I was hoping the storage space would just come back online. I'm 99% sure the drive data is fine because I broke the power plug off the old board while it was out of the system and off. Maybe a chip swap is needed? if so which chip? I assume storage spaces is seeing the drive as a diff serial# or unique id from new pcb?

[friken]

Here is all the info on the pcb swap, any help would be greatly appreciated.

Windows 8:

I have 4 drives assigned to a raid1 and a raid0 storage space. A power plug broke off of one of the drives. I ordered an exact replacement hdd pcb for that drive (model, firmware, rev all same). It spins up, bios sees it, windows sees it, I'm 100% sure no damage was done to the data as the drive was off when the power plug was broken. windows sees it but storage spaces thinks it is a new drive. So spaces is still showing the raid0 offline and raid1 in lowered resiliency mode. I am assuming something on the logic board, maybe hdd serial# or guid or something is now different for the repaired drive.

Does anyone know in powershell if there is a way to tell storage spaces that the repaired drive is in fact the one that it thinks is offline?

Here is a powershell Get-PhysicalDisk:

FriendlyName CanPool OperationalStatus HealthStatus Usage Size
------------ ------- ----------------- ------------ ----- ----
SAMSUNG HD204UI ... False Lost Communication Warning Auto-Select 1.82 TB
SAMSUNG HD204UI ... False OK Healthy Auto-Select 1.82 TB
PhysicalDisk3 False OK Healthy Auto-Select 55.9 GB
PhysicalDisk1 True OK Healthy Auto-Select 1.82 TB
HGST HDS5C4040AL... False OK Healthy Auto-Select 3.64 TB
HGST HDS5C4040AL... False OK Healthy Auto-Select 3.64 TB
PhysicalDisk5 False OK Healthy Auto-Select 1.82 TB
-------------------------------------
-------------------------------------

note that this drive:
SAMSUNG HD204UI ... False Lost Communication Warning Auto-Select 1.82 TB
Now has a new logic board and storage space is showing as:
PhysicalDisk1 True OK Healthy Auto-Select 1.82 TB

Hopefully someone knows storage spaces better than I do and can point me in the right direction (other than never use it again