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.
On 5/23/06, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> wrote:
We at least need two times
1. one is in car stage, and the code is in rom, and it is used to
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
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