> > 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. > Are we caching CONFIG_RAMBASE - CONFIG_RAMTOP ? > 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 > 1.5. do the same thing for vsmsetup.c > 2. moving RAMBASE to 1MB > > Stefan
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot