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

Ulf Samuelsson ulf.samuelsson at atmel.com
Sat Mar 29 00:02:20 CET 2008


>> 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.
> 
> 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.
> 

I think there should be no problem from a license point of view.

The home page says that you can use unmodified source
in your own code without having to release it to the public.

Since U-boot is open source to start with, this cannot be a problem.

It goes on and says that if the LZMA lib is modified,
then the resulting code has to be released as open source.
Again, no problem for U-boot, since it is open source to start with.

There are also commercial licenses available, but that is not applicable
since noone signed a commerical license.


> Please check for compatibility of licenses berfore resubmitting.
> 
>> 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?
> 

There are kernel patches for LZMA compression available.
Can be selected at least in buildroot.

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

Maybe the patches for Linux creates an image???
Never saw any need to use it myself.

> 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 design problem.
> 

Lots of applications are cost sensitive, and shaving 50 cents here,
50 cents there could be important.
Hard to judge without knowing the details.

> Best regards,
> 
> Wolfgang Denk
> 


Best Regards
Ulf Samuelsson




More information about the U-Boot mailing list