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: >>> 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. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
