Is it even possible to write an OS without ACPI support?

[gusc]

This is a question I've been passing around in my head for some time.

I'm OK with ACPI until it comes to DSDT and friends with AML. I feel comfortable working with defined data structures in memory, reading them, writing them, but once it comes to some byte code blob that I have to interpret ... not fun any more. Also I don't feel that comfortable with implementations of 3rd party code, think ACPICA.

So the question is - do I go ACPICA or try to implement everything on my own using stuff provided through different interfaces (BIOS calls, CPUID, MSR, IO, PCI, etc.) without ACPI? Is it even possible to do without ACPI?

[gravaera]

Yo:

You can load ACPI-CA as a driver, since it's mostly like a self-enumerating bus that describes the chipset, combined with a power-management interface with some other miscellaneous stuff attached (IRQ-control, PCI Link routing, etc). You can sort of hide it inside of a driver and pretend it's nothing more than a multi-function device.

EDIT: To answer the main question about whether or not you can write a kernel for the IBM-PC without ACPICA: yes and no. If you want to write a good, robust kernel that actually provides access to the hardware on the machine in a decent way, then for any modern IBM-PC machine, the answer is "no". If you want to write something that boots and runs to your satisfaction, and isn't a very serious project, the answer is "yes".

--Peace out,
gravaera

[Brendan]

Hi,

So the question is - do I go ACPICA or try to implement everything on my own using stuff provided through different interfaces (BIOS calls, CPUID, MSR, IO, PCI, etc.) without ACPI? Is it even possible to do without ACPI?

As far as I can see there's 3 main options:

• Write a "legacy OS" that doesn't support power management or various other things
• Write a native motherboard driver for each different motherboard, that does what ACPI's AML would've done (and possibly more)
• Support ACPI's AML

These options aren't mutually exclusive - you can combine 2 or more of them. For example; you can have an OS that runs as a "legacy OS" if it can't find any usable motherboard driver (or if the computer is so old that it doesn't support ACPI anyway, or if it's been disabled by the user); where something like ACPICA may be used as the basis for a generic motherboard driver.

Basically:

Code: Select all

    if( (system supports ACPI ) && (ACPI not disabled by user) ) {
        if( native motherboard driver exists) {
            use native motherboard driver
        } else if( generic motherboard driver exists) {
            use generic motherboard driver
        } else {
            run as "legacy" OS
        }
    } else {
        run as "legacy" OS
    }

This is what I'm planning to do; however I'm not actually planning to write more than about 2 of the motherboard drivers myself, and I don't plan to write any generic motherboard driver or mess with ACPI or ACPICA myself at all. I simply want to make sure it's possible for other people to write native and/or generic motherboard drivers if they ever feel like doing that (and make it easier for these hypothetical people by providing things like "how to write a motherboard driver" tutorials and providing source code for any motherboard drivers I do write, and providing tools that can help them - e.g. maybe something to disassemble/view AML).

I also have this strange idea of creating a tool that auto-generates an initial template for a native motherboard driver for my OS; that creates the boiler-plate source code for the driver's API (e.g. dummy functions that return "NOT SUPPORTED" errors) with tutorial-like documentation/descriptions of what the dummy functions are meant to do; that also inserts disassembled AML as comments in the relevant places. That way someone who wants to write a native motherboard driver can click a few buttons in a wizard/helper thing, and then work through the auto-generated source code with all information they need right where they need it.


Cheers,

Brendan

[rdos]

As far as I can see there's 3 main options:

• Write a "legacy OS" that doesn't support power management or various other things
• Write a native motherboard driver for each different motherboard, that does what ACPI's AML would've done (and possibly more)
• Support ACPI's AML

Actually, no. Having ACPI support doesn't mean you have power-management support. About the only useful function of ACPI is to find IRQ mappings for PCI. In order to support power management on the CPU, you need specific drivers for specific types of CPU-families, and ACPI won't provide you with much relevant help.

[rdos]

This is a question I've been passing around in my head for some time.

I'm OK with ACPI until it comes to DSDT and friends with AML. I feel comfortable working with defined data structures in memory, reading them, writing them, but once it comes to some byte code blob that I have to interpret ... not fun any more. Also I don't feel that comfortable with implementations of 3rd party code, think ACPICA.

So the question is - do I go ACPICA or try to implement everything on my own using stuff provided through different interfaces (BIOS calls, CPUID, MSR, IO, PCI, etc.) without ACPI? Is it even possible to do without ACPI?

It is perfectly possible to make an OS without ACPI support. The only issue is that you need some efficient probing technique in order to discover how PCI IRQs are connected to your interrupt controller.

[Brendan]

Hi,

As far as I can see there's 3 main options:

• Write a "legacy OS" that doesn't support power management or various other things
• Write a native motherboard driver for each different motherboard, that does what ACPI's AML would've done (and possibly more)
• Support ACPI's AML

Actually, no. Having ACPI support doesn't mean you have power-management support. About the only useful function of ACPI is to find IRQ mappings for PCI. In order to support power management on the CPU, you need specific drivers for specific types of CPU-families, and ACPI won't provide you with much relevant help.

What you really mean is that merely porting ACPICA to your OS doesn't necessarily mean that you know how to use it correctly or what it's actually for. There's several chapters of the ACPI specification dedicated to power management. This includes an entire chapter called "8 Processor Power and Performance State Configuration and Control". See if you can guess what it's about.


Cheers,

Brendan

[gusc]

OK, so I can do most of the things without ACPI, but what about Power Management? How do you power off the computer or receive power button event without ACPI, is that possible using IRQs?

[Brendan]

Hi,

OK, so I can do most of the things without ACPI, but what about Power Management? How do you power off the computer or receive power button event without ACPI, is that possible using IRQs?

Normally both events and requests from the OS itself are handled by ACPI's AML (which is interpreted by the OS - e.g. using ACPICA or something). Everything that's possible with ACPI is also possible with code that does the same as ACPI's AML would've done.

The problem is that different computers do things in different ways; and to handle that the AML is different for different computers. This means that if you have code that does the same as ACPI's AML would've done, then that code would also need to be different for different computers (e.g. some kind of "motherboard driver" for each different motherboard).


Cheers,

Brendan

[gusc]

The problem is that different computers do things in different ways; and to handle that the AML is different for different computers. This means that if you have code that does the same as ACPI's AML would've done, then that code would also need to be different for different computers (e.g. some kind of "motherboard driver" for each different motherboard).

So, if there are two ways of communicating with hardware (memory mapped IO and legacy IO instructions), and each of those two methods can take different "control codes" (let's call them that) to perform certain power management operations, that's where everything gets "unstandardized" and complicated, and ACPI would really help out. Otherwise I'd have to write my own motherboard driver for each manufacturer and model. Am I right?

[AbstractYouShudNow]

Is it even possible to write an OS without ACPI support?

Of course it is! Operating Systems were able to do power management and shutdown themselves well before ACPI was even invented. If ACPI is just too much for you, then you can try APM (wiki article), but I've heard that some recent computers no longer had any APM support, only ACPI. However, unless you just bought your test machine, it's likely that is supports APM and AFAIK, Bochs does support it too.

[rdos]

Hi,

As far as I can see there's 3 main options:

• Write a "legacy OS" that doesn't support power management or various other things
• Write a native motherboard driver for each different motherboard, that does what ACPI's AML would've done (and possibly more)
• Support ACPI's AML

Actually, no. Having ACPI support doesn't mean you have power-management support. About the only useful function of ACPI is to find IRQ mappings for PCI. In order to support power management on the CPU, you need specific drivers for specific types of CPU-families, and ACPI won't provide you with much relevant help.

What you really mean is that merely porting ACPICA to your OS doesn't necessarily mean that you know how to use it correctly or what it's actually for. There's several chapters of the ACPI specification dedicated to power management. This includes an entire chapter called "8 Processor Power and Performance State Configuration and Control". See if you can guess what it's about.


Cheers,

Brendan

This documentation is useless when Intel doesn't support the relevant ACPI objects, and AMD needs a CPU-related power manager.