OSDev.org

It is the time to communicate with the hardware. I am reading ACPI specification but I cannot clearly understand what this thing is (is a part of BIOS code-data right?) , what is doing (ok I read the tables, then?) and If there doesn't exist, how to replace them?

After that I want to program the hardware (chips and controllers), that's easy, question for this another time.

At the end I need to set up LAPIC's, IOAPIC and PIC's to handle the hardware Interrupts? As I was reading MP specification (is that something more than a manual?) I saw that maybe PIT (IRQ0) and DMA (IRQ13) isn't connected to IOAPIC, only to PIC. At wiki I read that in MADT table (ACPI)
that many defined that some IRQ many are connected different from normal. How can I get a list on runtime with the present IRQ's and where they are connected from both sides (sender, receiver(PIC, IOAPIC or both))?
If some interrupt isn't set to IOAPIC I need to set up PIC's and handle their interrupts. How to do that? I know that PIC's INTR pin is connected to all LAPIC's and how to handle them but how can I disable the sending the interrupts directly to bootstrap processors INTR pin?

I know that there are many questions so if you can answer only some questions please answer.

Hi,

ARISTOS wrote:It is the time to communicate with the hardware. I am reading ACPI specification but I cannot clearly understand what this thing is (is a part of BIOS code-data right?) , what is doing (ok I read the tables, then?) and If there doesn't exist, how to replace them?

ACPI can be described as 2 parts; where the first part is tables that an OS parses to get various pieces of information that can't change while the computer is running, and the second part is a pile of code that an OS can use to get information that can change while the computer is running and handle various events. The code for the second part is stored as byte-code (called AML or ACPI Machine Language) and you need an "AML interpreter" to execute/interpret that code.

Some devices (IO APIC, HPET, etc; plus legacy devices like PIT, RTC) are assumed to be built into the chipset where they can't be changed while the computer is running; so they're described by tables (e.g. ACPI's "APIC/MADT" table describes how many IO APICs there are, how legacy IRQs are connected to those IO APICs, etc).

ACPI has always supported hot-plug PCI; so it assumes that (for some computers) PCI devices may be changed while the computer is running. For this reason PCI devices (and how PCI IRQs are connected to the IO APIC) can't be described by static tables and are described by AML code instead. This means you need an "AML interpreter" to execute/interpret the code to figure out how PCI IRQs are connected to IO APIC inputs.

ARISTOS wrote:At the end I need to set up LAPIC's, IOAPIC and PIC's to handle the hardware Interrupts?

Early during boot you mostly want to mask everything in the PIC and IO APIC; and initialise tables to keep track of what is using each (PIC or IOAPIC) input and what is using each interrupt vector/IDT entry. When you're starting a device driver for a specific device, you install its IRQ handler/s (if any) and then use the information you've obtained to enable/configure that device's IRQ in the PIC or IO APIC. When you're terminating or uninstalling a device driver you do the opposite (mask the device's IRQ in the PIC or IO APIC, then uninstall its IRQ handler/s).

As part of this you'll eventually want some kind of "interrupt vector manager" to allocate and free interrupt vectors/IDT entries. This is important for MSI ("Message Signalled Interrupts") which is a feature of PCI, where the device can send a message to the CPU saying that it wants to interrupt that bypasses the PIC and IO APIC (e.g. doesn't use any IO APIC input). For this the device's PCI configuration space might say it wants 16 IRQs, so you'd use your "interrupt vector manager" to allocate 16 (consecutive) interrupt vectors and then set up the device to use the 16 interrupt vectors that you allocated. Note that ACPI's AML isn't involved for MSI IRQs, which makes it quite attractive if you don't have an AML interpreter yet.

ARISTOS wrote:As I was reading MP specification (is that something more than a manual?)

The MP specification is an old standard that existed before ACPI; that was superseded by ACPI. In general you should search for ACPI tables and use ACPI if it exists, but if there are no ACPI tables (because the computer is too old) then you'd search for MP specification tables and use those instead. If you don't support old computers (e.g. 15 years old, or older) then there's no need to support MP specification's tables.

ARISTOS wrote:I saw that maybe PIT (IRQ0) and DMA (IRQ13) isn't connected to IOAPIC, only to PIC. At wiki I read that in MADT table (ACPI)
that many defined that some IRQ many are connected different from normal. How can I get a list on runtime with the present IRQ's and where they are connected from both sides (sender, receiver(PIC, IOAPIC or both))?

This is (part of) what all the ACPI (and MP specification) tables, and the AML code is for. To determine how devices IRQs are routed to PIC and IO APIC inputs (and how to configure the IO APIC inputs properly - e.g. as "level triggered" or "edge triggered" and as "active high" or "active low") you need to do a lot of work, including having an AML interpreter. There is no simple list that describes everything.

ARISTOS wrote:If some interrupt isn't set to IOAPIC I need to set up PIC's and handle their interrupts. How to do that?

During boot you decide whether you will use PIC or IO APIC. If you chose to use PIC then you do not use IO APIC for anything at all (and leave it disabled/masked). If you chose to use IO APIC then you do not use PIC chips for anything at all (and leave them disabled/masked).

If you chose to use IO APIC and old PIT chip's IRQ isn't connected to the IO APIC; don't use the old PIT chip (e.g. use the RTC and/or the local APIC timer and/or HPET instead).

ARISTOS wrote:I know that PIC's INTR pin is connected to all LAPIC's and how to handle them but how can I disable the sending the interrupts directly to bootstrap processors INTR pin?

You don't. If you're not using the PIC chips, you mask all IRQs in all PIC chips and leave the PIC's INTR pin alone (and tell ACPI's AML that you're using IO APICs and not PICs so that it can do anything else that's has to be done for that computer).


Cheers,

Brendan

Brendan wrote:If you chose to use IO APIC and old PIT chip's IRQ isn't connected to the IO APIC; don't use the old PIT chip (e.g. use the RTC and/or the local APIC timer and/or HPET instead).

If HPET isn't present and PIT isn't connected to IOAPIC?

Brendan wrote:If you chose to use IO APIC then you do not use PIC chips for anything at all (and leave them disabled/masked)

And why I cannot use IOAPIC and PIC at the same time?

Brendan wrote:The MP specification is an old standard that existed before ACPI; that was superseded by ACPI. In general you should search for ACPI tables and use ACPI if it exists, but if there are no ACPI tables (because the computer is too old) then you'd search for MP specification tables and use those instead. If you don't support old computers (e.g. 15 years old, or older) then there's no need to support MP specification's tables.

How often a modern computer does not support ACPI?

Brendan wrote:The code for the second part is stored as byte-code (called AML or ACPI Machine Language) and you need an "AML interpreter" to execute/interpret that code.

Can you tell me an example of how AML works? The AML interpreter is interpreting the code and then? Do this code changes at runtime?
Can I build an AML interpreter, if yes where can I found reference?

Hi,

ARISTOS wrote:

Brendan wrote:If you chose to use IO APIC and old PIT chip's IRQ isn't connected to the IO APIC; don't use the old PIT chip (e.g. use the RTC and/or the local APIC timer and/or HPET instead).

If HPET isn't present and PIT isn't connected to IOAPIC?

If HPET isn't present just use the local APIC timer.

If HPET isn't present and there's also no local APIC timer (old single CPU systems) then it's likely that there's no IO APIC either.

Typically when a (well designed) OS boots it figures out what time sources are present/usable and chooses which to use for what. There are about 5 different time sources (PIT, RTC, ACPI timer, HPET, TSC, local APIC timer) all with varying capabilities and characteristics; and there are multiple possible uses (keeping track of "wall clock time", generating timestamps for file systems, "sleep()" and "nanodelay()", networking time-outs, power management, etc). You can do everything with a single timer (e.g. local APIC timer) if there's no other choices (and a lot of OSs do this anyway - e.g. local APIC timer for everything, with HPET as a fall-back when all CPUs are put into a deep sleep state - simply because the local APIC timer is superior to everything else).

ARISTOS wrote:

Brendan wrote:If you chose to use IO APIC then you do not use PIC chips for anything at all (and leave them disabled/masked)

And why I cannot use IOAPIC and PIC at the same time?

In theory this is (was?) technically possible; but it's not supported by ACPI and if it was it still wouldn't be worth the hassle.

ARISTOS wrote:

Brendan wrote:The MP specification is an old standard that existed before ACPI; that was superseded by ACPI. In general you should search for ACPI tables and use ACPI if it exists, but if there are no ACPI tables (because the computer is too old) then you'd search for MP specification tables and use those instead. If you don't support old computers (e.g. 15 years old, or older) then there's no need to support MP specification's tables.

How often a modern computer does not support ACPI?

Up until about 1996 nothing supported ACPI; then from about 1997 to 2001 computers started supporting ACPI but often it was very buggy (and possibly better to ignore ACPI in case); then from about 2002 until now every normal (80x86 PC) computer has ACPI.

Note that there have been a few abnormal/non-standard "computers"; including Intel's Xeon Phi coprocessor cards and possibly some of Intel's embedded stuff (their smartphone experiments, and things like Quark). It's likely that you won't need to care about these.

ARISTOS wrote:

Brendan wrote:The code for the second part is stored as byte-code (called AML or ACPI Machine Language) and you need an "AML interpreter" to execute/interpret that code.

Can you tell me an example of how AML works? The AML interpreter is interpreting the code and then? Do this code changes at runtime?
Can I build an AML interpreter, if yes where can I found reference?

The AML code doesn't change at runtime, but variables that effect its behaviour do.

It's a bad idea to write your own AML interpreter; and most people use ACPICA instead (see the wiki page). Part of the problem (beyond the obvious stuff) is that you have to tell AML which OS you are; and if you don't lie the firmware won't recognise your OS and will disable lots of features, and if you do lie and say that you are Windows you have to behave exactly the same as that version of Windows does.

The other part of the problem is that there's mostly 2 modes - "legacy mode" (intended for old OSs that don't support ACPI) where the firmware handles power management (mostly using SMM/System Management Mode); and "ACPI mode" where the OS (and AML) handles power management (including temperature sensors, fan speeds, clock throttling, etc) where (in theory) you can damage/overheat the computer if there's a bug in the way your OS uses/interprets AML.


Cheers,

Brendan

Brendan wrote:If HPET isn't present just use the local APIC timer.

If HPET isn't present and there's also no local APIC timer (old single CPU systems) then it's likely that there's no IO APIC either.

Typically when a (well designed) OS boots it figures out what time sources are present/usable and chooses which to use for what. There are about 5 different time sources (PIT, RTC, ACPI timer, HPET, TSC, local APIC timer) all with varying capabilities and characteristics; and there are multiple possible uses (keeping track of "wall clock time", generating timestamps for file systems, "sleep()" and "nanodelay()", networking time-outs, power management, etc). You can do everything with a single timer (e.g. local APIC timer) if there's no other choices (and a lot of OSs do this anyway - e.g. local APIC timer for everything, with HPET as a fall-back when all CPUs are put into a deep sleep state - simply because the local APIC timer is superior to everything else).

LAPIC doesn't have the same frequency (from computer to computer) so how can I set (for example) a 1 second delay? I am thinking to use the PIT and get his initial value from using IO instructions and set LAPIC timer with that.

Brendan wrote:

ARISTOS wrote:

Brendan wrote:The code for the second part is stored as byte-code (called AML or ACPI Machine Language) and you need an "AML interpreter" to execute/interpret that code.

Can you tell me an example of how AML works? The AML interpreter is interpreting the code and then? Do this code changes at runtime?
Can I build an AML interpreter, if yes where can I found reference?

The AML code doesn't change at runtime, but variables that effect its behaviour do.

I still cannot understand how the AML mechanism works.

Brendan wrote:It's a bad idea to write your own AML interpreter; and most people use ACPICA instead (see the wiki page). Part of the problem (beyond the obvious stuff) is that you have to tell AML which OS you are; and if you don't lie the firmware won't recognise your OS and will disable lots of features, and if you do lie and say that you are Windows you have to behave exactly the same as that version of Windows does.

What, why?

ARISTOS wrote:

Brendan wrote:It's a bad idea to write your own AML interpreter; and most people use ACPICA instead (see the wiki page). Part of the problem (beyond the obvious stuff) is that you have to tell AML which OS you are; and if you don't lie the firmware won't recognise your OS and will disable lots of features, and if you do lie and say that you are Windows you have to behave exactly the same as that version of Windows does.

What, why?

Because most hardware manufacturers care about only one thing: it has to work for windows. As windows certification has some extra requirements they typically work towards those as well, even if not strictly needed to run windows, but they typically don't go much beyond that.

I still cannot understand how the AML mechanism works.

HW manufacturer puts inside of their boards AML byte code, and your OS has an engine for its execution. Like Java, C# bytecode/interpreter pairs. It was meant to be a portable way of configuring HW independent from the CPU architecture. Such a noble idea. But for this they invented another abstract CPU, your OS should emulate.
I believe, there was no need to introduce this VM for this goal. Thoughtfully designed data structures for HW description would be more than enough. No need to introduce encoding for "actions".

davidv1992 wrote:Because most hardware manufacturers care about only one thing: it has to work for windows. As windows certification has some extra requirements they typically work towards those as well, even if not strictly needed to run windows, but they typically don't go much beyond that.

So how Linux and Mac work? They are modern and popular OS's.

zaval wrote:HW manufacturer puts inside of their boards AML byte code, and your OS has an engine for its execution. Like Java, C# bytecode/interpreter pairs. It was meant to be a portable way of configuring HW independent from the CPU architecture. Such a noble idea. But for this they invented another abstract CPU, your OS should emulate.
I believe, there was no need to introduce this VM for this goal. Thoughtfully designed data structures for HW description would be more than enough. No need to introduce encoding for "actions".

OK let's say that I found the ALM code what is the next steps, what does the code says? How I am sending mesages? (for example to put the computer to "soft off")

Brendan wrote:The MP specification is an old standard that existed before ACPI; that was superseded by ACPI. In general you should search for ACPI tables and use ACPI if it exists, but if there are no ACPI tables (because the computer is too old) then you'd search for MP specification tables and use those instead. If you don't support old computers (e.g. 15 years old, or older) then there's no need to support MP specification's tables.

Can I use MP specification instead of ACPI? What features I am losing?

Brendan wrote:If HPET isn't present and there's also no local APIC timer (old single CPU systems) then it's likely that there's no IO APIC either.

So on a MP system IO APIC and LAPIC are always present, aren't they?
All LAPIC's have a timer, haven't they?
So on a MP system I will use LAPIC timer and IOAPIC for interrupt handling and on a monocore system PIT or HPET (if present) for timing and PIC's for interrupt handling.
What Windows are doing on multicore and monocore systems (for timing)?

ARISTOS wrote:

davidv1992 wrote:Because most hardware manufacturers care about only one thing: it has to work for windows. As windows certification has some extra requirements they typically work towards those as well, even if not strictly needed to run windows, but they typically don't go much beyond that.

So how Linux and Mac work? They are modern and popular OS's.

OS X works through apple making sure their hardware/firmware provides enough to support it. As for linux, hardware tends to be a bit hit-or-miss, especially the more modern stuff. I have heard of cases where people had to actually replace the ACPI tables in their system at boot to get things to even work. Personally, I never went that far, though the laptop I am currently writing this on doesn't exactly play nice with power saving features under linux (entering/waking up from some of the low power states is a bit iffy).

Hi,

ARISTOS wrote:

Brendan wrote:The MP specification is an old standard that existed before ACPI; that was superseded by ACPI. In general you should search for ACPI tables and use ACPI if it exists, but if there are no ACPI tables (because the computer is too old) then you'd search for MP specification tables and use those instead. If you don't support old computers (e.g. 15 years old, or older) then there's no need to support MP specification's tables.

Can I use MP specification instead of ACPI? What features I am losing?

Originally there was the MP specification, the Advanced Power Management (APM) specification, and a few other smaller specifications (e.g. PCI IRQ routing table specification). ACPI was designed to replace all of these specifications with a single specification that covered everything. Then, as new features were added to 80x8 ACPI grew to include them too; and now ACPI also includes things like HPET, NUMA, error reporting, hot-plug RAM, etc.

Eventually, some firmware manufacturers stopped bothering with the MultiProcessor specification's tables. For some computers you'll just find a "bare minimum" MP specification table that only mentions one CPU and nothing else. For some computers you won't find an MP specification table at all.

If you don't use ACPI, and use the MP specification and APM specification instead; then how much you lose depends on how old the computer is. For computers from 15+ years ago you'd lose almost nothing. For computers from 2017 you lose almost everything.

Mostly; if you support old computers (from 15+ years ago) you have to support MP specification, and if you support newer computers you have to support ACPI. The only other choices are to have a featureless OS (e.g. that can only use one CPU, that has no power management, that doesn't support newer hardware like HPET, etc); or to write a motherboard driver for every motherboard.

ARISTOS wrote:

Brendan wrote:If HPET isn't present and there's also no local APIC timer (old single CPU systems) then it's likely that there's no IO APIC either.

So on a MP system IO APIC and LAPIC are always present, aren't they?

Yes.

ARISTOS wrote:All LAPIC's have a timer, haven't they?

Yes.

ARISTOS wrote:So on a MP system I will use LAPIC timer and IOAPIC for interrupt handling and on a monocore system PIT or HPET (if present) for timing and PIC's for interrupt handling.

There are single CPU systems that have IO APIC and local APIC; and in this case you'd want to use them (especially if you have support for them anyway, for mutli-CPU computers), because IO APIC is better than PIC (faster to access, more inputs, less PCI IRQ sharing) and because local APIC's timer is better than PIT (faster to access, much higher precision).

The full list of "common cases" might be:

• Old single-CPU, without local APIC, without IO APIC (and likely without HPET)
• Less old single-CPU, with local APIC, but without IO APIC (and probably without HPET)
• Even less old single-CPU, with local APIC, with IO APIC (and possibly with HPET)
• Old multi-CPU, with local APIC, with IO APIC, but without HPET
• Modern multi-CPU, with local APIC, with IO APIC, and with HPET

Also note that for modern computers some of the legacy stuff may not exist, and some might be emulated (by firmware using SMM). This includes PS/2 (emulated by USB maybe), PIT (emulated by HPET maybe), the PIC chips (which might not exist at all); and things like the floppy controller, serial ports and parallel ports (which all might not exist at all).

ARISTOS wrote:What Windows are doing on multicore and monocore systems (for timing)?

For timing; it's a complex subject (and should probably be a completely separate topic/post). Don't forget that there are multiple different things that an OS uses time for - e.g. keeping track of "wall clock time" (where you want accuracy more than you want precision, and really want multiple layers to get the highest possible accuracy - e.g. NTP keeping RTC synchronised, then RTC keeping something more precise synchronised); quickly obtaining the current "wall clock time" (for things like file system time stamps) where you don't need an IRQ at all; measuring elapsed time (for calculating CPU load, keeping track of "total CPU time consumed by each thread (in nanosecond)"; etc. All of these things have different requirements - some need accuracy and some don't, some need precision and some don't, some need an IRQ and some don't, etc. One specific time source (e.g. the CPU's TSC/Time Stamp Counter") might be excellent for some things (e.g. precise measurements of elapsed time) and completely useless for other things (e.g. anything that needs an IRQ).

You mostly need to determine which time sources are present/usable, then try to use "time source characteristics" to determine which (present/usable) time source is the best match for each of the very different purposes. There's no simple "if X is supported, always use X for everything" solution.


Cheers,

Brendan

ARISTOS wrote: OK let's say that I found the ALM code what is the next steps, what does the code says? How I am sending mesages? (for example to put the computer to "soft off")

Not messages. There are "control methods" for doing things like you mentioned. Your interpreter finds needed methods in defined places inside of the ACPI namespace, and executes a sequence of AML instructions, that constitute the method. Execution of those instructions results in writing to HW registers, that causes the action to have been taken. Please read section 5.5 of the spec (6.1) (Control Method execution and the ACPI Source Language (ASL)), and particularly section 5.5.2 (Control Method Execution), where your question is answered.