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):
- removal of the custom vgabios handling, using oprom instead
1.5. do the same thing for vsmsetup.c
- moving RAMBASE to 1MB
Stefan