Am 12.04.2010 15:39, schrieb Kevin O'Connor: > On Mon, Apr 12, 2010 at 11:56:45AM +0200, Patrick Georgi wrote: >> Am 12.04.2010 06:41, schrieb Kevin O'Connor: >>> Indeed, the time to "Stage:..." is faster than romcc now. Just need >>> to fix that delay after "Stage:".. >> Your other mail seems to indicate that this is because of the stack at 64MB. > > That's my guess - I'll try and confirm tonight. > >> 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.
> - 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. > 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. Patrick -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
