I will answer later. But for now, I reflashed ROM with external programmer and HDD works. I copied 1.6 GB Data an calculated MD5 hash. It fits the original file.

Cool ! One less thing to worry about ! It would have been nice to test with the WDR tool. Did you Read with external programer prior to re-write ? Did data match with the one you write to the chip with wdr ? In future we have to take that into consideration, flashing wrong ROM might prevent tool from re-program ROM.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

I will thank you for your advise, Spildit.
I wasn't able to connect to drive through WDR. Maybe it would work with another PC-Mainboard. Mine is an old Pentium 4 with installed Windows XP.
Of course, I read out the flash before erasing. Its content fits to the old ROM, which I wrote to the new PCB.
For now, I will end working on this.

Ok ! Thanks for sharing and it was nice to "work" with you.
Best regards and if you need something more just ask.
Hope that someday you manage to get that data out of the broken drive.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

Thanks. It was very informative for me and I learned a lot.
Just for the sake of completeness, I attached a photo from PCB with desoldered ROM, so you can see the connected pads VDD, HOLD and WP from SST25LF020A.
Thank you for your time and advice.

Thanks for sharing. When you manage to get the data out of the drive please come here to share the success story, ok ?
Best regards and wish you luck.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

Ok. So long!

It seems that he didn't made any researches...
So, without the ROM...the PCB it's like a computer without it's OS. If you screw the OS, you won't be able to use VSC because those are handled by the routines inside the ROM(OS).

But in his case he didn't damage the ROM. He just placed a ROM for other drive (firmware version) on his drive. This would be the same as moving the ROM chip. Rom was not damaged as drive was still spinning. If ROM was damaged drive would not spin at all, but in his case he had wrong adaptive data / wrong firmware, yet ROM was still loaded to RAM and booting. It should have been possible to Re-Flash again, as the code on ROM was still working, the same way that you can use WDR even without the heads of your drive reading firmware from the platters.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

I guess because of busy state. Anyway, I'm glad that the new drive survived.

I'm confused

I understand that in the end he used the bad hdd with the donor's PCB and the firmware extracted from old hdd and flashed with WDR. So..what adaptive data you say there...the firmware has all what it needs on SA, because it's the old firmware. There it's no conflict between ROM->SA mdules, they match. I assume that WDR write bogus data, perhaps not the entire 192kb block...and the firmware get stacked somewhere during boot.

So the VSC commands which in my opinion are processed by the firmware (the status VSC command...has some version numbers..which make me believe that it's part of the ROM frm)...won't work..so no more flashing via WDR.

I guess that Drive loaded ROM to RAM and executed it, but then either the adaptives/module tables were not providing the correct information for the firmware to be found at platter level, or the drive aborted the process as soon as it checked that firmware on platters was not compatible with ROM version. At any rate drive didn't respond to SVC from that point on. Assuming that PCB could be powered without connection to HSA it should have stayed in a state that could accept SVC and then permit to re-flash ROM.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

The BAD hdd didn't even power up (not spinning) if the new PCB was plugged to it with HSA contacts to PCB (and then the assumption that Pre-amp was shorted on OLD/Damaged Drive). The end user flashed the ROM of the OLD/BAD PCB on the NEW one, in the hope that the NEW PCB with OLD rom would match the firmware on OLD DRIVE (that is correct but the problem was with drive itself, not the PCB).

Conflict of SA - ROM is stated because NEW drive stop working (despite it was spinning) with its PCB when the ROM was flashed from its rom to OLD/DAMAGE drive ROM. Drive was OK but had ROM from the old drive, and so that ROM would be incompatible or lack the adatives to that specific DRIVE.

It works like this :

1 - Rom is loaded to RAM.
2 - ROM have content, like tables for drive to know where on platters are the modules of firmware to load, and head map, like how many heads the drive have, etc ... it can also have adaptive data, specific to that drive, like specific calibration defenitions for the drive to read platters.
3 - Only then Firmware from platters are (hopefully) read and drive reached rediness.

WDR wrote the right data/rom because user compared that with the dump made later with the exteranl eeprom programmer (data on chip was the data he flashed). Also DRIVE WAS SPINNING even with ROM tha didn't belong to the drive, meaning that ROM was not damaged neither corrupt, otherwise drive wouldn't spin at all. The problem was just with the fact that the drive then started to try to load firmware from platters and couldn't do so because of wrong ROM.
Re-Flashing with WDR should have worked if drive were to be prevented from reading content on platters, as it was for old drive (user was able to read rom from old/damaged drive by connecting power to PCB without HSA connected. Hope this clarify the issue. I'm starting to understand now, finally, how this thing works ....

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

Then why he used the chip programmer? I assume he didn't had any pleasure in un-soldering..instead using 2 clicks WDR on the new PCB with HSA disconnected. What would you try first
The old bios was incompatible with the new board...who knows..other ports mapped in other ways which the old bios couldn't access...other addresses on new PCB.
If it spins..it's not a sign that works..maybe the firmware worked fine until spinning the plates but crashed few functions after. Some functions inside the firmware were ok executed while others no...because the hardware differs from the what software "knows".

In other way..I assume that the kernel loader (the first code executed from the bios...first table entry in bios.bin) try to check the ROM modules against the SA backed up ones..and if it cant read or read bogus data..then it display WDC ROM. The ROM flash..has only the basic data to access the SA. How many heads are..etc. From what I've read the SA is written especially in the middle of the platters (or around there) where the heads don't need adaptive data to read the info.

The hdd identifies with WDC DISK or WDC ROM in model field .DISK indicates it was already loaded from disk. More, lets assume that the SA modules are bad...in this case we should have access reading each head. If we get errors on each head..it means that the Preamp is dead.

I'm assuming he was afraid of briking the "NEW" drive and panicked a little bit when he wasn't able to flash back the firmware with WDR tool, so he went directly to use the programer. Also if you have a soic8 clip you can connect the clip to chip and program the chip without soldering it. I have done it and it works :

read-write-serial-flash-wdc-logic-boards-t7192.html

PCBs were the same PCB revision, so it would be very unlikely that the MCU was not able to understand the op codes on the firmware. MCUs on the board were almost the same. My guess is that as soon as he realized that WDR was not flashing the firmware back he decided to use the programer and have done so, before i had the chance to sugest to run WDR with PCB without contact to Head Stack.
Drive spinned and cliked, as it should. If it weren't for the broken Pre-Amp on the old drive, that is, if the problem with the old drive was just a bad PCB, how would you solve it ?
Read this forum, you would have to buy a new PCB and swap ROM chip to new PCB. That was exactly what was done. If ROM were to be damaged it wouldn't even spin the spindle. If it was able to do so, it should have accepted VSC too. But now we can't test it, and it's not important either. The important part is that WDR flahed the file from the old PCB, and that was verifyed with a dump of the external programer, so in the furutre, if you find a PCB with masked ROM from ROYL family you can flash ROM from patient PCB to donor using this method.
Of course, it will not help in your case because as with the user of this post, your case is head/pre-amp damage (you can't even read firmware at all).

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

that soic8 stuff is awesome. It prevents me destroying the PCB

the MCU must match 100%. I believe that.."almost" doesn't work here. I have little experience with some PIC programming, but I know that on a cip..a pin must mean something, while on other..it will do something else. It doesn't involve opcodes..which is the language..but the hardware locations where the software try to communicate with the MCU.

Got mine on Ebay and its cheap. Check :

http://www.ebay.com/sch/i.html?_trksid= ... &_from=R40



Ok. I don't know. More testing would be required. But i think that if PCB revision match then it should be compatible .... That is the MCU and ROM code.

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

Hi again,
I tested new PCB with old drive and old ROM with connected and without connected head stack.
Unfortunately, I don't have got that SO8-clip, I had to unsolder the ROM, solder some wire on it and put it in the programmer.
Old drive with new PCB and old ROM wasn't able to connect via WDR, too.

If i understand correctley there are 2 ROMs on those PCBs, not one. The MCU have ALLWAYS a masked ROM and then there are the other ROM that you can read/write with WDR and that one can be Masked inside the MCU or not (Soic8). The ROM inside the MCU is loaded and then the other ROM is loaded too. Then drive will spin and information on ROM used to read program on service tracks/modules. SA might be written on any part of the disk, it doesn't have to be on the middle, and it's usually near the head parking zone (for drives that park heads outside then SA is on the outer track, for drives that park heads on the center, sa will be near the center), idea is for heads to reach sa in the faster way possible. Heads just "read" but on some drives, adaptive info on ROM is required for the data on sa to be read, that is why in some drive if you have a drive that was manufactored exactly at the same production line and time, even if the serial number is just nex to the other (drive produced next to the other) you can't get away with a PCB swap without exchanging ROM too, because of adaptive info stored on ROM. Yes, you might be able to load SA with some method and fetch a copy of ROM from there, or some other trick that pros like BlackST might know and will never tell, or with tools like pc-3000, but that is not the point. The point is, without tools and without swaping the ROM, ife there are adaptives on ROM you will not get away with a direct PCB swap unless by some miracle (or coincidence) you get an exact adaptive match.

When the drive loads all info from firmware it will hopefully identify with it's real drive name, and not something like the family name. If the drive identify with something like "buccanan" (on this case of this user), then it means that SA was not properly loaded to drive RAM and executed .


Let's assume SA is bad. You will have to LOAD from a loader file (external) using tools like PC-300 or Sediv or whatever containing data for the drive to start (code that normaly the drive would load from SA but now it can't). Only then you are able to access SA and read it or test heads. If SA have damaged modules that are essential for the drive to work, it will not boot (like a windows with damaged kernel). Then you execute a loader (like running a bartPE or hirens boot windows xp) and with that loader on ram you read SA to find bad modules and repair them (you use the portable windows to copy back the damage kernel files to the windows on c: partition).

Please view this video :

http://www.youtube.com/watch?v=BstYNyOZVrE

and part 2

http://www.youtube.com/watch?v=-lOAOMgBRQo

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.

Nope. Acording to my research only the first line on the MCU must match (EMBEDDED ROM CODE VERSION) and that was identical in the case that we were trying to recover .... 88i9045-TFJ2

_________________
1Q9xrDTzTddUXeJAFRn37aqh1Yr6buDCdw - (Bitcoin Donations)
paypal.me/Spildit - (PayPal Donations)
The HDD Oracle - Platform for OPEN research on Data Recovery.