@louis,

you want to connect let's say to J2 on 1477 boards ?

I want to debug live the mcu. for personal study. find the compression alg for the rom image etc.

You didn't answer : it's like saying "I want to diagnose my car" - "Do you want to connect to OBD ?" - "I want to see what's the problem and the actual readings" : there are many ways to do what you want, some are feasible other not, other more or less are , some maybe work only (worked...) at factory level... but it's not necessary either to reinvent the wheel nor complicate life. You have RAM and ROM to work with but first you maybe have to RE some code !

Good luck, anyway - it remembers me some time ago when I was more interested in R&D...

if you know other ways to debug a wd pcb, other than connecting through Con1, then your discussion make sense.

when u say..reinventing the wheel...first you must understand how the wheel works. I prefer to trust my own senses, not some guys which tell..don't do that..do that...and when u ask them why..the answer sounds like "because". many don't know that shifting left n pos 1 bit means 2^n but they are ready to learn u how to not reinvent the wheel..."with only 2 resistors" . they blindly apply things that they do not understand and the progress they deliver to the community it's a big 0. haven't read many topics here, but the most interesting topic I've read it's Dejan's Mcu jtagging. offcourse, there are some users here which really helps like fzabkar and spildit and perhaps others, but we have all to agree that gurus are very rare and they don't lost time answering stupid questions like ours/us

so, can u tell me, what u do with a wd VDT drive when the preamp it's dead. the original HSA has variable SPT per head per zone. u do a head swap, but the data it's written at a SPT that it's head dependent. I don't know for sure, I don't have any experience in DR but I assume that the last years this VDT drive option was a mass one in the fight for more&more higher capacities.

Indeed, the most interesting by far. In fact that's a case where intelligence trumps experience. You can have 30 years of experience swapping boards and replacing heads, but sometimes the task requires fresh insight, innovation and an understanding of first principles. ISTM that the data recovery profession relies too much on rote learning and expensive tools.

As for the accessibility of the JTAG pins for the purposes of attaching wires, I see no problem in using the plug on its own, provided that you have good eyesight and reasonable soldering skills. In fact thirty years ago I used an ordinary, portable, temperature controlled soldering iron to replace a fine pitched QFP IC, in the field. In your case you just need some wirewrap wire and heatshrink tubing, plus practice.

_________________
A backup a day keeps DR away.

I change heads and if necessary fix the firmware if it has got damaged, and/or make some adjustment depending on drive. That's all. And it works 95% of times. I don't recommend other ways, but it is sure that at that point tools like a DDA and PC3000 do make a difference.

Smart Attrib Table..it's a sector of 512 bytes. the drive firmware respond with it for an ATA command. WD holds some secret attributes. to see them we can download the module 21 and search for the smart sector deep inside.

here's a first screen from my gui app. according to ata specs, each smart attrib has an ID, a flag and the rest of columns u can see (12 bytes). there is one more table for threshold values. the flag's bit 1 tells that the attrib its vital (the odd flags). it turns to red when any of current or worst values became lower than threshold. the current and worst values are generated by firmware, based on the "raw value". let's say that the drive starts to make BADs...then the smart code in firmware..checks how many bads are, and lower the worst and current values using some scaling factor. I made yellow the bad related attribs to warn that something it's going bad. if you have any idea what to color in addition please let me know.

in the picture I opened a 21 mod file..(royal drive), and parsed it with my code. in addition I could get the smart sector from the drive with an ata command, but it will miss some hidden attibs.

so a drive it's failing if an attrib with odd flag has the current/worst values lower than threshold.

the wd mod 0x21 seems to have a shadow copy(not seen in directory mod 01)...named mod 0x20

I notice that you don't issue warnings for hidden attributes, eg attribute 0xC3.

BTW, flag bit #7 appears to determine whether the attribute is hidden.

Hidden SMART attributes in WD HDDs:
http://malthus.zapto.org/viewtopic.php?f=59&t=127&p=155

_________________
A backup a day keeps DR away.

if we can see those hidden...attribs..then it doesn't matter what bit 7 is wanted to let the column header clicks sort the items by flag. inserting your H there will screw the data.

the log you posted in your link it's from a parser made by u?

Yes. I'm not just a hardware guy. :-)

_________________
A backup a day keeps DR away.

tried to edit the smart table and upload it to SA. it doesn't work

the write mod 21 ends fine, with no error..but when I read it back...it doesn't reflect the modifications. perhaps that table it's only a reflection of the data stored in another places and gets overwritten back as soon as I change it.

IIRC, MODs 20, 21, and 22 store the SMART data. If you compare the raw values of the Total LBAs Read and Written attributes, I believe you will see that one MOD is updated before the others.

_________________
A backup a day keeps DR away.

WD6400AAKS with some stuff on it

no soldering, just some elastic rubber bands.

this cpu has 2 TAPs (test acces ports) not quite like in Dejan's sample. to build a working script we must auto-probe the TAPs and add all to the feroceon.cfg to be able to halt or debug. newest CPU's have more TAPS, each one controlling something (cores etc)

I used OpenOCD with a usb jtag debugger, wired to a mictor breakout. the jtag con1 fellows this arm cpu specs.

basically with this setup a new firmware can be written to ram which is just what we need to temporary start the pcb, access it with a software and flash the internal rom. of course you could study the firmware's flash_write code, write a injector which then flashes the rom as soon as it is executed.

however I couldn't manage to connect to the PCB for which this thread exists ..maybe the con1 has other wire scheme for old pcb's, or the contacts are not quite well.

meantime I found another donor somewhere in France. what I need now it's a clean room and some practice with head replacement technique.

wow. I managed to hook also the wd2000jd. (it seems to be from the contacts) the TAP it's like dejan's



MCU 88i6540-lfh1
MDL: WD2000JD-60KLB0

this would be nice to debug, since the bootstrap it's quite small. the unpacking code etc.

I'm trying to figure out what's the compression algorithm for the firmware's blocks and I think I got something. I'm doing IDA debugging but it doesn't work to well since it seems it doesn't handle well instructions stepping; also the "touch only" connections seems unstable and I'm loosing control frequently. right now I'm debugging first block of the firmware which it's a loader which unpack and map all the remaining blocks.

I found that the second byte (the first it's the block number) in each block's header has the first bit indicating if the block it's compressed.

the uncompressed size of rom blocks it's made from 2 words in header. the lower word it's at offset 0x1C in block's header. also if you scroll at the block start in rom image, you will find the the uncompressed size also there, the first dword.

the decoding/uncompressing routine it's in the first block (ID it's 5A aka block Z), which it's not compressed and it's executed by the bootstrap (code built in MCU which loads the firmware);

you could analyze the first block with an arm disassembler.

from what I've found it's seems that the algorithm it's a sort of LZAH

Here we go. The first version of the firmware unpacker

I have extracted the rom blocks from a firmware and unpacked them using the tool. Attached the zipped files. When the drive starts clicking and the fails with "WDC-ROM SN# XYZ----" "WDC ROM MODEL-BUCCANER-"..look at the unpacked block 6 => bk6_up.bin

btw. I've finished the packing option too. The tool it's now complete for "rom modding"

seems that wd switched to mictor 40 on newest hdd models.

louis - Did you finish the compression option for your unpacker? The version posted says unimplemented. I'm very interested in this exploration.