Re: Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)
I'll raise the question to the next level.... Has there been any discussion of putting any power management support into the LinuxBIOS. I've got a possible need for some basics, like suspend to RAM. Classic APM might be enough and simple to implement. ACPI would be a good choice, but I'm not sure about how much ROM foot print would be needed. Jordan At 07:42 AM 11/26/2003 -0700, ron minnich wrote:
---------- Forwarded message ---------- Date: Tue, 25 Nov 2003 23:18:53 -0800 (PST) From: Bharata B Rao <bharata_rao@yahoo.com> To: rminnich@lanl.gov Subject: Fwd: ACPI support in LinuxBIOS - moderator approval
Hello Ron,
Sorry for this unsolicited mail, but I am tempted to request you to get me this moderator approval so that this mail (see forwarded note) makes it to the list. This mail of mine has been sitting with the moderator for many days.
I am assuming that you are the moderator, if not excuse me.
Regards, Bharata.
--- Bharata B Rao <bharata_rao@yahoo.com> wrote:
Date: Mon, 27 Oct 2003 00:10:32 -0800 (PST) From: Bharata B Rao <bharata_rao@yahoo.com> Subject: ACPI support in LinuxBIOS To: linuxbios@clustermatic.org
Hello,
I see from the archives that there was some talk about extracting ACPI tables from BIOS and implementing ACPI support in LinuxBIOS.
I would like to know, if there have been any attempts in this regard from anyone ?
Do you feel that this idea is still feasible ? Or should I assume that this is a dead idea as I see no mention about ACPI power management here since last year ?
Kindly CC your replies. Thanks for your time.
Regards, Bharata.
__________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
__________________________________ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
it's on the list, waiting for somebody to take a stab at it. ron
* jarcher@pobox.com <jarcher@pobox.com> [031126 16:32]:
I'll raise the question to the next level....
Has there been any discussion of putting any power management support into the LinuxBIOS. I've got a possible need for some basics, like suspend to RAM. Classic APM might be enough and simple to implement. ACPI would be a good choice, but I'm not sure about how much ROM foot print would be needed.
Since ACPI is, similar to FCode, an interface based on abstracted binary code, it would probably be easier to add ACPI support to LinuxBIOS than supporting APM which needs code hooks. The ACPI tables could be a) generated by or b) stored in LinuxBIOS as is and will be found and interpreted by the Linux Kernel. But besides the technical issues there's also a legal question when including ACPI tables (some are patented by MS and not freely usable iirc, others might be copyrighted by Awkward & Co.) There are also kernel patches for Linux that allow attaching some of the ACPI tables to an initial ramdisk. This can be used to override broken bios ACPI tables with corrected ones without reflashing the bios. Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development
I mentioned APM because it seemed the simplest. Realisticaly you'd want to follow the LinuxBIOS approach and do minimal stuff at the BIOS level and move most of the information to a linux driver. So really all the BIOS portion has to detect and support are the conditions where the CPU goes through reset. This should only be the suspend to ram and the suspend to disk states. So how about a new simple LinuxBIOS PM interface? Jordan At 05:18 PM 11/26/2003 +0100, Stefan Reinauer wrote:
* jarcher@pobox.com <jarcher@pobox.com> [031126 16:32]:
I'll raise the question to the next level....
Has there been any discussion of putting any power management support into the LinuxBIOS. I've got a possible need for some basics, like suspend to RAM. Classic APM might be enough and simple to implement. ACPI would be a good choice, but I'm not sure about how much ROM foot print would be needed.
Since ACPI is, similar to FCode, an interface based on abstracted binary code, it would probably be easier to add ACPI support to LinuxBIOS than supporting APM which needs code hooks.
The ACPI tables could be a) generated by or b) stored in LinuxBIOS as is and will be found and interpreted by the Linux Kernel. But besides the technical issues there's also a legal question when including ACPI tables (some are patented by MS and not freely usable iirc, others might be copyrighted by Awkward & Co.) There are also kernel patches for Linux that allow attaching some of the ACPI tables to an initial ramdisk. This can be used to override broken bios ACPI tables with corrected ones without reflashing the bios.
Stefan
-- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development
* jarcher@pobox.com <jarcher@pobox.com> [031126 17:43]:
I mentioned APM because it seemed the simplest. Realisticaly you'd want to follow the LinuxBIOS approach and do minimal stuff at the BIOS level and move most of the information to a linux driver. So really all the BIOS portion has to detect and support are the conditions where the CPU goes through reset. This should only be the suspend to ram and the suspend to disk states.
So how about a new simple LinuxBIOS PM interface?
Some information, like power management code, is fitting pretty well in the firmware imo. Before inventing yet another interface I strongly recommend to look at the existing ones and sort them out if they do not work for some or another reason. ACPI may be ugly, but there's a big chance to support a whole lot of hardware at once by supporting ACPI table generation in LinuxBIOS. Otoh, creating an own table/format that can be parsed by a Linux driver will basically do the same thing in yet another implementation. Result is many people sit and parse ACPI tables to create LinuxBIOS tables (or even convert it automatically) The cleanest way would be to create FCode drivers for such components and use them in an Open Firmware environment - an OS can then decide to call methods provided by each hardware device in the device tree. Suspend to disk can be done in software (see swsusp for linux) - I guess suspend to ram involves a lot more system management mode (SMM) programming Stefan -- Stefan Reinauer, SUSE LINUX AG Teamleader Architecture Development
jarcher@pobox.com writes:
I mentioned APM because it seemed the simplest. Realisticaly you'd want to follow the LinuxBIOS approach and do minimal stuff at the BIOS level and move most of the information to a linux driver. So really all the BIOS portion has to detect and support are the conditions where the CPU goes through reset. This should only be the suspend to ram and the suspend to disk states.
So how about a new simple LinuxBIOS PM interface?
There are several pieces to this. 1) Telling operating systems what part it needs to play. 2) Switching to the suspend to RAM state. 3) Knowing in the BIOS we need to come out of suspend to RAM instead of doing a fresh initialization of the memory controller. Thinking about Suspend to RAM I have some strange thoughts about setting up hypertransport correctly. I am wondering if a suspend to RAM would be faster than a hard_reset? Anyway... On the LinuxBIOS side the communication can pretty much be accomplished with a CMOS parameter I think. As far as giving information to the running OS giving it the tables it expects is not the worst way to go. Most of the power management needs to happen in the OS and in the drivers. Ideally we would package the ACPI table entries in the LinuxBIOS table as real tabular data (not functions) and then convert them to real ACPI later. The OS needs a little bit of help to do suspend to RAM but we should keep it as minimal as possible. Eric
participants (4)
-
ebiederman＠lnxi.com -
jarcher＠pobox.com -
ron minnich -
Stefan Reinauer