ATA Identify "WORDS PER LOGICAL SECTOR"

[kurtmweber]

On the current versions of both bochs and qemu, the value at words 117-118 is 0.

Checking the MAJOR VERSION Identify Field, it appears that the emulated hard disk in bochs supports up to ATA version 6, and in qemu version 7. The WORDS PER LOGICAL SECTOR field does not exist in version 6, and in version 7 it's flagged as optional; it only becomes mandatory in 8. For a version 6 controller (e.g. bochs), obviously the value there is meaningless.

For version 7, it becomes complicated because it's an optional feature, so the value there may or may not be meaningful depending on whether the device in question supports that feature.

The spec specifies that valid values are greater than or equal to 256 (measured in 16-bit words, so 512 bytes). So if I find a value less than 256 there, is it correct to conclude that the device does not support anything beyond legacy 512-byte sectors? Conversely, if the value is greater than or equal to 256, can I correctly conclude that the device does support large sectors, or is it possible that in a non-supporting device the value there may just randomly be >= 256?

[Octocontrabass]

it only becomes mandatory in 8.

Where are you seeing this? It's listed as optional in all of the ATA8-ACS1, 2, 3, and 4 drafts that I found.

The spec specifies that valid values are greater than or equal to 256 (measured in 16-bit words, so 512 bytes). So if I find a value less than 256 there, is it correct to conclude that the device does not support anything beyond legacy 512-byte sectors? Conversely, if the value is greater than or equal to 256, can I correctly conclude that the device does support large sectors, or is it possible that in a non-supporting device the value there may just randomly be >= 256?

It's not possible to conclude anything just from reading words 117-118. You must also check word 106 bits 15, 14, and 12. If those bits do not indicate support for long logical sectors, you must ignore any value in words 117-118 and assume 256-word (512-byte) sectors.

I'd also throw in a check for reasonable ATA major/minor versions.

[BenLunt]

As an alternative, though this assumes there is a disk/disc present, to figure out how many words per sector there are, I simply read a sector of data.

For example, for an ATA device, knowing that the DRQ bit will be set when data is available for reading, after reading the first 256 words, I check the DRQ bit and if set, continue to read 256 words until the DRQ bit is clear.

1) WORDS_COUNT = 0
2) send read (one) sector command
3) read 256 words
4) WORD_COUNT = WORD_COUNT plus 256
5) if DRQ is still set, go to 3
6) done. WORD_COUNT equals count of words per sector

If the device is an ATAPI device, set the MID and HIGH bytes to 4096 before the read, then read the sector. After the read, the MID and HIGH bytes return how many bytes were read.
The ATAPI technique is simple, however, don't forget to actually read the sector data or at least reset the device.

This only relies on the fact that the device is ready and has media inserted. However, if the media is not inserted, the words per sector doesn't matter anyway.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[Octocontrabass]

For example, for an ATA device, knowing that the DRQ bit will be set when data is available for reading, after reading the first 256 words, I check the DRQ bit and if set, continue to read 256 words until the DRQ bit is clear.

This won't work for drives with unusual sector sizes, like the 520- or 528-byte sectors that are "typical" according to the ATA spec.

[BenLunt]

For example, for an ATA device, knowing that the DRQ bit will be set when data is available for reading, after reading the first 256 words, I check the DRQ bit and if set, continue to read 256 words until the DRQ bit is clear.

This won't work for drives with unusual sector sizes, like the 520- or 528-byte sectors that are "typical" according to the ATA spec.

You are correct, however, if this is the case, how do you know if the drive is a 520- or 528-byte drive? Does the specification explain how to determine the drive is one of these sector sizes? If not, when/how would you know to read the extra (4 or 8) words?

Either way, a slight modification to my code, checking the DRQ bit after every WORD read will fix this and work every time, even on these presumably odd sector-sized disks.

In my opinion, all drives I will ever encounter will be a 512-, 2048-, or 4096-byte drive. Since each of these values are evenly divisible by 512, my technique will always work on the drives I will encounter.

Have you ever encountered a drive that has 520- or 528-byte sectors? Or any other value than the three I mentioned above. I am curious. Has anybody?
Ben

[Octocontrabass]

You are correct, however, if this is the case, how do you know if the drive is a 520- or 528-byte drive? Does the specification explain how to determine the drive is one of these sector sizes? If not, when/how would you know to read the extra (4 or 8) words?

When IDENTIFY DEVICE word 106 bits 15, 14, and 12 indicate long logical sectors, words 117 and 118 indicate the logical sector size.

Have you ever encountered a drive that has 520- or 528-byte sectors? Or any other value than the three I mentioned above.

I personally haven't seen any ATA drives with odd sector sizes like that. It's much more common in enterprise SCSI (SAS) drives, where I have seen it.

Has anybody?

Google suggests they do exist, but I can't find any manufacturers offering them for sale to the general public.

[BenLunt]

When IDENTIFY DEVICE word 106 bits 15, 14, and 12 indicate long logical sectors, words 117 and 118 indicate the logical sector size.

After looking, I had once made a note about this but did not implement or do anything about it, so thanks for the reminder. I will read a bit more about it and implement this within my code.

Thanks,
Ben

[BenLunt]

After looking over my notes, I found out why I didn't implement this yet. In my opinion, QEMU doesn't emulate this function correctly. I have posted a bug report.

I take it as (after verifying bits 15:14) if bit 13 is set then there are multiple logical sectors per physical sector. i.e.: Physical sector size is greater than logical sector size.
If bit 13 is set, bits 3:0 must be non-zero.

Currently, when physical sectors size == logical sectors size == 512-byte sectors, QEMU still sets bit 13. In my opinion this is wrong. Therefore, I didn't pursue this implementation.

Oracle's VirtualBox returns 0x0000 in WORD 106, so not implemented at all.

I haven't tried any other emulator or real hardware yet.

Ben
- http://www.fysnet.net/osdesign_book_series.htm

[Octocontrabass]

I take it as (after verifying bits 15:14) if bit 13 is set then there are multiple logical sectors per physical sector. i.e.: Physical sector size is greater than logical sector size.
If bit 13 is set, bits 3:0 must be non-zero.

Currently, when physical sectors size == logical sectors size == 512-byte sectors, QEMU still sets bit 13. In my opinion this is wrong. Therefore, I didn't pursue this implementation.

QEMU is wrong here, but you can just ignore it when the reported physical sector size is invalid, since that information is only a performance hint. Actual drives won't set bit 13 when the logical and physical sector sizes are the same (according to specification documents from various drive manufacturers).

I don't see how this has anything to do with logical sector size though. (QEMU only supports 512-byte logical sectors, it'll never set bit 12.)