[LinuxBIOS] selection of compression algorithm

[yhlu]

OK, then We may let linuxbios_ram.rom and linuxbios_apc.rom and vsm code
stay with nrv2b if there is more overhead with lzma in CAR stage.


YH

On 5/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> wrote:
> 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
> that?
>
>
> Regards,
> Carl-Daniel
> --
> http://www.hailfinger.org/
>