[U-Boot-Users] LZMA support (patch)

[Luigi 'Comio' Mantellini]

Hi Wolfgang,

> In message
> <5566.213.156.35.235.1206739577.webmail at webmail.idf-hit.com>
> you wrote:
>>
>> Running the contained script the directory will be populated
>> with all need files (LzmaTypes.h, LzmaDecode.*). Anyway, I
>> can
>> resubmit the patch including all files. The LZMA SDK is
>> released under LGPL with exceptions but I don't understand if
>> the license is compatible with the u-boot's license. For this
>> reason I omitted  the sources from the SDK.
>
> This makes no sense to me.

I'm not expert in legalese questions.

>
> Either the license is compatible, and the code can be included,
> or it
> is not, then it cannot. In the latter case, the whole patch
> makes no
> sense.
>
> Please check for compatibility of licenses berfore
> resubmitting.

I think that the license is compatible (see the
http://www.7-zip.org/sdk.html). I just share my code with
community...
>
>> LMZA performs better than LZ on binary files. I will switch
>> to
>> LZMA to save flash memory space on my appliance. Of course,
>> the
>> LZMA is slower than LZ.
>
> But so far there is no code (board support) in  U-Boot  to  use
>  this
> feature, right? And it's not used by the Linux kernel either?
>

The code is used (eventually) by do_bootm routine to uncompress
a lzma-ed kernel image. The patch provides the opportune
image.c/cmd_bootm.c changes for this.

> And your patch does not even enable support for it in the
> mkimage
> tool, so you cannot even create images that use the feature?
>

mkimage doesn't compress anything! As well as gzipped images,
the lzma-ed images are created by an external tool (7z?):
mkimage adds just a simple identification header to identify
the used compression method. The proposed patch permits to
mkimage to set the opportune compression type (id=3) in the
uImage to recognize the lzma images.

> How exactly is this code supposed to be used?
>
>> Anyway, if the LZMA SDK license is compatible with U-boot , I
>> think that LZMA should be chosen by firmware developer when
>> the
>> flash memory space is a critical resource.
>
> Frankly, if you are so short with flash you have a h/w dsign
> problem.
>

The project constraints require a cheap flash memory to reduce
the final cost (and prize) of the device. This is not a design
problem...

luigi

> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev
> Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell,
> Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email:
> wd at denx.de
> core error - bus dumped
>