OSDev.org

rdos wrote:costed $25

I'm also a big fan of mass storage
controllers ... I'm also trying to implement also an AHCI ctrl for my project ... (http://filesystemd.sourceforge.net) which will be the file_system_level of my future multi-tasking OS ...
Currently ... i've only implemented drives for PATA IDE HD/ATAPI DVD and USB FLASH/DVD ...

PDF docs seem to be free over the net (?) at least for what I've found ... on official sites (?) .

---
It seems you have a little experience with this; do you know how to
distinguish the port for LEGACY SUPPORT (SATA LEGACY SUPPORT - it should be compatible with previous PATA IDE spec, but at different location (aka not 0x1f0, 0x170....))

Well I am looking at the PCI Port stuff(0xcf0) for PCI.ADDRESS_PORT and I can see 5 base ports; unfurtunatly I could not find any doc to tell me which ones
are mapping to 0x1f0 and which ones are mapping to 0x3f0 ... ?
(And probably this LEGACY SUPPORT includes also PATA IDE 48bit addressing too, yes ?(?))

---
Good luck with your driver !

MihailB wrote:It seems you have a little experience with this; do you know how to
distinguish the port for LEGACY SUPPORT (SATA LEGACY SUPPORT - it should be compatible with previous PATA IDE spec, but at different location (aka not 0x1f0, 0x170....))

You find them by searching for PCI classes. Unfortunately, there are at least to class-codes for PCI IDE. First there is class = 1 and subclass = 1 for older IDE-devices, and then there is class = 8F, subclass = 1 for AHCI IDE interfaces (at least according to AMDs SB800 document). You find the IO-bases in PCI BARs.

MihailB wrote:Well I am looking at the PCI Port stuff(0xcf0) for PCI.ADDRESS_PORT and I can see 5 base ports; unfurtunatly I could not find any doc to tell me which ones
are mapping to 0x1f0 and which ones are mapping to 0x3f0 ... ?
(And probably this LEGACY SUPPORT includes also PATA IDE 48bit addressing too, yes ?(?))

I don't think PATA supports 48 bit addressing. That is the feature that would finally make IDE obsolete.

I have some trouble with the AMD SATA-driver implemented in the SB800 chip on my new notebook. Currently, I cannot get it to work in AHCI-mode (it just clears the "command list running" bit as soon as I issue a command, without setting any error-bits), and it doesn't work with my PCI IDE-driver either (probably because it uses class = 8F).

My laptop has an SB800, the SATA controller works just fine with OpenBSD's AHCI driver.
Also, PATA supports 48-bit LBA, it was introduced in ATA-6/ATA100.. there are even ATA-7/ATA133 PATA controllers.

ATA-7s PATA interface wasn't widely adopted, but drives and controllers are out there.. it added support for UltraDMA 6 mode, and SATA 1.0

Here's how OpenBSD detects an ATA100 drive connected to a ATA133 controller in another system, sadly I don't have a ATA133 capable drive for it anymore:

This is an interesting thread. So if I search through the PCI devices, find a SATA Controller (Class 0x01, Subclass 0x06), extract the BARs, then I can get the IO address for legacy port IO?

Under VirtualBox I have a machine configured with only one SATA controller. The BAR info is here:
0x0000D041
0x0000D049
0x0000D051
0x0000D059
0x0000D061
0xF0804000

Hmm.. I was hoping for one IO space.. not 5. So one of those could be used as the base for port IO like ports 0x01F0 and 0x0170?

Thanks,
Ian

ReturnInfinity wrote:This is an interesting thread. So if I search through the PCI devices, find a SATA Controller (Class 0x01, Subclass 0x06), extract the BARs, then I can get the IO address for legacy port IO?

Under VirtualBox I have a machine configured with only one SATA controller. The BAR info is here:
0x0000D041
0x0000D049
0x0000D051
0x0000D059
0x0000D061
0xF0804000

Hmm.. I was hoping for one IO space.. not 5. So one of those could be used as the base for port IO like ports 0x01F0 and 0x0170?

Thanks,
Ian

yap this is my problem too !
I've tried different combinations ...
I was able to find a port to behave like old 0x1f0 was behaving but it does not repond to read/write commands ...
And there's another thing ... which one is 0x3f0(altrenate status register - which very importatn for it's nIEN) ? ...
The problem is that for eg INTEL's AHCI doc does not talk about which BAR is which port(it talks about legacy stuff but without this ... things are useless, 'cause you can not init IDE ...)

ReturnInfinity wrote:This is an interesting thread. So if I search through the PCI devices, find a SATA Controller (Class 0x01, Subclass 0x06), extract the BARs, then I can get the IO address for legacy port IO?

Under VirtualBox I have a machine configured with only one SATA controller. The BAR info is here:
0x0000D041
0x0000D049
0x0000D051
0x0000D059
0x0000D061
0xF0804000

Hmm.. I was hoping for one IO space.. not 5. So one of those could be used as the base for port IO like ports 0x01F0 and 0x0170?

Thanks,
Ian

This is explained in the PCI IDE Controller Specification, if the device is in compatibility mode.. the legacy port mapped addresses are the same, for controllers in native mode, the address for the primary channel's command registers is at 0x10 (BAR0), control registers are at 0x14 (BAR1).

Just google for the "PCI IDE Controller Specification" or for pciide.ps/pciide.pdf, obtaining the datasheet for the actual controller is also helpful.

Obviously none of this is relevant if the device is a proprietary SATA RAID controller or currently in AHCI mode, you'll need to write either an AHCI driver or write a very large quirks file that forces the controller into PCI IDE mode. How this is done is device specific.

Brynet-Inc wrote:My laptop has an SB800, the SATA controller works just fine with OpenBSD's AHCI driver.

OK, so now I think I know why my driver doesn't work. The AMD controller have a particular way to switch from IDE to AHCI-mode. My AMD controller is set to IDE-mode per default. Just changing the AE bit will only work on Intel controllers it seems.

rdos wrote:

Brynet-Inc wrote:My laptop has an SB800, the SATA controller works just fine with OpenBSD's AHCI driver.

OK, so now I think I know why my driver doesn't work. The AMD controller have a particular way to switch from IDE to AHCI-mode. My AMD controller is set to IDE-mode per default. Just changing the AE bit will only work on Intel controllers it seems.

Unfortunately, this is not the problem. It is already configured like they do with class = 1, subclass = 6, and it has the correct interface (=1).

I also had a wrong field coding in the command-list entry (one PRD too much), but fixing this doesn't change anything either.

I also removed the extra-fields I use, and let them stay "0", but that doesn't help either.

The only thing that does seem to work is that the initial FIS is received, but after that nothing seems to happen. No int bits are set, nothing.

MihailB wrote:yap this is my problem too !
I've tried different combinations ...
I was able to find a port to behave like old 0x1f0 was behaving but it does not repond to read/write commands ...
And there's another thing ... which one is 0x3f0(altrenate status register - which very importatn for it's nIEN) ? ...
The problem is that for eg INTEL's AHCI doc does not talk about which BAR is which port(it talks about legacy stuff but without this ... things are useless, 'cause you can not init IDE ...)

Similar issue here. The port responds but no data comes out of it. I tested it in VirtualBox and got no errors but also nothing was read from the disk. I'm sure the controller is in Native Mode but I would still expect Legacy Mode to work as well.. especially since the device is advertising the ports.

I guess you would need to tell the controller to force legacy operation..

-Ian

I've had more progess on the Sony Vaio, that now can read multiple sectors at full-speed. I discovered that I incorrectly set the C flag in the command list, which seems to abort the operation early (I'm not sure why this bit exists at all, but it should be reset). The docs didn't inform about what it was good for. It would be interesting to see if this bit also creates the odd error with the AMD SATA controller, which I've got nowhere with. I'll check that tomorrow.

After fixing the IRQ vector (still not implemented this from ACPI), my portable Compaq Pressario CQ57 with the AMD SATA-controller now works. I can do directory listings on the FAT32 partition, but there still is some issue when command slots are exhausted it seems like, because it suddenly stops working, and AHCI indicates the last command-slot is active. There is probably no test for no avaiable slots, but after I fix that it might work fully.

Now it works pretty well on both my machines with SATA-controllers (Intel and AMD). It also works both with PCI IRQs and MSIs, and with one IRQ per device and one IRQ per port. It also handles both reads and writes.

Still, when I stress the AMD SATA a lot, it still fails. I probably need another day to find that problem. The kernel debugger come in handy when it is "locked-up".

Edit: Seems like the Intel controller (Sony Vaio) does not stop working when stressed. I copied 800 files between directories (16MB), and it worked. The filesystem also was ok after the copy.

The AMD SATA works now. The problem was that the interrupt was sometimes generated before the descriptors were ready. I added a timer to the "notify"-thread, but I think I will change this again. The best algoritm probably is to poll the outstanding queues with a 1ms interval once the notification interrupt has been received, but data has not been transfered completely. That would give lower overhead than a timer that would be running all the time. With the Intel SATA, this will never happen, while it would happen occasionally with the AMD controller.

I've concluded that the reason is not early interrupts, but rather missing interrupts. When I added logic for looping after finding non-complete entries, it didn't solve the issue (still hangs with ready-packets that are never processed). OTOH, if I start a 15ms timeout every time I issue a command, and let the timeout notify completion (instead of the IRQ), it works. I'm not sure why I have this problem with the AMD SATA and not with the Intel SATA. There is a difference in interrupt dispatching: The Intel SATA uses one MSI per port, while the AMD SATA uses a single PCI IRQ (from IO-APIC).

What should the trigger mode be for IO-APIC IRQs from PCI? Maybe I should use level-triggered interrupts instead of edge-trigged?

rdos wrote:What should the trigger mode be for IO-APIC IRQs from PCI? Maybe I should use level-triggered interrupts instead of edge-trigged?

The MP or ACPI tables should tell you that.