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 email@example.com wrote:
We at least need two times
- 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.
- lzma decompressor + lzma compressed linuxbios_ram
- 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/