[coreboot] suspend/resume in v3
c-d.hailfinger.devel.2006 at gmx.net
Mon Sep 8 01:50:07 CEST 2008
On 08.09.2008 01:27, Kevin O'Connor wrote:
> On Sun, Sep 07, 2008 at 11:40:51PM +0200, Rudolf Marek wrote:
>>> CAR will write to memory locations below 1M. There are three ways to
>>> cope with that:
>>> 1. Back up that area during suspend and restore it as last instruction
>>> of resume.
>>> 2. Declare the CAR area (48 kB) as reserved memory.
>> Imho this is OK, and easiest.
> I don't think one can mark 48KB reserved below 0xA0000. I've found
> that boot loaders are picky about any reserved memory below 1MB.
Would 0xC0000-0xCFFFF for be OK? We already use that on some targets.
> It's normal to reserve the ebda (typically 0x9fc00 to 0xa0000), but I
> seem to recall reading that an EBDA over 16KB will confuse some
> programs. Using the EBDA area would also likely break SeaBIOS.
We don't want to break SeaBIOS. Having an EBDA area might be useful
sometime in the future, though.
>>> 3. Write excessively clever and fragile code which performs a double
>>> stack switch during resume.
>> Here are some other ideas, might not work if stack is never realocated. I
>> dont know how CAR in v3 works.
>> 4. use 0xA0000-0xBFFFF
>> I think we can use this RAM because it will be covered by SMM (done by
>> us) or will be covered by legacy VGA anyway.
> That should work for CAR, but it obviously wouldn't be useful for any
> long term storage.
The CAR area in v3 is where the stack lives during CAR and after
RAMinit. So if any code/hardware clobbers it before the last instruction
of coreboot, v3 will explode. The v2 model of having 2 stack locations
was a source of lots of headaches.
>> 5. use 0xf0000-0xfffff
>> It will get overwritten by some our code, before that we might use it.
> Using that area would prevent SeaBIOS from working.
OK, so the 0xC0000-0xCFFFF area is likely our only option, then.
More information about the coreboot