search

SerenityOS / serenity

The Serenity Operating System 🐞
https://serenityos.org
BSD 2-Clause "Simplified" License
30.37k stars 3.18k forks source link

ACPI support in Kernel #403

Closed supercomputer7 closed 4 years ago

supercomputer7 commented 5 years ago

Just looked at the code of the kernel, and I wondered if implementation of ACPI support is planned. If there is ACPI support, one can use the APIC (Advanced Programmable Interrupt Controller) for PCI IRQ routing instead of the older PIC, which enables using more than one processor in the future.

Such support brings features like better hardware detection (e.g. using MCFG table for PCI express instead of the older mechanism that involves IO ports), easy "native" reboot & shutdown functions and more.

So, implementation for such support can be delivered with one of the 2 methods below:

  1. Using ACPICA for AML interpretation and parsing static tables
  2. Writing parser for static tables (which is the easy part), then writing AML interpreter (with C++ it's more easy I presume, but still not very easy to write).

This is just a suggestion, I really think that this project has a tremendous potential.

Quaker762 commented 5 years ago

Hi,

I've been reading through the ACPI spec the past couple of days. It's going to be a pretty big job though, because a lot of the backend kernel stuff will need to be modified. I'll try and get a branch open in the next week or so and start implementing stuff, but it'd be a very big WiP for a while.

supercomputer7 commented 5 years ago

I also read the ACPI spec... and the ACPICA pdf (but didn't finish). We can try to use ACPICA or write something else. ACPI Reboot is pretty easy to implement, but ACPI shutdown requires an AML interpreter. PCI IRQ routing needs an AML interpreter. PCI express detection does not need one. In overall - It is indeed a big development process but once it's finished many useful features will be available.

supercomputer7 commented 5 years ago

Hi,

I've been reading through the ACPI spec the past couple of days. It's going to be a pretty big job though, because a lot of the backend kernel stuff will need to be modified. I'll try and get a branch open in the next week or so and start implementing stuff, but it'd be a very big WiP for a while.

In addition to what I wrote in above comment, I think that it is a good idea to support ACPI reboot first. I searched for ACPI related topics and found that: https://github.com/SerenityOS/serenity/pull/334

I built for my own bootloader a function to reboot the system via ACPI: https://github.com/supercomputer7/nahmanboot/blob/master/bootloader/src/drivers/acpi/powermodes.c Nothing really "smart", just finding FADT table, check the revision of the table, validate ACPI reboot support (with the flags field of the FADT), then using the ResetReg and ResetValue to reboot the machine. To do this in SerenityOS we need direct access to ACPI region in physical memory.

Such support is really bare minimum in my opinion. This will allow us to gather at least the RSDP which will be delivered to ACPICA (if we go that approach), or will be used to find DSDT and parse AML with an independent AML interpreter.

Quaker762 commented 5 years ago

In addition to what I wrote in above comment, I think that it is a good idea to support ACPI reboot first. I searched for ACPI related topics and found that:

334

Hahaha yeah, that was just a really dirty hack to try and get something working for reboot. It practically just triple faults the CPU. The "classic" reboot strategy.

Nothing really "smart", just finding FADT table, check the revision of the table, validate ACPI reboot support (with the flags field of the FADT), then using the ResetReg and ResetValue to reboot the machine. To do this in SerenityOS we need direct access to ACPI region in physical memory.

Such support is really bare minimum in my opinion. This will allow us to gather at least the RSDP which will be delivered to ACPICA (if we go that approach), or will be used to find DSDT and parse AML with an independent AML interpreter.

I'll have to go over some of the terminology/the spec again to familiarize myself with some of the ACPI stuff, but I should be able to have at least ACPI initialization/detection working pretty quickly (as well as mapping the ACPI region). Feel free to open a PR for it yourself if you feel you've got a pretty good handle on this stuff already (which it seems like you do). :)

awesomekling commented 5 years ago

We should try to build our own thing and not lift in external dependencies if possible. :) This sounds like the kind of thing where we can add support for what we need as we go.

supercomputer7 commented 5 years ago

In addition to what I wrote in above comment, I think that it is a good idea to support ACPI reboot first. I searched for ACPI related topics and found that:

334

Hahaha yeah, that was just a really dirty hack to try and get something working for reboot. It practically just triple faults the CPU. The "classic" reboot strategy.

Nothing really "smart", just finding FADT table, check the revision of the table, validate ACPI reboot support (with the flags field of the FADT), then using the ResetReg and ResetValue to reboot the machine. To do this in SerenityOS we need direct access to ACPI region in physical memory. Such support is really bare minimum in my opinion. This will allow us to gather at least the RSDP which will be delivered to ACPICA (if we go that approach), or will be used to find DSDT and parse AML with an independent AML interpreter.

I'll have to go over some of the terminology/the spec again to familiarize myself with some of the ACPI stuff, but I should be able to have at least ACPI initialization/detection working pretty quickly (as well as mapping the ACPI region). Feel free to open a PR for it yourself if you feel you've got a pretty good handle on this stuff already (which it seems like you do). :)

Triple fault is an ugly hack and should be avoided. Some machines don't behave as expected (don't reboot, but only halt). We shouldn't rely either on keyboard reboot as it might depend heavily on the quality of PS2 emulation in firmware. I presume keyboard reboot will work on most machines however, still it's only a temporary solution. Next year Intel is removing BIOS (which is known also as CSM feature today) from their motherboard, and some people speculate that they will remove later some old emulated hardware like VGA, PIC, PS2, PIT, ISA DMA... See this here: https://www.reddit.com/r/osdev/comments/a24eah/intel_will_stop_producing_motherboards_with_bios/

If you need help with the ACPI spec, let me know about it. I'm not an expert, but I grasped some good amount of knowledge on the subject. Will try to find time to work on such support.

We should try to build our own thing and not lift in external dependencies if possible. :) This sounds like the kind of thing where we can add support for what we need as we go.

I didn't say that before because I wanted to let you guys choose what approach you want to go for. If you ask me (and maybe others as well), ACPICA is completely bloated. Adding things for what we need is the right way. Writing the table parser is pretty much easy. The adventurous part of ACPI is hidden in the "AML planet" (an allusion to the film Treasure Planet) :)

jcs commented 4 years ago

971

supercomputer7 commented 4 years ago

971 has been merged. Currently we can't interpret yet any AML bytecode but that's OK, we will get to this later on :)

Anyway, SerenityOS has some sort of ACPI support now, which is really nice. For now, we can close this issue :)