[coreboot] [PATCH] VIA C7 CAR fixes / cleanup
patrick.georgi at coresystems.de
Mon Apr 12 16:21:34 CEST 2010
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.
More information about the coreboot