On 08.09.2008 01:27, Kevin O'Connor wrote:
Hi,
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:
- 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.
- 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.
- 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.
- 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.
Regards, Carl-Daniel