[LinuxBIOS] selection of compression algorithm

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Tue May 23 21:13:28 CEST 2006

Ronald G Minnich wrote:
> Stefan Reinauer wrote:
>> 1. auto.c stage           (romcc)
>> 2. uncompression stage    (gcc)
>> 3. compressed linuxbios stage (gcc, initially compressed)
> What I think of as the long term goal for OLPC:
> 1. auto.c stage: CAR, gunzip gcc code to ram
> 2. gcc stage: turn on the hardware, gunzip vga bios, other pieces, and 
> payload to ram
> 3. payload runs, may do further gunzip work

Do we really want to gunzip anything in CAR stage? How big is the code
to turn on RAM? Will it really benefit from being compressed? I would
turn on RAM first and only then start uncompression.

At what stage am I allowed to use malloc? gcc stage? payload stage?
Can I abuse the function stack before?

Another thing that bothers me: It seems we include the uncompression code
multiple times. Can we include it only once and make all stages use it?

> the gunzip was removed from V1 because linux had its own decompressor in 
> the bzimage. Given that there was, at the time, only one gunzip step, 
> using the kernel's gunzip was deemed to save space. On OLPC, which is 
> representative of the new systems, there are several distinct compressed 
> bits:
> 1. nrv2b for gcc-compiled linuxbios
> 2. nrv2b for OLPC VSA binary
> 3. nrv2b for linux+initrd
> 4. nrv2b for VGA BIOS

Can you upload all these files somewhere so I can make a size comparison
and work out the best compression parameters for lzma?

I have a (not completely finished) script called squeeze_lzma which will
run lzma with different parameters and figure out which yield the best
compression for the unlimited RAM case and for the small RAM case. So
we can use compression which needs only 5k RAM for decompression in
stage 1 and 60k RAM in stage 2+3.


More information about the coreboot mailing list