AHCI Post complete.
This commit is contained in:
parent
1387b297ac
commit
de351f1301
|
|
@ -83,4 +83,6 @@ figcaption {
|
||||||
font-style: italic;
|
font-style: italic;
|
||||||
}
|
}
|
||||||
|
|
||||||
|
.chroma {
|
||||||
|
padding: 10px;
|
||||||
|
}
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,86 @@
|
||||||
|
/* Background */ .bg { color: #d0d0d0; background-color: #202020; }
|
||||||
|
/* PreWrapper */ .chroma { color: #d0d0d0; background-color: #202020; }
|
||||||
|
/* Other */ .chroma .x { }
|
||||||
|
/* Error */ .chroma .err { color: #a61717; background-color: #e3d2d2 }
|
||||||
|
/* CodeLine */ .chroma .cl { }
|
||||||
|
/* LineLink */ .chroma .lnlinks { outline: none; text-decoration: none; color: inherit }
|
||||||
|
/* LineTableTD */ .chroma .lntd { vertical-align: top; padding: 0; margin: 0; border: 0; }
|
||||||
|
/* LineTable */ .chroma .lntable { border-spacing: 0; padding: 0; margin: 0; border: 0; }
|
||||||
|
/* LineHighlight */ .chroma .hl { background-color: #363636 }
|
||||||
|
/* LineNumbersTable */ .chroma .lnt { white-space: pre; -webkit-user-select: none; user-select: none; margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #686868 }
|
||||||
|
/* LineNumbers */ .chroma .ln { white-space: pre; -webkit-user-select: none; user-select: none; margin-right: 0.4em; padding: 0 0.4em 0 0.4em;color: #686868 }
|
||||||
|
/* Line */ .chroma .line { display: flex; }
|
||||||
|
/* Keyword */ .chroma .k { color: #6ab825; font-weight: bold }
|
||||||
|
/* KeywordConstant */ .chroma .kc { color: #6ab825; font-weight: bold }
|
||||||
|
/* KeywordDeclaration */ .chroma .kd { color: #6ab825; font-weight: bold }
|
||||||
|
/* KeywordNamespace */ .chroma .kn { color: #6ab825; font-weight: bold }
|
||||||
|
/* KeywordPseudo */ .chroma .kp { color: #6ab825 }
|
||||||
|
/* KeywordReserved */ .chroma .kr { color: #6ab825; font-weight: bold }
|
||||||
|
/* KeywordType */ .chroma .kt { color: #6ab825; font-weight: bold }
|
||||||
|
/* Name */ .chroma .n { }
|
||||||
|
/* NameAttribute */ .chroma .na { color: #bbbbbb }
|
||||||
|
/* NameBuiltin */ .chroma .nb { color: #24909d }
|
||||||
|
/* NameBuiltinPseudo */ .chroma .bp { }
|
||||||
|
/* NameClass */ .chroma .nc { color: #447fcf; text-decoration: underline }
|
||||||
|
/* NameConstant */ .chroma .no { color: #40ffff }
|
||||||
|
/* NameDecorator */ .chroma .nd { color: #ffa500 }
|
||||||
|
/* NameEntity */ .chroma .ni { }
|
||||||
|
/* NameException */ .chroma .ne { color: #bbbbbb }
|
||||||
|
/* NameFunction */ .chroma .nf { color: #447fcf }
|
||||||
|
/* NameFunctionMagic */ .chroma .fm { }
|
||||||
|
/* NameLabel */ .chroma .nl { }
|
||||||
|
/* NameNamespace */ .chroma .nn { color: #447fcf; text-decoration: underline }
|
||||||
|
/* NameOther */ .chroma .nx { }
|
||||||
|
/* NameProperty */ .chroma .py { }
|
||||||
|
/* NameTag */ .chroma .nt { color: #6ab825; font-weight: bold }
|
||||||
|
/* NameVariable */ .chroma .nv { color: #40ffff }
|
||||||
|
/* NameVariableClass */ .chroma .vc { }
|
||||||
|
/* NameVariableGlobal */ .chroma .vg { }
|
||||||
|
/* NameVariableInstance */ .chroma .vi { }
|
||||||
|
/* NameVariableMagic */ .chroma .vm { }
|
||||||
|
/* Literal */ .chroma .l { }
|
||||||
|
/* LiteralDate */ .chroma .ld { }
|
||||||
|
/* LiteralString */ .chroma .s { color: #ed9d13 }
|
||||||
|
/* LiteralStringAffix */ .chroma .sa { color: #ed9d13 }
|
||||||
|
/* LiteralStringBacktick */ .chroma .sb { color: #ed9d13 }
|
||||||
|
/* LiteralStringChar */ .chroma .sc { color: #ed9d13 }
|
||||||
|
/* LiteralStringDelimiter */ .chroma .dl { color: #ed9d13 }
|
||||||
|
/* LiteralStringDoc */ .chroma .sd { color: #ed9d13 }
|
||||||
|
/* LiteralStringDouble */ .chroma .s2 { color: #ed9d13 }
|
||||||
|
/* LiteralStringEscape */ .chroma .se { color: #ed9d13 }
|
||||||
|
/* LiteralStringHeredoc */ .chroma .sh { color: #ed9d13 }
|
||||||
|
/* LiteralStringInterpol */ .chroma .si { color: #ed9d13 }
|
||||||
|
/* LiteralStringOther */ .chroma .sx { color: #ffa500 }
|
||||||
|
/* LiteralStringRegex */ .chroma .sr { color: #ed9d13 }
|
||||||
|
/* LiteralStringSingle */ .chroma .s1 { color: #ed9d13 }
|
||||||
|
/* LiteralStringSymbol */ .chroma .ss { color: #ed9d13 }
|
||||||
|
/* LiteralNumber */ .chroma .m { color: #3677a9 }
|
||||||
|
/* LiteralNumberBin */ .chroma .mb { color: #3677a9 }
|
||||||
|
/* LiteralNumberFloat */ .chroma .mf { color: #3677a9 }
|
||||||
|
/* LiteralNumberHex */ .chroma .mh { color: #3677a9 }
|
||||||
|
/* LiteralNumberInteger */ .chroma .mi { color: #3677a9 }
|
||||||
|
/* LiteralNumberIntegerLong */ .chroma .il { color: #3677a9 }
|
||||||
|
/* LiteralNumberOct */ .chroma .mo { color: #3677a9 }
|
||||||
|
/* Operator */ .chroma .o { }
|
||||||
|
/* OperatorWord */ .chroma .ow { color: #6ab825; font-weight: bold }
|
||||||
|
/* Punctuation */ .chroma .p { }
|
||||||
|
/* Comment */ .chroma .c { color: #999999; font-style: italic }
|
||||||
|
/* CommentHashbang */ .chroma .ch { color: #999999; font-style: italic }
|
||||||
|
/* CommentMultiline */ .chroma .cm { color: #999999; font-style: italic }
|
||||||
|
/* CommentSingle */ .chroma .c1 { color: #999999; font-style: italic }
|
||||||
|
/* CommentSpecial */ .chroma .cs { color: #e50808; background-color: #520000; font-weight: bold }
|
||||||
|
/* CommentPreproc */ .chroma .cp { color: #cd2828; font-weight: bold }
|
||||||
|
/* CommentPreprocFile */ .chroma .cpf { color: #cd2828; font-weight: bold }
|
||||||
|
/* Generic */ .chroma .g { }
|
||||||
|
/* GenericDeleted */ .chroma .gd { color: #d22323 }
|
||||||
|
/* GenericEmph */ .chroma .ge { font-style: italic }
|
||||||
|
/* GenericError */ .chroma .gr { color: #d22323 }
|
||||||
|
/* GenericHeading */ .chroma .gh { color: #ffffff; font-weight: bold }
|
||||||
|
/* GenericInserted */ .chroma .gi { color: #589819 }
|
||||||
|
/* GenericOutput */ .chroma .go { color: #cccccc }
|
||||||
|
/* GenericPrompt */ .chroma .gp { color: #aaaaaa }
|
||||||
|
/* GenericStrong */ .chroma .gs { font-weight: bold }
|
||||||
|
/* GenericSubheading */ .chroma .gu { color: #ffffff; text-decoration: underline }
|
||||||
|
/* GenericTraceback */ .chroma .gt { color: #d22323 }
|
||||||
|
/* GenericUnderline */ .chroma .gl { text-decoration: underline }
|
||||||
|
/* TextWhitespace */ .chroma .w { color: #666666 }
|
||||||
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 127 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 93 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 106 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 56 KiB |
|
|
@ -0,0 +1,617 @@
|
||||||
|
---
|
||||||
|
title: "Writing an AHCI Driver"
|
||||||
|
date: 2024-01-08
|
||||||
|
draft: true
|
||||||
|
tags: ['osdev']
|
||||||
|
---
|
||||||
|
|
||||||
|
Now that I've wrapped up the [0.1.0 Release](/blog/2023/12/acadia-0.1.0) of
|
||||||
|
AcadiaOS I'm looking to cleanup some of the "just get it working" hacks that
|
||||||
|
exist in the codebase. First up on that list is the AHCI Driver.
|
||||||
|
|
||||||
|
## What is AHCI
|
||||||
|
|
||||||
|
AHCI stands for Advanced Host Controller Interface and if you like acronyms boy
|
||||||
|
are you in for a treat. AHCI is a way to interface with SATA (which replaced
|
||||||
|
PATA (a.k.a. IDE)) via its HBA. AHCI has since been superseded by NVMe but is
|
||||||
|
simpler to implement (or so I've been told) so I've started here.
|
||||||
|
|
||||||
|
To try to explain it without acronym soup, AHCI allows you to access disk
|
||||||
|
drives and optical drives (SATA devices) by writing relevant ATA commands to
|
||||||
|
memory addresses that are backed by hardware firmware. There are a wide variety
|
||||||
|
of commands available but best I can tell the main ones used these days are to
|
||||||
|
identify the device and read/write via direct memory access (DMA).
|
||||||
|
|
||||||
|
Essentially you give the device an offset to read from as well as physical
|
||||||
|
memory address to write to. The device firmware copies the amount of data you
|
||||||
|
requested to the physical address then triggers an interrupt to indicate that
|
||||||
|
the operation is complete. Likewise writing via DMA is the same but in reverse.
|
||||||
|
|
||||||
|
Disclaimer, all of the above is basically just summarizing Wikipedia and the
|
||||||
|
OSDev wiki and I don't really know what I'm talking about.
|
||||||
|
|
||||||
|
## Current State
|
||||||
|
|
||||||
|
The current AHCI implementation in Denali is straightforward but very brittle.
|
||||||
|
It relies on everything following the happy path and is cobbled together more
|
||||||
|
based on trial an error of what worked rather than following the specification
|
||||||
|
closely.
|
||||||
|
|
||||||
|
As a part of this article we're going to dive into the related specs and look at
|
||||||
|
how they relate to each other. The trickiest part of writing the driver is the
|
||||||
|
fact that the necessary information is spread across several different specs
|
||||||
|
rather than contained in one place. The specs I reference in this post are:
|
||||||
|
|
||||||
|
- [AHCI 1.3.1](https://www.intel.com/content/www/us/en/io/serial-ata/serial-ata-ahci-spec-rev1-3-1.html)
|
||||||
|
- SATA 3.2
|
||||||
|
- ATA/ATAPI Command Set 3 (ACS-3)
|
||||||
|
|
||||||
|
The SATA and ACS specs cost money so I can't link them directly but it isn't
|
||||||
|
hard to find drafts of them available online.
|
||||||
|
|
||||||
|
## How AHCI Works
|
||||||
|
|
||||||
|
AHCI allows you to control SATA devices by writing commands to memory. The
|
||||||
|
layout of these structures is nicely shown in the AHCI Spec Figure 4:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
There are several pieces here that I've annotated:
|
||||||
|
|
||||||
|
1. The Generic Host Control (GHC) is a set of registers that allow you to manage the
|
||||||
|
whole controller and get its status. These registers are referred to in the
|
||||||
|
spec using GHC.RegisterName so the interrupt status register for instance is
|
||||||
|
"GHC.IS" for short.
|
||||||
|
2. Each device (hard disk or disc drive) that is attached to the controller is
|
||||||
|
exposed as a "port" with a set of registers to control it individually.
|
||||||
|
These registers are referred to as PxRegisterName so for instance the command
|
||||||
|
issue register is PxCI.
|
||||||
|
3. For each port it has a separately allocated piece of memory that can accept
|
||||||
|
up to 32 "commands" to execute.
|
||||||
|
4. When the controller is finished executing a command for a device it will
|
||||||
|
write a Frame Information Structure (FIS) and raise an interrupt. (The GHC
|
||||||
|
has a register to show which devices have a pending interrupt GHC.IS).
|
||||||
|
|
||||||
|
Each device can support up to 32 pending commands (but only receive one FIS at a
|
||||||
|
time). The memory structure is as follows:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
To issue a command we can:
|
||||||
|
|
||||||
|
1. Select a command slot that isn't currently in use.
|
||||||
|
2. Write the command to that command table (the specifics of this are explained
|
||||||
|
later) and then set that command as active in the commands issued register
|
||||||
|
for that port (PxCI).
|
||||||
|
3. Wait an interrupt indicating that this command has finished and read the
|
||||||
|
resulting FIS. We mostly just care about the status byte. The controller
|
||||||
|
will unset the bit for the completed command in the PxCI register when it
|
||||||
|
raises the interrupt so we can disambiguate which command has finished.
|
||||||
|
|
||||||
|
Although this sounds straightforward there are a few moving parts here that we
|
||||||
|
need to get up and running.
|
||||||
|
|
||||||
|
- We need to find where the HBA structure is in memory.
|
||||||
|
- We need to allocate some space for the command tables and received FIS
|
||||||
|
structures.
|
||||||
|
- We need to set up interrupt handling for each port.
|
||||||
|
- Before this we will issue a hardware reset command to the controller to get
|
||||||
|
everything in a clean state.
|
||||||
|
|
||||||
|
## Finding the HBA structure
|
||||||
|
|
||||||
|
We find the HBA structure by iterating through the PCI configuration space and
|
||||||
|
finding AHCI device. I'm not going to delve too deeply into this because PCI
|
||||||
|
could be a whole separate post and it is a little trickier to explain because
|
||||||
|
it is harder to access the specifications (the good people at the PCI "Special
|
||||||
|
Interest Group" are happy to let you download the PDF for the low low price of
|
||||||
|
$4500 if you are not a member).
|
||||||
|
|
||||||
|
The short story is that we are looking for the device with the right [class
|
||||||
|
code](https://wiki.osdev.org/PCI#Class_Codes) - Class Code 0x1 (Storage Device),
|
||||||
|
Subclass 0x6 (SATA Controller), Subtype 0x1 (AHCI).
|
||||||
|
|
||||||
|
Once we have the correct configuration space we cn read the address at offset
|
||||||
|
0x24 (called the ABAR for AHCI Base Address) which points to the start of the
|
||||||
|
GHC registers.
|
||||||
|
|
||||||
|
We can mostly ignore the other information in the configuration space for now as
|
||||||
|
we aren't dealing with Message Signaled Interrupts yet.
|
||||||
|
|
||||||
|
## Hardware Reset
|
||||||
|
|
||||||
|
Now that we have found the Global Host Controller registers we're going to
|
||||||
|
initiate a hardware reset of the AHCI Controller. The advantage of this is we
|
||||||
|
will know the exact state that the controller and its ports are in. Other than
|
||||||
|
that it ensures that we aren't dependent on the specific way limine uses the
|
||||||
|
AHCI controller.
|
||||||
|
|
||||||
|
I suspect that this is **not** how most production operating systems handle
|
||||||
|
things but this should give us a clean slate for now.
|
||||||
|
|
||||||
|
From the AHCI spec:
|
||||||
|
|
||||||
|
> 10.4.3 HBA Reset
|
||||||
|
>
|
||||||
|
> If the HBA becomes unusable for multiple ports, and a software reset or port
|
||||||
|
> reset does not correct the problem, software may reset the entire HBA by
|
||||||
|
> setting GHC.HR to ‘1’. When software sets the GHC.HR bit to ‘1’, the HBA
|
||||||
|
> shall perform an internal reset action. The bit shall be cleared to ‘0’ by
|
||||||
|
> the HBA when the reset is complete. A software write of ‘0’ to GHC.HR shall
|
||||||
|
> have no effect. To perform the HBA reset, software sets GHC.HR to ‘1’ and may
|
||||||
|
> poll until this bit is read to be ‘0’, at which point software knows that the
|
||||||
|
> HBA reset has completed.
|
||||||
|
>
|
||||||
|
> If the HBA has not cleared GHC.HR to ‘0’ within 1 second of software setting
|
||||||
|
> GHC.HR to ‘1’, the HBA is in a hung or locked state.
|
||||||
|
>
|
||||||
|
> When GHC.HR is set to ‘1’, GHC.AE, GHC.IE, the IS register, and all port
|
||||||
|
> register fields (except PxFB/PxFBU/PxCLB/PxCLBU) that are not HwInit in the
|
||||||
|
> HBA’s register memory space are reset. The HBA’s configuration space and all
|
||||||
|
> other global registers/bits are not affected by setting GHC.HR to ‘1’. Any
|
||||||
|
> HwInit bits in the port specific registers are not affected by setting GHC.HR
|
||||||
|
> to ‘1’. The port specific registers PxFB, PxFBU, PxCLB, and PxCLBU are not
|
||||||
|
> affected by setting GHC.HR to ‘1’. If the HBA supports staggered spin-up, the
|
||||||
|
> PxCMD.SUD bit will be reset to ‘0’; software is responsible for setting the
|
||||||
|
> PxCMD.SUD and PxSCTL.DET fields appropriately such that communication can be
|
||||||
|
> established on the Serial ATA link. If the HBA does not support staggered
|
||||||
|
> spin-up, the HBA reset shall cause a COMRESET to be sent on the port.
|
||||||
|
|
||||||
|
Despite the long text, this process is fairly straightforward. We set the
|
||||||
|
Hardware Reset bit and then poll for it to be set to 0. We then set the AHCI
|
||||||
|
enable bit. For now we can leave interrupts disabled until we have reset the
|
||||||
|
ports. Once this is done we sleep for a few milliseconds to allow the ports time
|
||||||
|
to spin up. For now we are just using 50ms because that is the smallest
|
||||||
|
resolution we support sleeping for (1 scheduling tick) but I think theoretically
|
||||||
|
we could sleep for only a millisecond or two.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
ahci_hba_->global_host_control |= kGlobalHostControl_HW_Reset;
|
||||||
|
|
||||||
|
while (ahci_hba_->global_host_control & kGlobalHostControl_HW_Reset) {
|
||||||
|
continue;
|
||||||
|
}
|
||||||
|
|
||||||
|
ahci_hba_->global_host_control |= kGlobalHostControl_AHCI_Enable;
|
||||||
|
|
||||||
|
return static_cast<glcr::ErrorCode>(ZThreadSleep(50));
|
||||||
|
```
|
||||||
|
|
||||||
|
## Port Initialization
|
||||||
|
|
||||||
|
Now we can initialize each port that is implemented. There are two cases we
|
||||||
|
need to handle. Either the port has received a COMRESET and is running, or
|
||||||
|
staggered spin up is supported and we need to enable the port. As our VM doesn't
|
||||||
|
require staggered spin up, we will skip it for now and come back to it in the
|
||||||
|
future.
|
||||||
|
|
||||||
|
Before initializing each port we need to check if it has a device attached. We
|
||||||
|
can do that by checking the PxSSTS register described in the AHCI spec section
|
||||||
|
3.3.10.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
We are looking for a value 0x103, 0x100 indicating that the device is active
|
||||||
|
and 0x3 indicating that communication is established. For each port where we
|
||||||
|
detect this value we continue the initialization process.
|
||||||
|
|
||||||
|
### Memory Structures
|
||||||
|
|
||||||
|
We need to initialize the memory structures for each active port as shown in the
|
||||||
|
image before (under How AHCI works).
|
||||||
|
|
||||||
|
We need a command list structure of length 0x400 (technically it need not be
|
||||||
|
that long if fewer than 32 commands are supported but it doesn't use much
|
||||||
|
additional memory). Additionally a spot is needed for received FIS structure of
|
||||||
|
length 0x100. Finally each of the 32 commands in the command list must point to
|
||||||
|
a command table. Technically these can be quite large because each can hold up
|
||||||
|
to 2^16 physical region descriptors (using ~1 MiB of memory). I've opted
|
||||||
|
to limit it to just 8 16-byte descriptors so each command table would be length
|
||||||
|
0x100 as well. For now we don't support scatter gather buffers and just allocate
|
||||||
|
one contiguous memory section for each read.
|
||||||
|
|
||||||
|
In total all of these memory structures takes 0x2500 bytes (3 pages of RAM). We
|
||||||
|
allocate them all in one block and manually set up the pointers to their
|
||||||
|
physical addresses in the HBA port control.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
// 0x0-0x400 -> Command List
|
||||||
|
// 0x400-0x500 -> Received FIS
|
||||||
|
// 0x500-0x2500 -> Command Tables (0x100 each) (Max PRDT Length is 8 for now)
|
||||||
|
uint64_t paddr;
|
||||||
|
command_structures_ =
|
||||||
|
mmth::OwnedMemoryRegion::ContiguousPhysical(0x2500, &paddr);
|
||||||
|
command_list_ = reinterpret_cast<CommandList*>(command_structures_.vaddr());
|
||||||
|
port_struct_->command_list_base = paddr;
|
||||||
|
|
||||||
|
received_fis_ =
|
||||||
|
reinterpret_cast<ReceivedFis*>(command_structures_.vaddr() + 0x400);
|
||||||
|
port_struct_->fis_base = paddr + 0x400;
|
||||||
|
port_struct_->command |= kCommand_FIS_Receive_Enable;
|
||||||
|
|
||||||
|
command_tables_ = glcr::ArrayView(
|
||||||
|
reinterpret_cast<CommandTable*>(command_structures_.vaddr() + 0x500), 32);
|
||||||
|
|
||||||
|
for (uint64_t i = 0; i < 32; i++) {
|
||||||
|
// This leaves space for 2 prdt entries.
|
||||||
|
command_list_->command_headers[i].command_table_base_addr =
|
||||||
|
(paddr + 0x500) + (0x100 * i);
|
||||||
|
commands_[i] = nullptr;
|
||||||
|
}
|
||||||
|
port_struct_->interrupt_enable =
|
||||||
|
kInterrupt_D2H_FIS | kInterrupt_PIO_FIS | kInterrupt_DMA_FIS |
|
||||||
|
kInterrupt_DeviceBits_FIS | kInterrupt_Unknown_FIS;
|
||||||
|
port_struct_->sata_error = -1;
|
||||||
|
port_struct_->command |= kCommand_Start;
|
||||||
|
```
|
||||||
|
|
||||||
|
There are a few other things going on here. Once we allocate the space to
|
||||||
|
receive FIS structures we let the port know that it can send FISes using the
|
||||||
|
PxCMD register.
|
||||||
|
|
||||||
|
Additionally at the end we enable interrupts, clear the error register, and
|
||||||
|
tell the port it can start processing commands.
|
||||||
|
|
||||||
|
## Interrupt Handling
|
||||||
|
|
||||||
|
Now that the device is initialized we can actually begin to send it commands.
|
||||||
|
To do so we need to register an interrupt handler with the correct PCI
|
||||||
|
interrupt line (for now we will use the direct interrupt line rather than
|
||||||
|
Message Signaled Interrupts). Registering interrupt handlers is a whole other
|
||||||
|
beast so for this post we will just focus on their implementation.
|
||||||
|
|
||||||
|
The first step is to de-multiplex the interrupt in the controller by checking
|
||||||
|
the interrupt status register. Each port that has an interrupt pending will
|
||||||
|
raise it's corresponding bit in the Interrupt Status register. We can delegate
|
||||||
|
to each port the handling of an interrupt, then clear the interrupt bit once it
|
||||||
|
is done. The relevant code in this case looks like this:
|
||||||
|
|
||||||
|
```c++
|
||||||
|
for (uint64_t i = 0; i < num_ports_; i++) {
|
||||||
|
if (!ports_[i].empty() && (ahci_hba_->interrupt_status & (1 << i))) {
|
||||||
|
ports_[i]->HandleIrq();
|
||||||
|
ahci_hba_->interrupt_status &= ~(1 << i);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Then on the port side we can handle the interrupt. This requires determining
|
||||||
|
what kind of interrupt was generated using the port's Interrupt Status register
|
||||||
|
(PxIS). Each of the 17 defined bits in this register correspond to a different
|
||||||
|
interrupt type and can be individual enabled and disabled using the port's
|
||||||
|
Interrupt Enable register (PxIE). For now as we registered when setting up the
|
||||||
|
port we will only handle the interrupts related to receiving FISes from the
|
||||||
|
device.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
void AhciDevice::HandleIrq() {
|
||||||
|
uint32_t int_status = port_struct_->interrupt_status;
|
||||||
|
port_struct_->interrupt_status = int_status;
|
||||||
|
|
||||||
|
bool has_error = false;
|
||||||
|
if (int_status & kInterrupt_D2H_FIS) {
|
||||||
|
dbgln("D2H Received");
|
||||||
|
// Device to host.
|
||||||
|
volatile DeviceToHostRegisterFis& fis =
|
||||||
|
received_fis_->device_to_host_register_fis;
|
||||||
|
if (!CheckFisType(FIS_TYPE_REG_D2H, fis.fis_type)) {
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
if (fis.error) {
|
||||||
|
dbgln("D2H err: {x}", fis.error);
|
||||||
|
dbgln("status: {x}", fis.status);
|
||||||
|
has_error = true;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
if (int_status & kInterrupt_PIO_FIS) {
|
||||||
|
// Like above ...
|
||||||
|
}
|
||||||
|
if (int_status & kInterrupt_DMA_FIS) {
|
||||||
|
// Like above ...
|
||||||
|
}
|
||||||
|
// ...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
To handle the interrupt we read the raised interrupts from the PxIS register and
|
||||||
|
write the values back to it to clear them. Then we can specify how to handle
|
||||||
|
each type of interrupt that we receive. For now we will just debug print the
|
||||||
|
type and any errors from the interrupt since we aren't sending any commands.
|
||||||
|
|
||||||
|
Something I'm not sure about is that as soon as we enable interrupts we seem to
|
||||||
|
receive a FIS from the device with an error bit set. Both the hard drive and the
|
||||||
|
optical drive on qemu send a FIS with error bit 0x1 set. Additionally the status
|
||||||
|
field is set to 0x30 for the hard drive and 0x70 for the optical drive.
|
||||||
|
|
||||||
|
I was able to find a [OSDev Forum
|
||||||
|
post](https://forum.osdev.org/viewtopic.php?f=1&t=56462&start=15#p342163)
|
||||||
|
referencing that this behavior is caused by the reset sending an EXECUTE DEVICE
|
||||||
|
DIAGNOSTIC command (0x90) to the device. It notes that this is largely
|
||||||
|
undocumented behavior but at least this information offers some clarity on the
|
||||||
|
outputs. Reading the ATA Command Set section 7.9.4 we can see that the command
|
||||||
|
ouputs code 0x01 to the error bits when `Device 0 passed, Device 1 passed or not
|
||||||
|
present`. According a footnote we can "See the appropriate transport standard
|
||||||
|
for the definition of device 0 and device 1." I really thought I was already
|
||||||
|
looking at the "appropriate transport standard" but alas. All that to say we'll
|
||||||
|
just ignore this interrupt for now.
|
||||||
|
|
||||||
|
## Sending a Command
|
||||||
|
|
||||||
|
Now that the AHCI ports are initialized and can handle an interrupt, we can send
|
||||||
|
commands to them. To start with lets send the IDENTIFY DEVICE command to each
|
||||||
|
device. This command asks the device to send 512 bytes of information about
|
||||||
|
itself back to us. These bytes contain 40 years of certified-crufty backwards
|
||||||
|
compatability. I mean just feast your eyes on the number of retired and obsolete
|
||||||
|
fields in just the first page of the spec.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
We'll ignore almost all of this information and just try to get the sector size
|
||||||
|
and sector count from the drive. To do so we need to figure out how to send a
|
||||||
|
command to the device. To be honest I feel like the specs fall down here in
|
||||||
|
actually explaining this. The trick is to send a Register Host to Device FIS in one
|
||||||
|
of the command slots. This FIS type has a field for the command as well as some
|
||||||
|
common parameters such as lba and count. In retrospect it is fairly clear once
|
||||||
|
you are aware of it, but if you are just reading the SATA spec and looking at
|
||||||
|
the possible commands, making the logical jump to the Register Host To Device
|
||||||
|
FIS feels damn near impossible.
|
||||||
|
|
||||||
|
First up we chose an empty command slot to use:
|
||||||
|
|
||||||
|
```c++
|
||||||
|
uint64_t slot;
|
||||||
|
for (slot = 0; slot < 32; slot++) {
|
||||||
|
if (!(commands_issued_ & (1 << slot))) {
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
if (slot == 32) {
|
||||||
|
dbgln("All slots full");
|
||||||
|
return glcr::INTERNAL;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
The `commands_issued_` variable is just for our own accounting of which slots
|
||||||
|
are currently in use by another command.
|
||||||
|
|
||||||
|
Next we can populate the FIS for that slot. The spec for the Register Host to
|
||||||
|
Device FIS is as follows:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
We don't need to initialize most of the fields here because the IDENTIFY_DEVICE
|
||||||
|
call doesn't rely on an lba or sector count. One of the keys is setting the high
|
||||||
|
bit "C" in the byte that contains PM Port which indicates to the HBA that this
|
||||||
|
FIS contains a new command (I spent a while trying to figure out why this wasn't
|
||||||
|
working without that). The code for this is relatively straightforward.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
auto* fis = reinterpret_cast<HostToDeviceRegisterFis*>(
|
||||||
|
command_tables_[slot].command_fis);
|
||||||
|
*fis = HostToDeviceRegisterFis{
|
||||||
|
.fis_type = FIS_TYPE_REG_H2D,
|
||||||
|
.pmp_and_c = 0x80,
|
||||||
|
.command = kIdentifyDevice, // 0xEC
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
We also need to let the HBA know where it can put the result in memory. For this
|
||||||
|
we use the physical region descriptor table corresponding to this command slot.
|
||||||
|
As described before, for simplicity now we are only using a single entry to do
|
||||||
|
this. We allocate a 512 byte memory region and set it's physical address and
|
||||||
|
size in the first slot of the command slots PRDT.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
uint64_t paddr;
|
||||||
|
auto region =
|
||||||
|
mmth::OwnedMemoryRegion::ContiguousPhysical(0x200, &paddr);
|
||||||
|
command_tables_[slot].prdt[0].region_address = command.paddr;
|
||||||
|
command_tables_[slot].prdt[0].byte_count = 0x200; // 512 bytes
|
||||||
|
command_list_->command_headers[slot].prd_table_length = 1;
|
||||||
|
```
|
||||||
|
|
||||||
|
All that is left to do is to issue the command! We set the size of the command
|
||||||
|
FIS (in double words for some reason?) as well as let the HBA know it can
|
||||||
|
prefetch the data from memory. Then we set the bit for this command slot in the
|
||||||
|
PxCI register which will cause the device to start processing it.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
// Set the command FIS length (in double words).
|
||||||
|
command_list_->command_headers[slot].command =
|
||||||
|
(sizeof(HostToDeviceRegisterFis) / 4) & 0x1F;
|
||||||
|
|
||||||
|
// Set prefetch bit.
|
||||||
|
command_list_->command_headers[slot].command |= (1 << 7);
|
||||||
|
|
||||||
|
// TODO: Synchronization-wise we need to ensure this is set in the same
|
||||||
|
// critical section as where we select a slot.
|
||||||
|
commands_issued_ |= (1 << slot);
|
||||||
|
port_struct_->command_issue |= (1 << slot);
|
||||||
|
```
|
||||||
|
|
||||||
|
But wait! How will we know when this command has completed? We somehow need to
|
||||||
|
wait until we receive an interrupt for this command to proccess the data it
|
||||||
|
sent. To handle this we can add a semaphore for each port command slot to allow
|
||||||
|
signalling when we recieve a completion interrupt for that command. I think it
|
||||||
|
might make sense to have some sort of callback instead so we can pass errors
|
||||||
|
back to the caller instead of just a completion signal. However I'm not sure
|
||||||
|
what type of errors exist that are resolvable by the caller so for now this
|
||||||
|
works.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
void IdentifyDevice() {
|
||||||
|
...
|
||||||
|
// Issue command.
|
||||||
|
commands_issued_ |= (1 << slot);
|
||||||
|
port_struct_->command_issue |= (1 << slot);
|
||||||
|
|
||||||
|
command_signals_[slot].Wait();
|
||||||
|
|
||||||
|
// Continue processing.
|
||||||
|
...
|
||||||
|
}
|
||||||
|
|
||||||
|
void AhciPort::HandleIrq() {
|
||||||
|
uint32_t int_status = port_struct_->interrupt_status;
|
||||||
|
port_struct_->interrupt_status = int_status;
|
||||||
|
|
||||||
|
...
|
||||||
|
// Parse received FIS.
|
||||||
|
...
|
||||||
|
|
||||||
|
uint32_t commands_finished = commands_issued_ & ~port_struct_->command_issue;
|
||||||
|
|
||||||
|
for (uint64_t i = 0; i < 32; i++) {
|
||||||
|
if (commands_finished & (1 << i)) {
|
||||||
|
command_signals_[i].Signal();
|
||||||
|
commands_issued_ &= ~(1 << i);
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Ok now that we have retrieved the information from the drive we can parse it.
|
||||||
|
For the sector size, the default is 512 bytes which we will use unless the
|
||||||
|
`LOGICAL SECTOR SIZE SUPPORTED` bit is set in double word 106, bit 12. If that
|
||||||
|
is set we can check the double words at 117 and 118 to get the 32 bit sector
|
||||||
|
size value. For the sector count, we need to check if the device supports 48 bit
|
||||||
|
addressing using double word 83 bit 10. If it is used we can get the number of
|
||||||
|
sectors from the 4 double words starting at 100. Otherwise we read the number of
|
||||||
|
sectors from the 2 double words starting at index 60.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
uint16_t* ident = reinterpret_cast<uint16_t*>(region.vaddr());
|
||||||
|
if (ident[106] & (1 << 12)) {
|
||||||
|
sector_size_ = *reinterpret_cast<uint32_t*>(ident + 117);
|
||||||
|
} else {
|
||||||
|
sector_size_ = 512;
|
||||||
|
}
|
||||||
|
|
||||||
|
if (ident[83] & (1 << 10)) {
|
||||||
|
lba_count_ = *reinterpret_cast<uint64_t*>(ident + 100);
|
||||||
|
} else {
|
||||||
|
lba_count_ = *reinterpret_cast<uint32_t*>(ident + 60);
|
||||||
|
}
|
||||||
|
dbgln("Sector size: {x}", sector_size_);
|
||||||
|
dbgln("LBA Count: {x}", lba_count_);
|
||||||
|
is_init_ = true;
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
You might be rightfully thinking that it would be less brittle to make a struct
|
||||||
|
definition that we could point at this address which would implicitly contain
|
||||||
|
these offsets - and you would be correct. But to be honest, I can't be bothered
|
||||||
|
to create a 256 entry struct definition just to get these values. Maybe in the
|
||||||
|
future.
|
||||||
|
|
||||||
|
## Reading Data
|
||||||
|
|
||||||
|
Now that we have the ability to read the IDENTIFY DEVICE data we are only a
|
||||||
|
short hop, skip, and jump away from reading data from the drive. The main
|
||||||
|
differences when reading data are (a) the command number, (b) we must specify
|
||||||
|
the Logical Block Address (LBA) we want to read from and the number of sectors
|
||||||
|
to read, and (c) we need to dynamically size the entry in the Physical Region
|
||||||
|
Descriptor Table (we will still use only one entry for now).
|
||||||
|
|
||||||
|
Because much of this is similar we can fairly easily create a shared struct with
|
||||||
|
the necessary information and construct the requests in parallel.
|
||||||
|
|
||||||
|
```c++
|
||||||
|
struct Command {
|
||||||
|
uint8_t command;
|
||||||
|
uint64_t lba;
|
||||||
|
uint32_t sectors;
|
||||||
|
uint64_t paddr;
|
||||||
|
};
|
||||||
|
```
|
||||||
|
|
||||||
|
Then from that we can create an IssueCommand function that constructs the
|
||||||
|
Register Host to Device FIS in a similar way for both. Before that I'd like to
|
||||||
|
take this opportunity to point out how the LBA in this FIS is stored in a way
|
||||||
|
that truly only a mother could love:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
That asside we simply update the FIS construction to set the command, LBA, and
|
||||||
|
sector count. Following that we set the PRDT values (although we still only use
|
||||||
|
one slot).
|
||||||
|
|
||||||
|
```c++
|
||||||
|
auto* fis = reinterpret_cast<HostToDeviceRegisterFis*>(
|
||||||
|
command_tables_[slot].command_fis);
|
||||||
|
*fis = HostToDeviceRegisterFis{
|
||||||
|
.fis_type = FIS_TYPE_REG_H2D,
|
||||||
|
.pmp_and_c = 0x80,
|
||||||
|
.command = command.command,
|
||||||
|
|
||||||
|
.lba0 = static_cast<uint8_t>(command.lba & 0xFF),
|
||||||
|
.lba1 = static_cast<uint8_t>((command.lba >> 8) & 0xFF),
|
||||||
|
.lba2 = static_cast<uint8_t>((command.lba >> 16) & 0xFF),
|
||||||
|
.device = (1 << 6), // ATA LBA Mode
|
||||||
|
|
||||||
|
.lba3 = static_cast<uint8_t>((command.lba >> 24) & 0xFF),
|
||||||
|
.lba4 = static_cast<uint8_t>((command.lba >> 32) & 0xFF),
|
||||||
|
.lba5 = static_cast<uint8_t>((command.lba >> 40) & 0xFF),
|
||||||
|
|
||||||
|
.count = command.sectors,
|
||||||
|
};
|
||||||
|
|
||||||
|
command_tables_[slot].prdt[0].region_address = command.paddr;
|
||||||
|
command_tables_[slot].prdt[0].byte_count = 512 * command.sectors;
|
||||||
|
```
|
||||||
|
|
||||||
|
Then issuing either the identify device command or the read command is
|
||||||
|
relatively straightforward:
|
||||||
|
|
||||||
|
```c++
|
||||||
|
// IDENTIFY DEVICE
|
||||||
|
CommandInfo identify{
|
||||||
|
.command = kIdentifyDevice,
|
||||||
|
.lba = 0,
|
||||||
|
.sectors = 1,
|
||||||
|
.paddr = 0,
|
||||||
|
};
|
||||||
|
auto region =
|
||||||
|
mmth::OwnedMemoryRegion::ContiguousPhysical(0x200, &identify.paddr);
|
||||||
|
ASSIGN_OR_RETURN(auto* sem, IssueCommand(identify));
|
||||||
|
sem->Wait();
|
||||||
|
|
||||||
|
// DMA READ
|
||||||
|
CommandInfo dma_read{
|
||||||
|
.command = kDmaReadExt,
|
||||||
|
.lba = lba,
|
||||||
|
.sectors = sector_cnt,
|
||||||
|
.paddr = 0,
|
||||||
|
};
|
||||||
|
auto region =
|
||||||
|
mmth::OwnedMemoryRegion::ContiguousPhysical(0x200 * sector_cnt, &read.paddr);
|
||||||
|
ASSIGN_OR_RETURN(auto* sem, IssueCommand(dma_read));
|
||||||
|
sem->Wait();
|
||||||
|
```
|
||||||
|
|
||||||
|
From here the world is our oyster and we can read any arbitrary data from the
|
||||||
|
disk. The bulk of this code isn't actually all that long (~200 LOC in the [AHCI
|
||||||
|
Port implementation](https://gitea.tiramisu.one/drew/acadia/src/commit/21265e76edf4fa93b8ec1795da4bdd2fc70b79d9/sys/denali/ahci/ahci_port.cpp)
|
||||||
|
). However I probably added and deleted several times that trying to get
|
||||||
|
everything working and refactored down to a nice interface.
|
||||||
|
|
||||||
|
## Coming next
|
||||||
|
|
||||||
|
This is nowhere near a full implementation. Among the things we
|
||||||
|
skipped that I plan to come back to at some point are:
|
||||||
|
|
||||||
|
- **Staggered spin up:** In controllers that support this, each device is
|
||||||
|
powered down after RESET and must be started individually.
|
||||||
|
- **Message Signaled Interrupts:** The hot new way to handle PCI device
|
||||||
|
interrupts. Has only been available since 1998 so support may vary.
|
||||||
|
- **Port Multiplier Support:** Something that gets mentioned all over the specs
|
||||||
|
but I've avoided evening looking into until this moment. But it looks like it
|
||||||
|
allows several devices behind a single port.
|
||||||
|
- **Scatter Gather buffers:** For big files we may not always be able to find a
|
||||||
|
sufficient contiguous chunk of physical memory. This means we may have to use
|
||||||
|
more than one entry in the PRDT!
|
||||||
|
- **Error Handling & Retry:** Even though QEMU may succeed in executing commands
|
||||||
|
100% of the time, real hardware may not and we should probably handle that.
|
||||||
|
- **Less that 32 commands supported:** We kinda always assume that the device
|
||||||
|
can handle 32 commands even though it may not (how many it does is exposed in
|
||||||
|
the GHC registers).
|
||||||
|
|
@ -12,3 +12,7 @@ title = "Drew's Site"
|
||||||
url = 'https://www.linkedin.com/in/drew-galbraith/'
|
url = 'https://www.linkedin.com/in/drew-galbraith/'
|
||||||
weight = 30
|
weight = 30
|
||||||
|
|
||||||
|
[markup]
|
||||||
|
[markup.highlight]
|
||||||
|
noClasses = false
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,6 +8,16 @@
|
||||||
{{- end }}
|
{{- end }}
|
||||||
{{- end }}
|
{{- end }}
|
||||||
|
|
||||||
|
{{- with resources.Get "css/syntax.css" }}
|
||||||
|
{{- if eq hugo.Environment "development" }}
|
||||||
|
<link rel="stylesheet" href="{{ .RelPermalink }}">
|
||||||
|
{{- else }}
|
||||||
|
{{- with . | minify | fingerprint }}
|
||||||
|
<link rel="stylesheet" href="{{ .RelPermalink }}" integrity="{{ .Data.Integrity }}" crossorigin="anonymous">
|
||||||
|
{{- end }}
|
||||||
|
{{- end }}
|
||||||
|
{{- end }}
|
||||||
|
|
||||||
{{- range .Resources.Match "css/*.css" }}
|
{{- range .Resources.Match "css/*.css" }}
|
||||||
{{- if eq hugo.Environment "development" }}
|
{{- if eq hugo.Environment "development" }}
|
||||||
<link rel="stylesheet" href="{{ .RelPermalink }}">
|
<link rel="stylesheet" href="{{ .RelPermalink }}">
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue