Need firmware for pc3k WDC WD20EARS-00MVWB0 25.12E

[Spildit]

Can the soft read with ignoring read errors?

Write click on the ROM Modules window and chose "Read All". It will read all it can and save a copy on the working directory selected on the utility. But i don't think the problem is there. I would try first to take care of that translator list/mod ...

[Spildit]

Wait Wait Wait ----

Let me see !

You had a bad PCB.
You replaced PCB.
But you swapped ROM.
So you have Donnor PCB + Original ROM.
Let's assume that Original ROM is damaged / currupted. That will display that error that you show on WDR Log.

Do the following :

- MOVE ROM again from donor PCB back to DONOR. This will make a PCB at the state dyou recieve it when you aquired it, hopefully with 100% good ROM.

- Now drive will not work correctly because it will lack adaptives.

- Use WDR and do the REPAIR. Wait for it to fisnish. The REPAIR will copy adaptives, etc from SA to ROM. Flash ROM. This will copy good adaptives info to good ROM on PCB making a perfect ROM on the PCB.

Makes sense ?

[Spildit]

Can the soft read with ignoring read errors?

When you READ wirth WDR it will save what it can read, ignoring the errors, to the selected folder on the software.
But if ROM is bad to start with ..... It might be causing problems .... ASnd there is no point in flashing BAD ROM anyway.

[Spildit]

Or maybe it's indeed a week/damaged Head ...

[Spildit]

Or maybe it's something else .....
Bahhhh !
Sorry, i trully don't know what the problem with the drive is.

[Spildit]

If i try to do flash repair i get error 3746 on module 107?

flash repair.JPG

What is module 107?
It's normal that is not shown in module list?

Where is module 107.JPG

Ok ...
I think that ROM is ok.
I've taken a better look.
I think that Module 107 is gone from SA, either it was deleted or something haoppened to it and it's gone, so Rom Repair doesn't work as it should because it can't find mod 107 and then outputs that error.

[michael chiklis]

I did selfscan module repair to repair those 4 errors, but didn't fix them.
As you can see in the pic selfscan modules F0 - F1 - F2 - F3 get error 3746.

I cleared module 32 (Translator Grown) and then i opened the module file with Hexworkshop (it cleared).
Then i did quick translator with P-list (WDR wrote "successfully"), but it's still slow.
Then i went into module operation menu, Road MAp - Via Enumeration and i found much more modules, also module 107 but it's corrupted ("read all modules" button doesn't really copy all modules, i don't know why).
I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

Module 0B:

Still slow...

So i flashed the firmware from the donor pcb and pushed "repair", but still the same problem (also i still get error on module 107).
Then i flashed again the pcb with the original rom, of course il still the same...

So I gave up and I realized that it is a problem of heads as you were saying at the beginning
So I wanted to try once again to test the heads, guess what ...

Now WDR detects bead head (only head 1), until yesterday it reported GOOD

Should i try to depop head?
I will need help how to do it because i never did in my life...

Thank you.

----------------------------------------------------------------------------------

P.S.
Now head 1 is reported again good

Attachments

Log.txt

(529.01 KiB) Downloaded 517 times

[Spildit]

- Maybe Head 1 is failing but not totaly dead.
- If you depop you will loose data.
- Mabe you have a bad block on SA on the place where that module is stored and so you can't write it back.

[Spildit]

To depop :

Service - Edit Heads Map
"Depop Virtual Head" - put the number of the head on the box, select the check mark on "clear translator" and click GO.
You will loose all the data in the drive.


Regardng the module you are trying to FIX, it should be a ROM compy, so no problem with that, it's not essential to the working of the drive. I guess it have a bad sector on that part of SA, you would have to create the module on other SA track (empty) and change road map to point to the new location of the module. Don't bother to do that. The module is not needed for the working of the drive, it's just a ROM backup. Thta is why you get errors regening ROM.
Also, it's just that modules that is damaged or did you find more damaged modules ?

[fzabkar]

I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

You need to edit the MOD. Change the MOD ID from 0x000B to 0x0107 and then recompute the 4 checksum bytes. Pad the end with 0x00 bytes until it's the correct size.

If you upload the binary data for MOD 0B, I can do this for you.

[Spildit]

I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

You need to edit the MOD. Change the MOD ID from 0x000B to 0x0107 and then recompute the 4 checksum bytes. Pad the end with 0x00 bytes until it's the correct size.

If you upload the binary data for MOD 0B, I can do this for you.

That is correct ! I missed that !
But at any rate the module is just a ROM backup file on SA. It doesn't influence drive at all. It's just the ROM backup copy. Drive will have the same problem. But of course, OP can try !

[fzabkar]

You need to change offsets 0x08 - 0x09 from 0B 00 to 07 01. That's the MOD ID in little endian format.

The checksum bytes are computed as a 32-bit little endian sum over the entire MOD contents. This checksum is located at offsets 0x0C - 0x0F.

The new checksum is computed as follows:

new cksm = old cksm - (new MOD ID - old MOD ID)

= 0x826D3862 - (0x0107 - 0x000B) = 0x826D3766

Therefore you need to edit the checksum bytes as follows:

offset 0x0C - 0x0F from 62 38 6D 82 to 66 37 6D 82

You might like to use WDR to confirm that the checksum is correct.

[michael chiklis]

I read description of module 107, it's wrote "copy of id0B", so i copied module 0B (which is ok) and i renamed it 107, then I/O and write it, but it doesn't fix it (module 107 remains corrupted).

You need to edit the MOD. Change the MOD ID from 0x000B to 0x0107 and then recompute the 4 checksum bytes. Pad the end with 0x00 bytes until it's the correct size.

If you upload the binary data for MOD 0B, I can do this for you.

~id000B.txt

(512 Bytes) Downloaded 340 times

[fzabkar]

FWIW, MOD 107 doesn't exist in the following resource dump:
http://www.datadonor.net/HD%20Western%2 ... 0MVWB0.rar

Other MODs such as 102, 104, 105 are "NOT_INIT", so they don't appear to be necessary.

Bytes 0x04 - 0x07 appear to be 01 00 1E 00 in the SA and 04 00 1E 00 in the ROM. Maybe that part of the header needs to be edited, too. ???

[fzabkar]

I suspect that this is what it should look like:

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00000000  52 4F 59 4C 01 00 1E 00 07 01 01 00 69 37 6D 82


But I suspect that MOD 107 may not be necessary. Did you check whether the others were NOT_INIT?

[michael chiklis]

FWIW, MOD 107 doesn't exist in the following resource dump:
http://www.datadonor.net/HD%20Western%2 ... 0MVWB0.rar

Other MODs such as 102, 104, 105 are "NOT_INIT", so they don't appear to be necessary.

Bytes 0x04 - 0x07 appear to be 01 00 1E 00 in the SA and 04 00 1E 00 in the ROM. Maybe that part of the header needs to be edited, too. ???

Also in WDR doesn't exist module 107 in the module list, but it appears if i do Road Map - Via Enumeration

[Spildit]

It's a ROM backup, not necessary and not used at all by the SA/Drive. Forget about fixing that. The problem is something else.
I think it's indee head 1 that sometimes work and sometimes it doesn't work.
If you don't need the data, depop head 1, clear translator and do the quick format with p list. Test with mhdd.

[fzabkar]

I'm not a data recovery professional, so I don't know what WDR is doing. But if I examine MOD 01 with a hex editor, it appears that each MOD entry in the directory occupies 0x12 bytes and begins with 12 02 low_MOD_ID_byte high_MOD_ID_byte

So the entry for MOD 107 should begin with 12 02 07 01, but there isn't one. That might be why it doesn't appear in the module list.

I have no idea what "Enumeration" means in the present context.

[Spildit]

It means that none of us know for sure what we are doing !
At any rate i vote for bad head 1

[fzabkar]

ISTR from NazYura's documentation that he first looks for the MODs by consulting the directory in MOD 1. He then sometimes finds additional MODs that aren't in the directory. I suspect he does this by reading each MOD ID sequentially and then checking the command status. May be that's what is meant by enumeration, ie reading from MOD 0000 to MOD FFFF and monitoring the status.

ISTR that I once found a MOD 100 that didn't exist in the MOD 01 directory. I found it by reading the SA tracks and looking for "ROYL" signatures.