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