[coreboot] [PATCH] Add option 'compress ramstage'

Eric W. Biederman ebiederm at xmission.com
Tue May 3 01:26:12 CEST 2011

Stefan Reinauer <stefan.reinauer at coreboot.org> writes:

> * Eric W. Biederman <ebiederm at xmission.com> [110502 22:00]:
>> Sven Schnelle <svens at stackframe.org> writes:
>> > Add an option to make compression of ramstage configurable. Right now
>> > it is always compressed. On my Thinkpad, the complete boot to grub takes
>> > 4s, with around 1s required for decompressing ramstage. This is probably
>> > caused by the fact the decompression does a lot of single byte/word/qword
>> > accesses, which are really slow on SPI buses. So give the user the option
>> > to store ramstage uncompressed, if he has enough memory.
>> Odd. Historically this has been solved by simply putting an mtrr over
>> the compressed area.  So that you would still get full cache block
>> transfers during the decompression.  I am fuzzy about the appropriate
>> mode.  Write protect I think.
>> Have you tried setting up an mtrr over the area that will be
>> decompressed.  That should result in something that is even faster
>> than copying non-compressed data.
> The problem is that the code hard coded those values assuming coreboot
> lives in the first 1MB which is not the case anymore since we have SMM
> handlers.

Was that a destination hard code?  The code itself should come out of
the last couple of megabytes before 4G.

Regardless the performance penalty for not caching is huge fractions
of the boot time so whatever small practical issues exist we should
figure them out.


More information about the coreboot mailing list