On 6.0 (and 3.0) :

HDD - (Select your HDD)
It will open a window. Right Click on it, chose :
Service - Modules Operation.
It will open another window.
Right click on it, chose :
I/O - Read All and I/O - Check all , etc ....
It will copy the modules to the working directory.

For depoping heads on 6.0 :

Service - Edit Heads Map. Depop Head.
Put on the box the number of the head you want to depop. Press GO

To do it on RAM :

Actions - Change Heads Map in RAM.

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

@ michael ...please let my topic away. go make your own one.

now news.

got the programmer today. just for fun..the item arrived in town on 31 march..so I waited 5 days for 5km.

now..

found the problem. see the bricked rom and the original attached. there's a missing block of 512bytes 0x200. 3.0 missed one sector during flash!

don't know if there's a bug in the 3.0 or perhaps the windows trying to detect the device exactly during the device flashing. that's why it is better to "hide" the drive behind a box. windows won't know about the drive because this is handled by the box.

to remember..the problem was on the donor's pcb, which was bricked during playing with 3.0 while depoping one head.
after flashing a good rom and I was surprised that the donor drive acted like the dead one...changed the PCB from the old drive to the donor and nothing changed (last time I did that..the drive started..so i knew that should work). still dead..I mean..clicking 5 times..not finding SA!. then I said..that's it..the preamp has gone on this drive too. but after putting back its own pcb..I observed that I didn't tighten enough the screws. so I paid a little more attention when screwing and the drive started nicely. this is another possibility for a drive to appear as dead and clicking like not finding the SA.

with the programmer along, I did first test with my flash_write function. It was written some time ago but never tested I can say that after the write, the pcb doesn't reboot. so I can read again the flash and compare with the one I flashed..to check if match.

see the log:


and finally I attach an image with the programmer. the soic8 clip it's a little difficult to be placed on rom chip, and has the wires soldered in a way not compatible with my ST 25P10 so I had to use some wires to reorder where the pins go.

Look at the pictures attached.
Those are from 5.3 manual. They are present in 6.0 too.
Modules Operations are present at 3.0 too.

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

Very cool and thanks for sharing.
Good to know that you have your testing drive ready for more fun
Also i like the programmer and clip. Keep up with the good work.

In the future it will be a thing to take intro consideration when flashing ROM on PCB .... Do not power down the device when you finish flashing, read again and compare if it's indeed flashed as it should

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

Very cool piece of code

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

I've already put that in one function. Imagine that if it's not done automatically..You'd have to dump the rom..open a hexeditor..search the dir where the dump lies..search the original..compare..see the result

Not really, i would do a MD5 hash on the original and compare with the md5 of the downloaded copy after flashing. And i would do that only on drives with masked ROM on MCU.
At any rate its a good function to have

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

why do md5 hash since I compare byte by byte..the write_from buffer with the buffer holding the flash read after a successful write.

here I do exactly that, I mean..download the flash and compare it with what I wrote.


any good programmer's software has this option...to automatically check the flash after write.

@Louis

What's the situation with H1 ?

H1 of the donor..still dead

however, having now 2 hdd to plug into controller I have learned how to send commands to any of them. I implement functions but I test them and fix them as I have the occasion.



here's the donor and the other old model I purchased this week.

Here we go.

Now I'm speaking about donor's dead H1, or why I say it's dead.

why it's dead? attached a zipped file

I managed to read sector 1 and 2 at the beggining of the SA (cyl -1) with defective Head 1... resulting 2 files:
->dump_head1_cyl-1_sec1.bin
->dump_head1_cyl-1_sec2.bin

to obtain the mod_01 (dir module)..you should stick together the first 0x200bytes from both files. compare it to the original H0 mod_01.

I copied the files and called again the function. do the same with the files and compare the results.

you'll have H0 mod_01 (the good one), H1 mod_01, and mod_01_copy

each time I read H1 it will return BOGUS data. although there are some bytes that match the good data...those bytes are not FIXED. so.. it's not a defect on the platter. the data is corrupted somewhere between the [head and preamp].

say it's not like that

now you know what this means:

Yes, head is gone for sure
I think that i can say that "you have lost your head" this time
lolol

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

now I try to apply the same method to my dead HD (the one from which I've started this topic), but i get the perm_ovl_not_loaded error. the kernel needs some stuff inside SA to let me exec my function.

so I'm working at load permanent overlay function. my model it's not royl. basically I understand that this load perm overlay..maps the sata module 0x11 to the MCU's ram...it's another method to force loading some modules when they are not available in SA. I tested my implementation on the donor's PCB alone..and it loads its SA dumped mod 11 from a file. when I try the same thing on the dead hdd, I get a complain about "not compatible". obviously I used the donor's mod 0x11.

yeah..the mod 11 holds the zone table described here.

the kernel needs it to know the sectors per track (SPT)..and the lba start/stop for the Zone Zero (SA zone). I have loaded the mod 0x11 to my donor's pcb (not mounted on hdd) and after that I can read the Zone Table.....the kernel doesn't complain with perm_ovl_not_loaded

here's a 10 points question: if the head returns randomly good data...see the previous posts, then how the heck it is able to surf the Servo System...to find its tracks, because this involves reading the disk?

perhaps it tries many times until it finds the servo track...then find data tracks with a lot of work..since it returns a lot of bad bits. let's say..that after some percentage of errors it wouldn't be possible for the head to scroll through the tracks.

perm_ovl_not_loaded

Perm_OVL = Permanent Overlay = Mod 11 .
It will allow you to run the WD HDD when you start in it "safe mode".

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

somethings not good.

I put my donor into "safe mode"...(all 4 jumpers set since it's a sata model). power up..it identifies as wdc rom..normally because it's in kernel mode, not spinning. then I load perm overlay. it loads it fine because it's saved from its SA. then I spin it up. then I try to access the SA and it does like the dead hdd. clicks and nothing. it seems that mod_11 isn't enough to let me access read the sa. so what else to do?

... This is a strange statment ...
What are you using to load perm ovl ?
When it loads to RAM i think drive should start spinning automaticly.
I can test this later.

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

no..the donor seems to be dead. remember that I had few previously mentioned situations when the donor...acted like the dead drive. and I tighten the PCB screws and finally started. last night... had the same situation after swapping PCB's for testings..and when almost to give up..it started..but this time the trick with screw tightening...didn't worked

today..I've put all the jumpers at the back..and after that...it started to click..and I posted the situation (my last post). the rom it's fine. perhaps the connections of the PCB with the HSA are damaged since I did a lot of PCB swapping.

what's funny is that I load perm overlay then I call read head function..and then it starts spinning and it does exactly like the dead drive (5 times 3 clicks) and at the end returns success but the file it's filled with 0x00

Now i'm confused.
Can't you test that with a known good drive ?
Because you now have 3 drives.

1 - The original one with assumed dead pre-amp
2 - One donor that is good except for one dead head
3 - One old WD drive.

Are you talking about drive 2, right ?
Are you saying that you re-flashed the ROM on the drive and it didn't revert back to the prior state ? Drive with just one dead head ?

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