OSDev.org

Hi, I have a few questions about the fields in the ATA IDENTIFY command:

1. Should I care if bit 13 is set? If I'm reading data in logical sectors anyways why would that matter?
2. If I see that bit 12 is set I must look at words 117-118 (Logical sector size (DWord)) correct?
3. Can I just ignore bit 13 and 0:3, since as far as I understand those are just optimal performance hints for the driver?
4. If this field is not implemented can I assume 512 bytes per sector?

Thanks

Just a quick note, if you are using QEMU and reading these bits, be aware that QEMU may incorrectly set bit 13.

I have given a bug report.

As for the other comments/questions, I believe you are correct, though would have to look through my notes.

Ben

BenLunt wrote:Just a quick note, if you are using QEMU and reading these bits, be aware that QEMU may incorrectly set bit 13.

I have given a bug report.

As for the other comments/questions, I believe you are correct, though would have to look through my notes.

Ben

Thanks. Actually, the bit 13 being set doesn't really affect the final result, even if 0:3 is set to 0.
In my code I just do logical_sectors_per_physical = (1 << bit_0_to_3),
which is basically a no-op in this case. The spec even mentions this specific case,
and says that it's 2^0, so 1 logical sector per physical.



Although I do agree that it's a bit weird that they set it at all.

8infy wrote:1. Should I care if bit 13 is set? If I'm reading data in logical sectors anyways why would that matter?

How much do you care about performance? Misaligned writes are significantly slower than aligned writes.

8infy wrote:2. If I see that bit 12 is set I must look at words 117-118 (Logical sector size (DWord)) correct?

Yes.

8infy wrote:3. Can I just ignore bit 13 and 0:3, since as far as I understand those are just optimal performance hints for the driver?

Yes.

8infy wrote:4. If this field is not implemented can I assume 512 bytes per sector?

Yes.