WD2000JD problem

[louis]

I'm developing my tool

I load it from locally saved mod_11. (mod 11 ...of-course it's a backup of the donor's SA)

now..

I deleted mod_01 from H1 so the donor can't load any mod. I'm in safe mode now. to test the deletion, when I try to read mod_01 (with a vsc command)...I get 0x5181 -->> DISK_DAM_ERROR which it's good since the kernel tries to load the file from H0..where it's deleted...then tries the H1 which it's defect (errors posted early).

for any other mod I get 0x3701 -->> FM_ERR_DIR...which meand..the dir module (01) missing/error

I can read the SA without any mods loaded...I'm in kernel mode!! I didn't load any perm overlayer at this moment! so this brings light into my mind
there are vsc functions which throws 0x3042 -->> VSCE_PERM_OVL_NOT_LOADED...so requires mod 11 to be loaded...but THE SA ACCESS DOESN'T DEPEND ON ANY MODULE. THE SA can be empty...and the kernel still can read it.

[louis]

100% sure

there are 2 copies of each mod: ..H1 and H2. the kernel loads H1 and if H1 mod is bogus..then it tries H2 copy. there's no need to del mod 11 since the kernel wont know where it is..if I delete the mod 1. mod 1 has the locations inside SA of all the mods! so..what i did it's the same as del entire SA!

who knows where perm_ovl it's required. perhaps when writing? more test needs to be done. I'll try to fix back the mod 1 to check if I can without perm ovl.

[louis]

I did the write mod_1...without any perm_ovl, directly from "safe mode".

don't know what will happen when you try to read the sa as you go to its limit...since the size it's given in mod 11. perhaps a safe cylinder border it's hard-coded in kernel. as you change zone...you'll need the adaptives...which are in other mods...so you won't be able to do self scan or complicated stuff while all important mods are missing from SA. you may safely limit to SA operations only.

perhaps the perm ovl it's required by those tools to get the SA SPT (sect per track). when the tools want to write mods on SA they want to know the SA size...to know how much can go writing mods. the size it's given by a vsc command but only after perm ovl it's loaded.



if you can't read the SA the preamp it's dead

[louis]

Did it really write to SA ? and can you read it back and compare the files to see if was correctly written ?

yes. in fact I erased only one sector..the first sector in SA for H1. it's equivalent, if you like..to erasing bootloader for windows...it won't be able to find any file..although the files are 100% there.

By the way, SD WD doctor have a function to read SA at a lower speed, to gain access to SA. Any clue about what it might be and any use for it ?
Starts to look like obscured lies ...

don't know about it. it is for all wd models or something specific? let's don't blame for what we don't know.

Now that i think about it, i've read somewhere (pc3k or salvation manual) that when flashing WD ROM one should always do that from safe mode.
Maybe what happened with you the other day was related to the code on the drive using RAM or buffers the same time it was flashing ?
At any rate i like the fact that your tool checks for what was written.

"Safe mode" can be achieved by dismounting PCB from hdd (if you don't know the jumpers). the kernel doesn't load the SA. it is safer because the kernel doesn't do any other data transfers and leaves the MCU handle only the rom write. on the other hand, it could be a software bug. if the software continues writing I/O port although the device say... stop..I'm busy..the data it's missed.

[louis]

Removing the pcb is the same as setting the jumpers ?
Even the totality of the ROM code is loaded when you set the jumpers ?
Is there any advantage of setting the jumpers over removing the pcb ?
Can you test to set the jumpers and try to read ROM ?
The only advantage that i can see is if spindle controller is damaged you can set jumpers and prevent it to lock the pcb so you can read ROM ?
Maybe some other modules of ROM are not loaded with the jumpers ?

1. it has the same effect. the kernel doesn't read the SA. the result is: "kernel mode" aka safe mode
2. I think so.
3. You dont use the screwdriver
4. the rom reading it's not influenced by any jumpers. yes it reads fine with or w/o jmprs.
5. I noticed that when the PCB is removed..or the safe mode is on via jumpers..the pcb identifies with 0 heads. I have to spin it up to update its head number. when it's 0 heads..if I send it some commands which involves heads..I get an error..invalid-head. mod 0xa which it's inside rom..holds the the H number. so you can see that it's loaded only when needed. we can link the heads number module loading...by the spinup action. I believe that the first call made internally by the kernel to the function which spin the motor..initialize the head number..by reading mod 0xa.

[louis]

case of a dead head. which in fact wasn't dead.

so the mod 47 (sa adaptives) located in rom...can be regenerated from SA's mod 41 (which contains also the mod47 data). if you have the same rom version.

[louis]

and..if a head doesn't work as it should be this could be a cause..and should be checked. compare mod47 against mod 41 to see if somehow mod 47 wasn't corrupted.

[louis]

I check it with a hexeditor. Now my H1 mod 47 differs from mod 40..since I've deppoped the device. when depopping, all the adaptive data are cut to a lower head number (mod 47 ..40 etc). so if in example you have 2 bytes/head (some adaptive info like mr offset dac etc)..for 4 heads..you'll have in mod 40.. a table with N entries of 2ytes x 4heads = 8 bytes each. after depop..the table will have 2x3 = 6 bytes each. so 2 bytes get lost. if you repop the adaptives can't be recovered...those N x 2 bytes...so you have to write the entire mod 41 again..from backup...as it was before depopping.

in my case...I've tested the H1..with no SA mods loaded..it's still dead...or perhaps it's rom mod 47...has wrong adaptives...for SA. but I've checked against the original mod 41 (the first dump I've made when putting the hands on it)..and does match..so it is possible that the firmware was corrupted before the device arrived to me.

it would be interesting do a depop with a known tool dump the modules and compare with a backup to see exactly which files gets modified

you can see in this image, there are 4 heads..if you cut one head..it will look like I explained 2x3 followed by 2x3...

[louis]

back at "safe mode". just implemented a "write mod" function and had the occasion to test what's happening when writing in "safe mode".

in "safe mode" the vsc command let me write only the mod_01. for any other mods it gives me FM_Dir_ERR. last time I did only mod_1 write so the study result was partial In normal mode...the vsc command let me write any mode.

if in safe mode I load perm ovl...then I can access the zonetable. but look how it looks.

zone table in "safe mode" with povl loaded.

Code:

Zone 0 (this limits the Service Area!!)
---------------
First Virt. cyl .. = 0xffffffc0 (-64)
Last Virt.  cyl... = 0xffffffff (-1)
First LBA......... = 0xffe00000 (-2097152)
Last LBA.......... = 0xffffffff (-1)
Sectors per Track. = 0x0384 (900)
Zone 1
---------------
First Virt. cyl .. = 0x0000 (0)
Last Virt.  cyl... = 0x22bf (8895)
First LBA......... = 0x0000 (0)
Last LBA.......... = 0x0000 (0)
Sectors per Track. = 0x04b9 (1209)
Zone 2
---------------
First Virt. cyl .. = 0x22c0 (8896)
Last Virt.  cyl... = 0x39bf (14783)
First LBA......... = 0x0000 (0)
Last LBA.......... = 0x0000 (0)
Sectors per Track. = 0x04a4 (1188)
Zone 3
---------------
First Virt. cyl .. = 0x39c0 (14784)
Last Virt.  cyl... = 0x5eff (24319)
First LBA......... = 0x0000 (0)
Last LBA.......... = 0x0000 (0)
Sectors per Track. = 0x0480 (1152)

zonetable with drive started in normal mode

Code:

Zone 0
---------------
First Virt. cyl .. = 0xffffffc0 (-64)
Last Virt.  cyl... = 0xffffffff (-1)
First LBA......... = 0xffe00000 (-2097152)
Last LBA.......... = 0xffffffff (-1)
Sectors per Track. = 0x0384 (900)
Zone 1
---------------
First Virt. cyl .. = 0x0000 (0)
Last Virt.  cyl... = 0x21bf (8639)
First LBA......... = 0x0000 (0)
Last LBA.......... = 0x24fdf9d (38789021)
Sectors per Track. = 0x0463 (1123)
Zone 2
---------------
First Virt. cyl .. = 0x21c0 (8640)
Last Virt.  cyl... = 0x473f (18239)
First LBA......... = 0x24fdf9e (38789022)
Last LBA.......... = 0x4d880c0 (81297600)
Sectors per Track. = 0x0453 (1107)
Zone 3
---------------
First Virt. cyl .. = 0x4740 (18240)
Last Virt.  cyl... = 0x573f (22335)
First LBA......... = 0x4d880c1 (81297601)
Last LBA.......... = 0x5e67f99 (98992025)
Sectors per Track. = 0x0438 (1080)

so..it seems that in normal mode..the LBA-s for the rest of the zones are initialized. also if you look closer..the cylinder values are also changed

[louis]

nope..only mod_01. but didn't tested the raw_write...via-> cyl, head sector.

[louis]

as I mentioned..there are more ways to write SA:1. using a vsc command which writes a module..on both H1 H0 (the test was made with this; this it's the easy way..because you don't spec where to write the file..it's handled by the kernel which puts the file where mod_1 tells); 2. using a raw mode..where you spec cyl head sect to write. 3. using lba mode.

so you see...there are more ways still to be tested.

[louis]

didn't implemented such a function right now. I'm still customizing/tuning the low level access functions which are the base of the application. higher level functions will use those functions to do more or less complicated stuff.

[louis]

don't know..because I don't know if I'll be able to finish it.

[Nesa]

@Louis

Good work. It seems to me that Louis is hooked on hdds

I know that feeling All those bytes in all those modules can be very catching.

[louis]

I can write in "safe mode"..using raw write function..aka write_cylinder_head_sector.

the programs need a directory where all mods are backed-up...and the name of directory mod. then it checks all files in that directory..for check-sum and other stuff. it only retains the backed mods that bypass the checking. then it writes the mod files on H0 and H1. before writing...I check if the area it's readable..(to prevent doing more damage) then if ok..write..then read back and compare the local file to what it was written.

here in the log..mod 2d has an invalid day/year etc in header. also..my head 1 it's dead..so I'll have an error when writing that head.

Code:

checking 109 modules using program's internal function
module has an invalid day: 0
invalid mod MOD_2D.bin skipping this file...
108 valid mod(s) and 1 invalid mod(s) found inside dir C:...WDC WD2000JD-60KLB0_08.05J0_WD-WCAMT131983-ORIG\SA Modules
writing only valid modules...
0. mod: 0x01
        H0-> success
        H1-> wd_smart_write_log: error register is on. aborting...
VSC error code decoded: 0x5181 -->> DISK_DAM_ERROR
wd_read_pchs: send_wd_cmd failed, aborting
1. mod: 0x02
        H0-> success
        H1-> wd_smart_write_log: error register is on. aborting...
VSC error code decoded: 0x51A2 -->> DISK_ECU_UNSAFE_ERROR
wd_read_pchs: send_wd_cmd failed, aborting
2. mod: 0x34
        H0-> success
        H1-> wd_smart_write_log: error register is on. aborting...
VSC error code decoded: 0x51A2 -->> DISK_ECU_UNSAFE_ERROR
wd_read_pchs: send_wd_cmd failed, aborting
...

[louis]

strange stuff. when doing some software tests...the donor died again. what seems to bring it alive it's getting the old PCB..putting it on the donor drive...again remains dead too...and put back again its own pcb. the old pcb seems to somehow "unblock" the preamp. off course there could be many other things related to this situation...but this it's the third time I'm bring it alive like this.

[louis]

wow...after some work I think I may have fixed a "little" the H1

I can read the H1 on SA without errors (at least on first 2 tracks where I tested). now I've just written the mod_01 on H1 and read it successfully. the data read from H1 after the fix..was bad, so the mods doesn't exist there in a readable form.

it's about what I said here. mod 47 form rom.

5. read again. mod 47 holds adaptives for all heads in SA!!..if adaptive for head 1 are defective but the H0 reads fine SA...then if the adaptives exist again in mod 40...H1 could be fixed by reading from there the correct values data dac, mr etc.. SA exist in 2 copies..one on H0 (main used) and one in H1.

in rom..in mod 47..there's a single word which it's the MR Jog parameter for H1. If H1 can't read the SA..then that word it's bad...or the head it's physically damaged. I did some changes, manually to that word..in mod 47 then uploaded it to the rom

I must do some more test to see if the entire SA it's accessible to H1. but one think it's clear..I don't get those dam..ecu errors.

[louis]

"you will never be able to understand a fraction of what data recovery is all about"...

I bet u do. a lot.

G.F.U!

a lamer is one which think that if he pays 10k for a soft..it's a "pro". and unfortunately there is plenty in here..all telling...send your hdd to a pro.

better, why don't you tell us..how to generate the mr jog or servo data for a bad head?

[louis]

next.
I'm in "safe mode". i noticed that in this mode the size of the device reported by ATA ident it's 1 sector! also until it spins..it reports 0 heads.

I load permovl..and extract the SPT which in 900...and last Cyl..which in -64. then I try to read each track from sector 1 to 900. after track 32 I get DM_HEAD_CHK_WRONG_CYL_FOR_RSVD_AREA

also I get random errors on track reading. so..when I read H1 on SA..once I get 3 tracks with errors..and next time other 2 tracks... or 5 tracks etc.

I have around 450kb/track.

[louis]

why?

now it's much better. I did a low level erase...which means I filled all 32 tracks for H1 with 00. now when I read all tracks for H1 (SA) ..almost every time I get success. from 4-6 tracks with errors...now I get max one.