new thread with some work on Bootstrap internals

The donor has arrived. It is in a really bad shape outside. It has some marks from a fall down or something. First time I plugged in I was amazed by the sound...it was like from an old CD-Rom. Looking closer I realized that the air filter is half broken and missing. Patched with some scotch. It came in a plastic bag (which it's intact) with a sticker closing the opening..and since I haven't found the rest of the filter inside..I assume that it was sold like this..although the ebay seller stated "good condition"

Despite it's bad external shape, the donor works fine. It spins and I can access the SA..with my head/track/ vsc reading routine. I did the PCB swap...without any rom flashing. The result it's the same. 2 clicks repeated 5 times. So the problem it's inside. I tried reading the track -1 with the head 0..and no chances. I get the same error 0x4341 as before;

So..with a working PCB the same model, version etc I can't read any head on patient. This leads to a dead pre-amp, because the ROM information it's all that is needed by one head to go to the SA and read something on track -1. I assume that a module conflict (ROM<->SA) wouldn't influence the head reading. The drive won't work..but at least it would let me read the head, no?

YES. I HAD RIGHT. I did the swap in the opposite direction. The donor with the patient PCB. It runs..no clicking here...but it's identified also as WDC ROM BUCCANER (as I assumed before ).
Te "module conflict" SA-ROM modules...doesn't influence the head's reading (readability). I can read the heads in this situation! Basic stuff that no one wants to tell you. Yeah...I found it myself.

Yes. I did a short test, reading with a VSC the track -1 head 0...and returns fine the header of the Module 0x1...which holds the modules hosted on the SA. I've stopped here the researches, don't want to push the donor, because it has that hole patched and I'm afraid not getting dust inside.


Tried only on head 0, but it should work fine on all the heads. The problem should appear as we take distance from the track -1 and the read head doesn't stay on the same track with the write head. The adaptives handle that.


So if my be stored on AS..you don't need them to read SA. You need the head map etc..which on the same model..should be the same.


No...I know where you point...but I'm sure 100% that I'll get the same result as with the original PCB. It's clear...with the patient's PCB I can access the SA of the donor...not having any clicking, without any touch to the firmware.

My final diagnostic: dead-PREAMP.

Better, I would say here...when the reading arm it's orthogonal on the platter's radius. So it depends on the HSA position..where on the disk would happen that.

I think so.

I had some plans developing the tool on the new received donor...(especially working on SA modules) but because it has that filter broken..I don't have a testing hardware of course, I have around about 2 sata hdds but don't want to play on them an older one..on which I could play has ide con...not supported by working pc's mobo which has only sata connectors.

I'm waiting for a rom programmer ...because I plan to implement a "write flash" option..and I want a way to fix the rom chip...if I accidentally brick it during software tests.

some basic functions in my application

some words about WD mod_01.

mod_01 it's the first module accessed by the rom firmware. it's in fact a table holding information about all mods that are present on SA.

the mod_01 starts with a header. if the ROYL mark it's found at the beginning, this means that the firmware it's somehow newer..and the first 48 bytes forms a header. if not..the first 24 bytes...are the header of the old format.

the ROYL format it's somehow an enhancement to the old one. the mod's IDs are stored on 2 bytes..instead 1 byte....so more than 256 mods can be stored on SA on ROYL firmwares.

after the directory header...follows a series of headers describing each module.it is normal because the firmware must know where on the platters in SA is stored each mod. the number of headers (mods) is indicated in the main header...in case of old format..and for the new format in some bytes after the header;

the table entry describing each mod.. has a size of 8bytes...and holds the mod ID, the cylinder and start sector..+ size in sectors..so the mod can be read. on ROYL firmware there is another way of accessing mods..called LBA...so if this is stated in the main header (Bytes 16:19 "0002")...then the tables looks a little different having 18bytes size, in fact the first byte (usually = 0x12) tell the length; what it's interesting is that there is a member on this header showing the number of module copies on SA and a file attribute member, which doesn't exist on CHS way.

so to handle the mod1 parsing...one must read the header. if it's the old format...get the number of mods form this header (Bytes 10:11)..and then scroll down for each mode's table entry and get the mod. if the ROYL mark it's found...the version int field (starting at 16 byte) in header must be checked..to see if we have a LBA or CHS table for mods. then read the "number of mods" which it's found after the main header...size 2 bytes. the mods table it's located immediately after the "number of mods" for LBA..and 4 bytes after that..for CHS mode.

to examine this use a hex-editor and open a 0x0001.mod downloaded from here

^^ useless...for non-russian speakers

today some words about PUIS (Power Up In Standby) nice to have for hot-swapping pcb

while playing with my evolving app I came across a strange situation while implementing wd PUIS. there's a wd-vsc which controls this option, which means that the HDD will start without spinning the platters.

a flag with 4 options controls the PUIS type.


PM2 it's the PCB' jumper..

in my case, I wasn't able to set the drive in PUIS state with the PM2 jumper because the flag was set in firmware for "Disable PUIS, PM2 jumper ignored", which doesn't care of the PM2 jumper and spins always. I had the problem while setting the flag to "Enable PUIS, PM2 jumper ignored". on reboot the drive was silent...but it doesn't wanted to respond to my VSC commands (returning HOST_UNSUPPORTED_ATA_OPCODE), in order to set it back. more...for the ATA identify command (which it's the standard method to detect present hdds)...returned an empty structure. so what to do? (flash firmware? I don't have the tools.)



If you enter in this state..you won't be able to sent VSC commands to restore back the flag; on the other hand, windows seems not to know how to start the device. perhaps the bios should handle this. I didn't made researches on how to start the hdd with external methods so I coded another ATA command to sent to device in order to exit from PUIS state.after that, the firmware accepts again VSCs so I was able to reset the PUIS flag to jumper controlled.

Here I've implemented a check to see if the device it's somehow stacked in PUIS mode. This is the respons for ATA_IDENTIFY (0xEC)

yeah, I tried to find some useful software tests for the inside components ...servo..preamp.

I'm doing some tests on the good drive. I get fine results..no error if I call functions in a logic order.


but if I stop the spinning the platters and call actuator init I get an error. the drive doesn't start spinning:

I assume that servo_actuator_init needs to access the SA to read its data, but since the drive it's not spinning it throws an error.

so the error code it's around my bad hdd error 0x4341; usually the numbers starting from 0xXXyy belongs to a specific part ie servo all wix 0x40xx etc

ok..more...

again about PUIS. now I have the donor PCB which Powers Up in Stand By based on the jumper I set on PM2 or not! (so a jumper which does the specs) since it doesn't start the motor, it means that that flag it's written somehow inside the rom firmware. I have translated the PCB to the patient and it it proved true. the patient with the PM2 set doesn't start (until I send it the right ata command). so, I've done a rom dump and compared to the factory default. the dirty flag it's written inside 0xD mod at the end of the rom. the factory byte it's set to 0x02...and after I did the VSC modification...to 1...the flash reflected it as 0x00 (so if I set a flag with the VSC command to 3...it will be set in firmware as 3-1 = 2)

attached the roms. use HxD to compare the diff. the "Orig" in file's name, marks the default factory firmware. the crc byte it's changes..the flag byte..and 4 letters

what's funny is that on the patient hdd on witch the rom firmware can't access the SA..the VSC doesn't let me change the PUIS...it throws VSCE_PERM_OVL_NOT_LOADED. basically it needs to edit itself, but complains about SA

bad news.

my donor seems to be badly damaged. it came unformatted so what I did till today..I did with it how it was. only tests with rom and SA. today booted under xp to test some stuff and did a format. played with wdr and did a sort of surface scan..and at a moment it started to make some really ugly noise. it was with the old pcb on it. now look how it looks. however the external shape...about I've told proved that didn't left untouched the internals.

I'm not interested in that...but I'm afraid the HSA not to be affected. the heads reads fine the SA.

not. now that I'm looking better I get some DISK ECU UNSAFE ERROR on head 1 in SA. and in the rest of the. m...damn. that pattern it's for a dead head. and since i didn't tested the donor from the beginning I don't know if the old PCB did that..when playing around with it mounted on donor.

this is what the owner left behind on head 0..cyl n sector z


tsted again backup all function and it downloads well the rom and SA modules. all modules are located on head 0...and therefore I could play fine with it till today, not knowing what lies inside

it sucks.

well, since I have formatted the hdd, now it's seen by wingoz. this is a big deal because it tries to access it and f. it. the device must be disabled from device manager, otherwise it will screw your operations!

as I said, the wdr demo or not reports ok on heads tests read...write etc. look in the image at the dos window...my app reporting head 1 down + the error. I'm 100% that the head is dead. I see it during debugging... the error and nothing came up in the read buffer.

more..wdr back-ups the files to a drive and unfortunately it was exactly the one I was working on, the donor. suddenly windows started throwing errors that cannot access that dir created by wdr. to play around..I did a head depop for head 1 and did a reset. then the entire modules list (except mod1) went red..with the error FM...bla bla...like on the other thread. while windows continuing popping messages with "cannot access ...blabla". I did a pc reboot this time, popped back the head and now the SA modules are fine. only that the hdd identifies as something else while it was WDC WD2000JD now it became WDC WD1200LB . at inspection the rom firmware is heavy changed in mod 47 (SA adaptives), so really I don't understand from where such large modifications and what was touched inside that mod.

wdr3 demo and full too. look at the window's title.

I'll wait for another donor to appear at a decent price on ebay. this one It was sold only to us..that's why I purchased it through a guy which can buy in us ans ship to me. so no doubts that I can do anything at this moment. one with only a letter in DCM slipped through after already placed the order for this one..

there's a tool around to check the royl module's checksum.

fzabkar someday said:



What he didn't knew, it was that the module sum correctly...but the tool is the problem, it misses something

I've worked today on a function which does a rom firmware file check. I mean...for an existing file...if someone want's to check the integrity. I've implemented a reverse scan at the end of the firmware file..searching for the ROYL mark..then for FLASH_MODULE_DIRECTORY..and from there...scan all internal mods for crc. for the ROYL frm it's possible, but for the old model firmware...I don't see an easy way. However, I need this function, if I plan to develop firmware write. some checks must be made on the firmware we want to flash.

Hello louis, i noticed that you have WDR3.0 inside HBCD? you customized your HBCD i guess?
Also about your tool, just for information, do you plan to release it or not?

^^ at this moment I don't know if the CRC update isn't handled by the firmware if you we use the standard module update VSC function. the second way it's to write the SA directly by pcs_write function at the start point of the module on the platter.

what I mean is that if I have a mod file on my hdd...and change something to it, I can then, write it to the SA in 2 ways: 1.a special vsc command...or 2. a simple data write using also a vsc command. as you can see at a previous post of mine, changing PUIS byte in flash, is handled by the firmware which does the modifications and fix the crc of the flash module. they have a special command for changing some flags, but I could have done it by downloading the mod..changing it by myself and uploading it again.

by the way, do you now if wd roms larger than 192kb exist?

I believe that there's now way to know what's the bios size. that vsc command simply reads the flash image mapped on dram memory. I could do some tests, starting downloading first 128..then 192...then 256, and perform a checkrom() for the downloaded rom file to see if it's complete, but this will take some time. It's a little bit confusing for a user to select what's the rom size. that's why I search a way to simply avoid that drop/list. it would be nice.

louis, the rom size is (mod109 size -1) *512 bytes.

qintl, on a lower perspective, perhaps. but what we do with the non-royl firmware, the 128k ones? there isn't any mod 109. we treat this situation as 128k? I mean..what returns false when asking mod109...it's a 128k rom? What if we can't access the SA? you know that he rom can be dumped even without access to SA

btw, I found a rom which seems to be old enough not to have any trace of mod's at the end of it. more, it doesn't fit to my description form here. the sizes seems to be on 3 bytes instead 4.