I used to think all the firmware was stored in EEPROM. However, it appears that the Identify Device data block is actually stored on the platters, as is the majority of the firmware. This explains why drives that are unable to read the platters will sometimes identify themselves with a strange model number stored in the EEPROM.
I knew something having to do with the firmware is stored (on the first bits sometimes) of the platters (read it somewhere - probably HERE!), wasnt sure what though.
But what I dont get is the LBA/CHS part being irrelevant...
I dont think that the device's drivers/system drivers could ever make such a conclusion, regardless of the circumstances!
explain what you're thinking again (just trying to get into that labyrinth head of urs : p)
A Pentium III, 256MB RAM and 10GB HDD are needed to run Windows XP. The power of 3 C64 was needed to fly to SPACE. Something is wrong with our world... And its called WINDOWS! ____________________________ SAVE THE INTERNET - FIGHT Net NEUTRALITY
I'm trying to understand why the drive can correctly report 512 bytes of identity data, but fails when trying to read 512 bytes of user data from any sector.
The ATA Identify Device command doesn't specify a sector address because the data are not retrieved from any sector in the user area. This means that LBA or CHS addressing is irrelevant for this command. However, a read or write command does need to specify the target sector, and it can do so using either LBA or CHS addressing. I'm wondering if the bridge chip is getting confused and trying to access the drive in LBA mode when it only supports CHS addressing??? Is this even plausible???
Maybe the bridge chip knows to retrieve the identity data in PIO mode but then incorrectly switches to DMA mode??? Again, I have no idea whether this is plausible, either.