OSDev.org

Cheers Brendan.

Yeah, I'll definitely leave ACPI disabled even if I choose to keep this solution - which mostly achieves the desired result, or something close to it.

So is there a recommended way for a hobby OS to do a power off using another method? Implement the whole bleeding ACPI mess? Just forget about it?

Andy

There is a "portable," OS-independent implementation of ACPI known as ACPICA. However I am not sure of the licensing, I know it is compatible with GPL but not everybody (including me) prefers that license. I think there are some solutions for commercial OSes, but I'm not sure about non-GPL compatible licenses.

Other than ACPI I know of no other way to perform a shutdown, except maybe APM which is old and I know next-to-nothing about. You could check the source code for a kernel which implements ACPI or some other code, like GNU GRUB, whose halt command I noticed shuts down the PC.

berkus wrote:acpica can help to an extent.

Sure. If you're able to implement the tons of function in the os layer. It took me a while to make it run... However it's worth a try

IIRC acpica was under a custom intel license, which at reading seemed like a bsd compatible.

Tosi wrote:
You could check the source code for a kernel which implements ACPI or some other code, like GNU GRUB, whose halt command I noticed shuts down the PC.

GRUB's halt instruction involves APM and that to connected via the Protected Mode Interface.
Again, though the "wiki" says APM is old, I've seen lots of newer systems that supports APM along with the ACPI. So, you might consider implementing it.

Yeah, I didn't know if GRUB used APCI or not. It might be fine to use APM for shutdown, because although it requires being in real mode (to use the BIOS), if you're shutting down you don't have to worry about getting back to protected mode or protecting certain memory locations.

Good tips guys, thanks. I wondered whether it might be possible using either 16- or 32-bit BIOS functions. I've got 32-bit BIOS detection, but so far I hadn't found a good enough reason to implement the calling interface. If it supports poweroff that might be reason enough.

andymc wrote:Good tips guys, thanks. I wondered whether it might be possible using either 16- or 32-bit BIOS functions. I've got 32-bit BIOS detection, but so far I hadn't found a good enough reason to implement the calling interface. If it supports poweroff that might be reason enough.

Well as Tosi pointed out, you can switch to Real Mode to shutdown the PC. Afterall, you are not going to return to Protected Mode anyway. This doesn't mean that you cannot implement the Protected Mode Interface. It rather saves you from whole lot of hassles. I'm yet to come out with the Protected Mode APM implementation.

Chandra wrote:

Tosi wrote:
You could check the source code for a kernel which implements ACPI or some other code, like GNU GRUB, whose halt command I noticed shuts down the PC.

GRUB's halt instruction involves APM and that to connected via the Protected Mode Interface.
Again, though the "wiki" says APM is old, I've seen lots of newer systems that supports APM along with the ACPI. So, you might consider implementing it.

Chandra, i am a newbie in this forum and i need some help...
About the sample code posted by kaworu, can i compile that code as a kernel module ? And what about the headers in the sample code - are they standard ones ?
Thanks in advance,
Raphael.

ps: i´m not a hobby-O.S developer (at least yet ), but i need the code to turn off computer to simulate a power fail.

A lot of newer systems, especially laptops, lack any APM support at all.. don't bother with it.

In general if you want to implement ACPI you're probably best off going with ACPICA. It's tested and updated frequently enough to be depended on, and it's designed to be integrated into either user space or a kernel quite easily. There's a quite a few prerequisites, but only because they're absolutely required by ACPI to function properly. A lot of the OS dependent functions can be turned off or handled internally as well (Mutexes, memory caches, etc).

Generally if you're to the point where you're looking at implementing ACPI most of what it needs should be easy enough to implement, or already implemented. In general you'll want to have support for several devices before approaching ACPICA including: PIC, PIT, Local APIC (mainly for the timer), IOAPIC, possibly HPET support, and PCI Bus support. You'll need proper logical and physical memory management as well as dynamic memory allocation. A lot of the initialization code for these devices should eventually tie in with ACPI initialization code through early table access as well. You'll pretty much need ACPI down the line to support all the devices and features most modern PCs have though, still it should regarded as something to be approached after you have a fairly mature kernel. It's far from impossible to do, but it's definitely not the first thing you want to approach when building a kernel.

Hi,

agpcraphael wrote:ps: i´m not a hobby-O.S developer (at least yet ), but i need the code to turn off computer to simulate a power fail.

agpcraphael wrote:About the sample code posted by kaworu, can i compile that code as a kernel module ?

If you're not an OS developer (yet), then which kernel are you talking about?

Most existing kernels (e.g. freeBSD, Linux, etc) already support ACPI and have existing services for power management. In this case you want to use the kernel's existing support if you can, rather than trying to bypass it and implement your own code that will conflict with the existing code.

Another alternative might be to use a UPS to interrupt power. Most UPSs use some sort of (serial or USB) connection for both status and control (including telling the UPS to turn power on/off). If the UPS's (serial or USB) connection is connected to one computer then it could be used to interrupt the power going to a different computer; and in this case you don't really need to write any software - you can just use existing UPS tools (e.g. the "upscmd" utility that is part of the NUT/"Network UPS Tools" package, or the utility for Windows that came with the UPS, or whatever). As a bonus, this would also be the most accurate way of simulating a power failure, as there's no chance for the OS or the firmware to do anything before shutdown.


Cheers,

Brendan

Brynet-Inc wrote:A lot of newer systems, especially laptops, lack any APM support at all.. don't bother with it.

agpcraphael was talking about kaworu's code which implements ACPI and not APM.

agpcraphael wrote:i´m not a hobby-O.S developer (at least yet ), but i need the code to turn off computer to simulate a power fail.

Since you're under hosted enviroment, you host OS won't let you play with Power Management. The only exception being that you're running DOS.

If you manage to write your own OS in future, conditions will be different and complex too. As you can see, APM is old and less likely to be supported in newer PCs. Again, ACPI is a complete mess, but once you manage to keep things straight, you're done. Linux Distributions too use ACPI behind their poweroff routine.

About the sample code posted by kaworu, can i compile that code as a kernel module ? And what about the headers in the sample code - are they standard ones ?

I'm not sure what modules are you talking about. Are you running linux?
If you are writing your own OS, you can compile that code and run (as a module, if your OS supports it). The headers in that sample code are standard as well. But as Brendan said, that particular code can break under lots of situations. Nevertheless, I've seen that code running successfully under lots of PCs. Give it a try!

Cheers.

Cognition wrote:In general if you want to implement ACPI you're probably best off going with ACPICA. It's tested and updated frequently enough to be depended on, and it's designed to be integrated into either user space or a kernel quite easily. There's a quite a few prerequisites, but only because they're absolutely required by ACPI to function properly. A lot of the OS dependent functions can be turned off or handled internally as well (Mutexes, memory caches, etc).

Generally if you're to the point where you're looking at implementing ACPI most of what it needs should be easy enough to implement, or already implemented. In general you'll want to have support for several devices before approaching ACPICA including: PIC, PIT, Local APIC (mainly for the timer), IOAPIC, possibly HPET support, and PCI Bus support. You'll need proper logical and physical memory management as well as dynamic memory allocation. A lot of the initialization code for these devices should eventually tie in with ACPI initialization code through early table access as well. You'll pretty much need ACPI down the line to support all the devices and features most modern PCs have though, still it should regarded as something to be approached after you have a fairly mature kernel. It's far from impossible to do, but it's definitely not the first thing you want to approach when building a kernel.

You forgot one thing that is required. It also requires support for C, and (almost) a flat-memory model in kernel in order to use the package unmodified. But I think an ACPI-driver is necesary in order for a mature OS to take advantage of modern hardware, so I'm working on providing the C-compatible environment required. For me, this is the main obstacle. Writing the required OS dependent interface would be quite easy.

Chandra wrote:

Brynet-Inc wrote:A lot of newer systems, especially laptops, lack any APM support at all.. don't bother with it.

agpcraphael was talking about kaworu's code which implements ACPI and not APM.

My post was in response to you, not agpcraphael.

Hello , I've tried to use this code but it causes a Page Fault (Present Memory) , my Kernel is in the Higher Half..any idea what could be causing this?