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 
> To: [e-mail]
> 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  wrote:
> > Date: Mon, 27 Oct 2003 00:10:32 -0800 (PST)
> > From: Bharata B Rao 
> > Subject: ACPI support in LinuxBIOS
> > To: [e-mail]
> >
> > 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
> [e-mail]
> http://www.clustermatic.org/mailman/listinfo/linuxbios

Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

[ron minnich]

it's on the list, waiting for somebody to take a stab at it.

ron

Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

[Stefan Reinauer]

* [e-mail]  [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

Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

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:
> [e-mail]  [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

Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

[Stefan Reinauer]

* [e-mail]  [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

Fwd: ACPI support in LinuxBIOS - moderator approval (fwd)

[e-mail] 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