[LinuxBIOS] Messing with CAR in a big way

Rudolf Marek r.marek at assembler.cz
Sat Jan 12 11:45:47 CET 2008

Hash: SHA1

Carl-Daniel Hailfinger wrote:
> On 12.01.2008 01:18, Rudolf Marek wrote:
>> Imho you must copy the data from CAR, because when it is OFF, no
>> writeback is
>> done to memory: (from BKDG)
>> Temporary data stored in the cache during boot cannot be written back
>> to DRAM
>> after enabling the
>> DRAM controller using a CLFLUSH or WBINVB instruction. The cache should be
>> invalidated after the DRAM controller is initialized with an INVD
>> instruction.
> OK, then we simply copy the whole CAR area to some backup memory
> location, disable CAR, then INVD and copy everything back to the
> original location. That way, moving the stack with all of its nasty side
> effects will not happen.
>> The later is imho not done in LB I think. Maybe needs fix?
> I have to reread the v2 code. Almost all BIOS code I write nowadays is
> either for code shared between v2 and v3 or for v3 only.

Ok, I tried to research this yesterday but failed to find it.

>> Btw please design it to be suspend-to-ram friendly ;)
> Will do. Is there any specific part of the source that lists your
> requirements for suspend-to-RAM? IIRC resume-from-RAM enables CAR, gets
> RAM out of self-refresh, then jumps back to the OS. Writing to arbitrary
> RAM locations has to be avoided with suspend-to-RAM.

Yes or at least now please write to 1MB - TOPK region as it is done now in v2.
So the CAR is written directly bellow to TOPK.

I think for S3 I will need to define LOWK too. -maybe just _RAMBASE But lets
assume now that 1MB-TOPK  memory can be used. Please try to avoid writings
anywhere in bellow 1MB as possible (to RAM, CAR location is "dont care" for me).

I think to run S3 from unpatched kernel I still need to fix Secondary.S boot
plus my reset realmode routine. I think I will put it directly to first 4KB of
memory, which will be later overwritten by tables anyway.

So far, I would prefer if LB uses mem like this:

0-4KB (lowmem data area)


0xf000 BIOS segment for DSDT etc

This memory should be reserved in e820 _RAMBASE-TOPK plus we can use ACPI memory
hotplug to reclaim this memory back once linux is restored ;) (yeah my know idea  )

So haveing _RAMBASE sitting at 1MB as default would be cool too, eliminates the
stack computations for 1MB for APs too.


> Regards,
> Carl-Daniel
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the coreboot mailing list