Support for SATA controllers in IDE mode

[SamuelYvon]

Introduction

Up until now, Mimosa only supported PATA drives (parallel ATA). This was mostly due to the fact that the driver would only use controllers located at the standardized addresses.

IDE controllers are available on the PCI bus: they can be detected and their configuration can be read from there. This allows us to support IDE controllers that are not located at the standard ports, but also support SATA controllers performing in IDE mode because they are not (in my experience) located at the standard addresses. Of course, the standards addresses are also supported.

SATA controllers worked in IDE compatibility mode before the introduction of AHCI, which we do not support. Most BIOSes will present the option of having the controllers operate in IDE mode, as it is a standard feature of these devices.

The C kernel will be able to detect and use these controllers to correctly load the Gambit image in memory. The Scheme kernel will also be able to interface those drives.

Quick list of changes (maybe incomplete?):

• Added PCI configuration I/O support (Scheme / C)
• Added support for the bus master ports (Scheme / C). This is necessary for SATA drive as controllers share interrupt lines.
• Added support for dynamic affectation of interrupt service routines (C)
• Added support for ide controllers using different port affectation (Scheme / C)
• Added [S]ATAPI packet send support (C), only for non-data packet as described by the ATAPI spec.
• Enhanced detection of drive, as well as their types (Scheme / C). All connected drives should now be detected properly.

Remaining work to be done:

• Right now, as described in issue IDE: Scheme Driver relies on C driver to have setup the interrupt table correctly #89, the Scheme kernel cannot control the interrupt service routine affectations. This is not a problem for the moment, since the C kernel will do the correct affectation for the Gambit executable to be loaded. This guarantees that the state the Scheme kernel will be in is coherent. However, this is incorrect for future drivers that will not have a counterpart in both parts of the kernel. I think this can wait until the need presents itself.
• The outl/inl bindings in Scheme are not correctly implemented (see low-level.scm). The outl instruction is acceptable, since it uses three parameters (high word of value, low word of value and port) and a single call. It would however be simpler to have a function in the ffi to support the 32 bits integers (tagging leaves 30 bits available). The inl instruction is implemented naively, by doing two (x86-inl) in different calls, to extract the high and low word. This is bad, since (x86-inl) is not very fast. This works to provide support for these functions, but this is something that needs to be fixed before merging. I ping @feeley for this feature, since I tried to get it working in the ffi, but I am unsure how to embed assembly in c-lambdas.