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 Agreed. > > 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. Agreed. -Kevin -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
