OSDev.org

Ok, so I finally recieved a copy of the PCI Express Base Specification and there is now a small wiki article about PCI Express (http://wiki.osdev.org/PCI_Express). It also contains a sub-section about the extended configuration space and how to access it using the enhanced configuration mechanism (the missing Mechanism #2 from the PCI article). I still have a lot of work to do, and as I am a horrible article writer, I do apologize.

On a related note, I also have the latest SATA Specifications, and when I can get around to it, you might see some articles on that as well.

Could you please explain somehow the differences of using "draft" specifications instead of "official" ones?

Would someone be missing things that would totally prevent from producing correct SATA/PCI, etc., drivers/programs?

I'm a little confused as to why you are asking here, but I will gladly provide an answer.

A draft specification is not the official release, and as such, the working group designing the specification could technically decide to dump everything from one draft, rewrite it and implement everything in a completely different way in the next draft (although this almost never happens with published drafts).

Point #1: The latest draft specification for the C++ standard (http://open-std.org/JTC1/SC22/WG21/docs ... /n3090.pdf) contains the following disclaimer: "Note: this is an early draft. It’s known to be incomplet and incorrekt, and it has lots of bad formatting.".

Point #2: The ATA-7 Specification decided to go off and print information from the SATA v1.0 draft specification, several things were changed and by the time the SATA specification was ratified, the two standards said two completely different things, thus leading to a conflict in implementations.

Point #3: Would you really want to provide the equivalent of beta software in a release version of your project or operating system? That is essentially what a draft specification is, it is a beta version of the ratified document.


I hope this answers your question. If not, I'd be happy to ellaborate.

Yes, that's basically what I meant. And so it seems a seriously expensive situation to try to fully keep up with the standards for the sake of correct code, sadly for a lot of newer hardware specifications (maybe purely software ones also), but of course it must be done sooner rather than later, as long as possible.

Thanks for the articles anyway. I will try to code some things about SATA, PCI, and USB, as soon as I can, and give code, feedback, questions, etc., for trying to make it more complete and understandable.

Great! Looks like a verb is missing in this sentence, though: "The minimum memory address range requested by a BAR 128-bytes. "

The xor ax,ax in the code example looks suspicious. Does this mean that bits 16-19 of MSR 0xC0000158 are guarranteed to be zero?

getPCIBusRange won't work since "shl ah,al" isn't an instruction. It should probably be:

What's the definition of bit 6-19 and 0-1 in MSR 0xC0000158? If bit 6 is always zero, the and al,0x3c above can be removed.

Good writeup, one thing I'm curious about is the MSR mechanism though. Is it innately supported by every PCI Express system or just newer ones? I know there's also the ACPI MCFG tables available for enumeration of PCI MMIO ranges. Is there actually preferred method recommended for x86 based systems?

Hi,



The ACPI MCFG tables are the preferred method.

The MSR only exists on AMD CPUs with hyper-transport (family = 10 and family = 11). Nobody can really be sure if later/future AMD CPUs will use this MSR or not.


Cheers,

Brendan

Good to know, thanks for the info Brendan.