Barracuda XT, Barracuda, Barracuda Green, DiamondMax and other desktop SATA and IDE drives

[fzabkar]

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.

[Grim0x]

AH, I see.

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)

[fzabkar]

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.