4

I've been trying to test my AHCI driver for my hobby OS on bare metal. Before that, I tested my driver in QEMU with the parameters:

qemu-system-i386 -boot d -cdrom elfboot.iso -machine q35 -m 2G -hda hda.img -serial stdio

The output is something like that:

...
PCI: 00:1F.2 [0106] (01): 8086:2922 Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci2: sectors = 204, block size = 2048
DEV: Added block device ahci2
...

The PCI device is the AHCI controller which is used when starting QEMU with the above parameters. Now, I felt confident enough that the same setup would work on real hardware too, so I gave it a try. This is what was printed on the screen:

...
PCI: 00:17.0 [0106] (01): 8086:A102 Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci1: sectors = 4068212736, block size = 0
DEV: Added block device ahci1
...

I also tested it on another machine, which doesn't have an AHCI controller, but a RAID controller which is running in AHCI mode. On that machine, the output is basically the same as on the other bare metal setup:

...
PCI: 00:17.0 [0104] (00): 8086:282A Mass Storage Controller
...
AHCI: Initialize module...
...
AHCI: Found AHCI device with signature EB140101
AHCI: ahci1: sectors = 4068212736, block size = 0
DEV: Added block device ahci1
...

According to the SCSI specification, the value of 4068212736 (0xF27C0000) does not have a set meaning. Also, the block size is set to zero, which does not match with what I see on QEMU. Only the output shown in the QEMU console is correct. On both of my real machines the reported capacity is wrong, with the same values.

What am I supposed to do next? Is this a vendor-related issue? It seems that the read capacity (10) command is mandatory for all SCSI devices of that type, so in my inexperienced opinion, I don't think that is the problem here.

EDIT: I put an SCSI request sense after the read capacity (10) command since it was stated that request sense should be put after every SCSI command for stalling the device.

Now, the reported number of blocks is 65263, which is still wrong, but also different from 4068212736, so I'm not sure If I move in the correct direction now. Also, the block size is now correctly reported as 2048 bytes.

CRoemheld
  • 889
  • 7
  • 26

1 Answers1

0

The READ CAPACITY (10) response is two big-endian (network byte order) unsigned 32-bit integers for the last LBA and the block size. The problems you're having look like they're related to byte ordering. I think it's likely that the highest LBA is really 0x00007CF2. The blocksize is showing as 0 because it's in the byte at the other end of the integer, and was truncated.

Mike Andrews
  • 3,045
  • 18
  • 28
  • Unfortunately, that is not the issue here. I know that the result is sent back in big endian, but I used a small function which reverses the byte order in such cases. Also, `0x7CF2` is not the correct LBA for the last block. The correct LBA for the last block is `204`, which is `0xCC`. And that byte does not appear in the reported last block field anywhere. – CRoemheld May 20 '20 at 15:50