What should I do before switching to Protected or long-mode

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
rdos
Member
Member
Posts: 3308
Joined: Wed Oct 01, 2008 1:55 pm

Re: What should I do before switching to Protected or long-m

Post by rdos »

The main issue why I would want to use ACPI for PCI device identification is the IRQ routing table. The IRQ entry read-out of PCI configuration space is frequently wrong when the APIC is used. Especially for new hardware on newer machines.

I think I will use the presence of the _PRT entry to decide if I would use the old PCI identification scheme or ACPI entries.
Cognition
Member
Member
Posts: 191
Joined: Tue Apr 15, 2008 6:37 pm
Location: Gotham, Batmanistan

Re: What should I do before switching to Protected or long-m

Post by Cognition »

PCI0 does tend to be a PCI or PCI-Ex root bus (you can tell based on the _HID field, _CID will always show it as a PCI Bus). Basically there are some possible PCI configurations that might involve multiple root buses that may not be listed in the MCFG table, usually due to hot-plugging as Brendan suggested. Before you actually go about traversing the ACPI namespace you're required to have access to certain buses, basically any System Memory and System IO addresses, any Embedded Controllers listed in a ECDT and any PCI bus ranges listed with a _BBN field (Really this amounts to providing access to any PCI Bus address ranges stumble across the firmware from what I've seen). Most other bus regions should be initialized on the fly (via _HID or _CID) and have their availability indicated by calling the corresponding _REG method to indicate region availability. It's basically a way to allow certain buses to be defined in AML and provide some sanity checks so an interpreter won't crash and burn if access to a bus isn't available. You can also use the _OSC method to indicate to ACPI what extended PCI features an OS actually supports, presumably to keep it from doing anything too crazy if the OS doesn't know how to handle it.

There's also the PCIBarTarget type region, which apparently exists just so ACPI can retain control over specific PCI Device functions without the OS loading native drivers for them. In general it's probably safer to actually traverse and enumerate a PCI bus after you've enumerated the ACPI namespace. ACPICA allows you to setup several callbacks to handle most of this in a sane fashion.
Reserved for OEM use.
Post Reply