Hi Wolfgang,
In message 5566.213.156.35.235.1206739577.webmail@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@denx.de core error - bus dumped