"Eric W. Biederman" wrote:
>
> One thing we also want to consider. A deep sleep mode on portable
> computers can turn off the RAM controller. If this is a sane thing to
PIIX4 manual has a number of different states:
POS - Power On Suspend - degates clock generator, may turn of clock
generator too. southbridge (TOD clock) 32khz signal remains to refresh ram
Suspend to Ram... same, but also powers off cpu.
suspend to disk... turn off ram too, only small part of PIIX4 stays on
and monitors for wakeup events, remembers state (ie i'm not off
i'm suspended)
>
> do this needs some firmware support. Just something to think about,
exactly. in all but POS (ACPI has a different term) the CPU is reset,
as is some other hardware (ram ctlr). SO upon CPU being powered again,
it will reset the same as if the whole system is cold-started (not sure -
what's difference between reset and INIT pin?) so the reset vector
0xffff0 code must branch at somepoint based on a flag (cold-start or
resume) and do things differently. for suspend to ram, this code is mostly
in linuxbios already (just re-init ram controller and things like that).
for suspend to disk, additionally (with current architecture) linux
would have to start to a certain point, then load image back into
ram (from swap?) I think special case of kexec to load ram image
from swap area or similar might be appropriate, that could
be called in a kernel thread when a flag is passed to linux(in rom)
from linuxbios.
>
> though I bet having an address in CMOS of which image to boot on power
I believe the standby power well in the PIIX4 maintains this state, but
cmos sounds like an appropriate place to store this.
>
> up would be all we would need to handle this case.
>
> Eric
