[coreboot] [LinuxBIOS] Messing with CAR in a big way / S3 considerations

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Jan 12 23:21:16 CET 2008


On 12.01.2008 22:39, Rudolf Marek wrote:
> ron minnich wrote:
> > Rudolf, many payloads start at 1 MB. I don't think we want to use CAR
> > at that low address.
>
> Maybe if you want to have CAR address = RAM address (to copy it to itself)
> Just please choose TOPK - CAR_SIZE as it is now.

Well, CAR has to be below 1 MB (processor limitation). We can make sure
it will not clobber more than 64 kB in that area. Because of conflicts
with legacy ROM decoded areas, CAR has to stay below 896 kB. Conflicts
with areas decoded by devices are pretty likely in the 640 kB - 1024 kB
range.

> > What is the reason that we can't put all coreboot
> > variables below 1MB?
>
> Yes we can, but some parts are very messy including but not limited to:
>
> 1) stack segment for AP cpus, very ugly define, hardwired to 1MB when
> using
> _RAMBASE lower then 1MB
>
> 2) Memory is cleared from zero to TOPK, which is bad.

But the two points above are pure code issues and can be fixed, right?

> > Just trying to understand s3 :-)
>
> Before suspend phase:
> Coreboot boots payload, it boots OS.
>
> Suspend phase:
> Linux will put to a ACPI table a waking vector address, and uses the
> value from
> DSDT to write to SB value to activate the S3 sleep.
>
> Resume phase: Coreboot runs as from coldboot except of taking memory from
> self-refresh mode. No payload is to be loaded, only it is jumped back
> to OS.
>
> What it needs:
>
> It just needs not to mess with memory too much. We can reserve a
> region for
> Coreboot say at 1MB-2MB (plus usual reserved regions like 0-4K and
> 960K-1MB)

See my list of constraints above.

> I dont want to take all low memory because the entry point is in real
> mode and
> the OS must have some memory bellow 1MB free.

An area with 64 kB size somewhere below 1 MB should cover variable
storage. We might have to mess with the 0-4 kB area as well.

> There are parts of Coreboot which are messing too much with memory, like I
> described in previous mails and this must be fixed. Easiest way how to
> avoid
> non-std solutions and get instantly more memory is to escape to up 1MB
> of memory
> or to any better place ;) I dont think it is wise to have for LB only
> 0 - 640KB
> of RAM with lot of exceptions, lets use one continuous block in
> "higher" RAM.
> ACPI says, reserved blocks can start at 8MB.
>
> Problematic parts:
>
> Secondary.S -  (the trampoline for AP CPUs)
>
> lapic_cpu_init.c -  (it copies the Secondary.S to undefined place in
> low memory,
> and AP cpu stack is handled badly when _RAMBASE is bellow 1MB)
>
> wakeup.c (yeah mine implentation which jumps back to real mode, this
> must be
> fixed, so no data at our reserved region of 0-4KB gets overwritten)
>
> clear_init_ram.c (in AMD CAR)
>  it just clears a lot of memory from ZERO instead of _RAMBASE to TOPK
>
> Used CAR "memory/cache" should not be a problem, because it is not
> written back
> to memory in any way.
>
> So to sum it up. If we would isolate Coreboot writes to memory to
> those regions:
>
> 0-4K
>
> 960K-1M
>
> _RAMBASE - TOPK  (RAMBASE > 1MB)
>
> It would be nice, and just _RAMBASE - TOPK region could be reserved in
> memory
> map, because it uses Coreboot when starting after resume. This memory
> region
> could be claimed back to OS via ACPI memory hotplug, which I'm now
> investigating. Reserving permanently 1MB of memory when using S3 would
> be also
> possible because Asus BIOS takes 1MB at the end of memory for SMM and
> suspend too.

Well, during CAR our stack has to be below 1 MB. Moving the stack during
execution is something we do now for K8, but I'd like to get rid of that
completely so we never introduce such stuff to v3. Note: Geode LX in v3
does not move the stack.

> I hope it is now clear how it works ;) I just avoided in my
> experiments all
> those stuff because I told linux to use 2MB-1024MB :) (my TOPK is 2048)

Nice trick.

> But now I really would like to get this solved too, because suspend to
> RAM now
> works which is great leap because with proprietary BIOS I was unable
> to get it
> working :)))

Congratulations!

Regards,
Carl-Daniel




More information about the coreboot mailing list