[OLPC-devel] you can try this

[Carl-Daniel Hailfinger]

Marcelo Tosatti wrote:
> On Fri, May 26, 2006 at 12:37:12AM +0200, Carl-Daniel Hailfinger wrote:
>> Ronald G Minnich wrote:
>>> Steve, your VSA was 70k, which busted the 64k limit. So, I have added
>>> support to OLPC that assumes that the VSA is NRV2B compressed. This cut
>>> it from 70k to 42k. You now have 20k left to consume. More desirable, in
>>> future, would be for us to get this down to 32k, to leave room for linux
>>> ...
>>> I am attaching the nrv2b compressed OLPC VSA. I will be committing the
>>> changes for handling a compressed VSA in few minutes. Be warned: you
>>> can't go back :-)
>>>
>>> Also, Carl-Daniel is working on a better compression mechanism, which I
>>> hope we will move to very soon. This will get smaller, I think.
>> Yes. For the VSA you just mailed:
>>
>> Size  File
>> 71926 olpc_vsa.bin
>> 42139 olpc_vsa.bin.nrv
>> 37517 olpc_vsa.bin.lzma
>>
>> Ron, I'll mail you a patch for lzma support very soon. Just working
>> out the final bits to make it perfect. Can I submit a patch against
>> revision 2312 or do you have more in the queue?
> 
> Carl,
> 
> While at it, you might want to check kernel's LZMA compression:
> 
> http://www.zelow.no/floppyfw/download/Development/Patches/kernel/040-lzma-vmlinuz.diff

Ah, another iteration of lzma-in-kernel. All of these lzma-in-kernel
patches I saw are based on very old upstream code, do not follow
proper coding style, have #ifdef mess and use macros all over the
place, besides that they are very windows-like in variable naming
(StudlyCaps) and typedef usage.

Since we have to have lzma in LinuxBIOS (to compress VSA etc. reasonably
well), these patches are interesting, but of no use to us because
we can as well use the lzma decompressor of LinuxBIOS to decompress
the kernel and initrd.

Thanks,
Carl-Daniel
-- 
http://www.hailfinger.org/