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

[Harald Welte]

Hi Wolfgang, Luigi,

On Fri, Mar 28, 2008 at 11:33:58PM +0100, Wolfgang Denk wrote:

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

Given my expertise with license compliance, I volunteer to look into the
legal issues, to the point that if I have any doubt I will consult with
my legal counsel on that subject.

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

As for board support / LZMA: I don't know.  But I'm pretty sure that
I've seen LZMA compressed u-boot images before.  LZMA is really popular
with cheap consumer-grade embedded linux equipment, particularly DSL CPE
and Wifi Routers.  Most of them don't use u-boot, but only use it for
the kernel image and the flash filesystem.  They're using quite simple
out-of-tree patches for that, though.

I think this has come up on lkml before, and Linus didn't like it very
much.  Probably related to the fact that many core kernel hackers look
at embedded as sort of a special case, when in reality I am quite sure
that the total quantity of embedded systems running Linux is
significantly larger than the number of Linux servers + desktops
together...

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

That has obviously to be fixed.
 
> How exactly is this code supposed to be used?

some documentation would certainly be fine, yes.

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

Yes and no.  I tend to agree, but I also realize that there are economic
incentives to keep the bom cost as low as possible, especially in
large-quantity consumer equipment...

You can just as well claim: If you're using suboptimal compression and
wasting flash space, you have a software design problem ;)

I think it makes a lot of sense to add LZMA support to u-boot, but
obviously in a clean, consistent, documented way.  It doesn't hurt, will
not be compiled unless explicitly selected, and the API is zlib like,
i.e. the code changes it requires are non-intrusive.

Just my thoughs...

--
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.denx.de/pipermail/u-boot/attachments/20080406/432514cb/attachment.pgp