[coreboot] [PATCH] VIA C7 CAR fixes / cleanup

Kevin O'Connor kevin at koconnor.net
Tue Apr 13 02:30:40 CEST 2010

On Mon, Apr 12, 2010 at 04:21:34PM +0200, Patrick Georgi wrote:
> Am 12.04.2010 15:39, schrieb Kevin O'Connor:
> > On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote:
> >> If we:
> >> - Move the intermediate stack to wherever the ramstage stack resides
> >> (somewhere close to RAMTOP),
> >> - change the stage loaders (copy and ulzma) to leave out %esp..RAMTOP
> >> (with some safety margin below %esp), which should always be "0" anyway, and
> >> - enable caching for RAMBASE..RAMTOP (already done, I think)
> > 
> > I didn't understand the first two points.  The third point makes sense
> It seems that the stack is usually close to RAMTOP. We'd have to make
> sure that it's at a deterministic position (ie. == RAMTOP) and avoid
> overwriting that stack on decompression, then we could reuse the
> ramstage stack location for uncompression.

Ahh - okay.  I was getting the ramstage confused with romstage.

> > - right now on my board RAMBASE is 0x4000 
> Most boards have RAMBASE at 1MB (or 2MB in some cases). RAMBASE at 16K
> is only left for a couple of boards that rely on their own vgabios handling.
> Two things "should" happen (if someone with the board finds the time):
> 1. removal of the custom vgabios handling, using oprom instead
> 2. moving RAMBASE to 1MB


> > if we make sure to cache everything up to RAMTOP and then place the
> > ulzma stack somewhere in that memory range I think it should work.
> That "somewhere" could be the stack location of the ramstage.

Makes sense.

> > Right now, the code in src/cpu/via/car/cache_as_ram.inc isn't setting
> > up the cache using RAMBASE or RAMTOP - it just does it's own range
> > (which I think is the first 1Meg and a small part of flash) - it's the
> Might be good to change this at some point.



More information about the coreboot mailing list