[LinuxBIOS] selection of compression algorithm

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Wed May 24 02:00:58 CEST 2006

yhlu wrote:
> We at least need two times
> 1. one is in car stage, and the code is in rom, and it is used to
> uncompress linuxbios_ram
> 2. one is in linuxbios_ram, and it is in ram, it is used to uncompress payload.
> car stage, before call copy_and_run, the stack is already in ram. but
> code is still in rom. So at this time we need to balance the lzma
> benifit on compress linuxbios_ram and it's own code size increase in
> rom. also need to set one extra buffer in ram for every ap code.

OK, so we have to check which of the two solutions is smaller.
1) lzma decompressor + lzma compressed linuxbios_ram
2) nrv2b decompressor + nrv2b compressed (linuxbios_ram + lzma decompressor)

I just checked this for all abuild targets. The second variant wins
for half of the targets. That brings me to a third option:
3) nrv2b decompressor + nrv2b compressed lzma decompressor + lzma
   compressed linuxbios_ram
nrv2b decompressor needs IIRC 512 bytes, lzma decompressor needs 4096
bytes, so if nrv2b only compresses the lzma decompressor and we assume
~50% savings by compression, option 3 is always 1.5k smaller than option 1
and option 3 is 1.5k-7.3k smaller (2k for OLPC) than option 2.

How difficult would it be for us to build option 3?

> Hope we can squash car stage code + linuxbios_ram code into 64k again.

Depending on the board, that might be difficult. For OLPC, everything fits
nicely into 32k. For most Tyan boards, we suffer from the fact that auto.o
is uncompressed and ~28k alone. That is really horrible. Any reasons for


More information about the coreboot mailing list