By now I support all things discussed in this topic:
http://www.osdev.org/phpBB2/viewtopic.php?t=13113
How much people supports ACPI at least partially and using real mode interrupts (INT 15h?) to at least shut down and turn off the PC?
Another question is that, am I right with believing that ACPI is just a "language" interface to perform things like turn off the disks, the screen, the PC, and other things, that could otherwise be performed sending commands and/or values to standard (or nonstandard) peripheral ports?
ACPI Support
ACPI commands are sent to a compatable BIOS in a interpreted language yes. Obviously this means there has to be a way for the BIOS todo the actual communication to devices, through chipset determined ports etc. Though it is beyond impossible for you to support these ports and chipsets, so i advise using ACPI.
Hi,
Everything that ACPI does could be done by a "motherboard specific" code (not necessarily just "chipset specific" code, as different motherboards may use the same chipset in different ways) that uses I/O ports, PCI configuration space, etc.
ACPI doesn't just do power management though (e.g. setting different power modes), which includes thermal management and noise management (temperature sensors, fan control, etc). It also handles the "off" button, the "sleep" button (if any), and case switches (used to detect if the case is off in some systems that depend on the case being on for proper cooling).
In addition it's used for configuration (the 'C' in "ACPI"). This includes motherboard resources (e.g. programmable PCI IRQ routing, which I/O ports are reserved by the chipset, which I/O ports are used by things like serial ports, parallel ports, floppy controller, PIT, DMA, etc), CPU & APIC detection, NUMA domain detection, hot plug device insertion/removal (for PCI, RAM, CPUs), and other things.
For the "run-time" part of ACPI, the BIOS gives the OS some AML code (ACPI Machine Language) which is byte code for an OOP language. The OS calls routines contained in this AML code.
The ACPI standard does say something about interpretting this code (e.g. like a Java virtual machine), but this isn't the only way. One of the things I'd like to do is have a compiler convert this AML code into native assembly source code, and then combine it with some framework code so that when it's assembled you get a "chipset device driver" for my OS (that is saved to disk and loaded like any other driver after that). This would also allow the source code to be modified (so that the "chipset driver" can be improved), and would allow me to have a large number of pre-compiled binaries that people could download/use. Of course I'm not too sure how practical this approach is yet...
Cheers,
Brendan
I parse ACPI tables during boot, and intend to eventually support the "run-time" part of ACPI (but don't yet, and won't for a very long time).~ wrote:How much people supports ACPI at least partially and using real mode interrupts (INT 15h?) to at least shut down and turn off the PC?
Yes and no...~ wrote:Another question is that, am I right with believing that ACPI is just a "language" interface to perform things like turn off the disks, the screen, the PC, and other things, that could otherwise be performed sending commands and/or values to standard (or nonstandard) peripheral ports?
Everything that ACPI does could be done by a "motherboard specific" code (not necessarily just "chipset specific" code, as different motherboards may use the same chipset in different ways) that uses I/O ports, PCI configuration space, etc.
ACPI doesn't just do power management though (e.g. setting different power modes), which includes thermal management and noise management (temperature sensors, fan control, etc). It also handles the "off" button, the "sleep" button (if any), and case switches (used to detect if the case is off in some systems that depend on the case being on for proper cooling).
In addition it's used for configuration (the 'C' in "ACPI"). This includes motherboard resources (e.g. programmable PCI IRQ routing, which I/O ports are reserved by the chipset, which I/O ports are used by things like serial ports, parallel ports, floppy controller, PIT, DMA, etc), CPU & APIC detection, NUMA domain detection, hot plug device insertion/removal (for PCI, RAM, CPUs), and other things.
For the "run-time" part of ACPI, the BIOS gives the OS some AML code (ACPI Machine Language) which is byte code for an OOP language. The OS calls routines contained in this AML code.
The ACPI standard does say something about interpretting this code (e.g. like a Java virtual machine), but this isn't the only way. One of the things I'd like to do is have a compiler convert this AML code into native assembly source code, and then combine it with some framework code so that when it's assembled you get a "chipset device driver" for my OS (that is saved to disk and loaded like any other driver after that). This would also allow the source code to be modified (so that the "chipset driver" can be improved), and would allow me to have a large number of pre-compiled binaries that people could download/use. Of course I'm not too sure how practical this approach is yet...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
Masterkiller
- Member
- Posts: 153
- Joined: Sat May 05, 2007 6:20 pm
I post my question here, because it is directly realted to the ACPI so 1 topic less 
I am interesting how to detect motherboard devices at boot using ACPI tables. I have read specification, but I continue misunderstanding something... I do following:
I am interesting how to detect motherboard devices at boot using ACPI tables. I have read specification, but I continue misunderstanding something... I do following:
- Find the RDS PTR and calculate the checksum;
- From the pointer from RDS PTR find the Root System Descrtion Table, calculate the checksum, for each entry go to specific function to evaluate the table;
- On bochs I got two entries: FACP and APIC, I suppose Fixed ACPI Description Table always exist;
- From FACP get the pointer to DSDT and calculate the checksum;
Hi,
To make it worse, your OS may also need to understand how Microsoft understands the ACPI Machine Language. This is because the AML can do the equivelent of "if OS_type == WindowsNT then <foo> else <bar>".
There's also borked motherboards which have craptastic AML code. This means that if you do everything perfectly it might not work anyway because of bugs (and/or missing features) in the BIOS's AML. There's different ways to get around this. AFAIK Linux has a blacklist and a whitelist (and if the motherboard isn't in either list Linux won't use ACPI if the BIOS is made before the year 2000) and there's a "ACPI = on | off" style kernel parameter to override all this. FreeBSD (and probably other BSDs) go further and allow the end-user to provide their own AML code to replace the BIOS's AML code.
Cheers,
Brendan
Yes, your OS must understand the ACPI Machine Language. The AML code contains the namespace, where each name in the namespace is like a function name.Masterkiller wrote:The question is what next? Where is ACPI Namespace where all the devices are described hierchary. If it is in the definition block provided by DSDT and if so, do my OS must understand ACPI Machine Language?
To make it worse, your OS may also need to understand how Microsoft understands the ACPI Machine Language. This is because the AML can do the equivelent of "if OS_type == WindowsNT then <foo> else <bar>".
There's also borked motherboards which have craptastic AML code. This means that if you do everything perfectly it might not work anyway because of bugs (and/or missing features) in the BIOS's AML. There's different ways to get around this. AFAIK Linux has a blacklist and a whitelist (and if the motherboard isn't in either list Linux won't use ACPI if the BIOS is made before the year 2000) and there's a "ACPI = on | off" style kernel parameter to override all this. FreeBSD (and probably other BSDs) go further and allow the end-user to provide their own AML code to replace the BIOS's AML code.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.