[U-Boot] fit image: boot gzipped ramdisk does not work anymore

[Tom Rini]

On Fri, Aug 02, 2019 at 08:00:22AM +0200, Simon Goldschmidt wrote:
> Hi Heiko,
> 
> On Fri, Aug 2, 2019 at 6:08 AM Heiko Schocher <hs at denx.de> wrote:
> >
> > Hello Julius,
> >
> > Am 01.08.2019 um 20:24 schrieb Julius Werner:
> > >> First, we have a problem as we need to support what's out in the world.
> > >
> > > How about I write a patch to change the decompression call in
> > > fit_image_load() to fall back to a memcpy() if the decompression fails
> > > (and print a big warning that the FIT image is wrong and should be
> > > updated)? That should keep those old installations working.
> >
> > Hmm.. what happens if decompression does not fail ?
> > (I wonder, why I get this Error, but I go into vacation, so I have
> >   no chance to dig deeper into it soon ...)
> >
> > And why should we decompress, if we "know" we do not have to (in ramdisk
> > case)? This cost only boottime ...
> 
> It's correct we don't need to decompress since the kernel can decompress the
> ramdisk. However, the FIT image is wrong (given our updated definition of the
> "compressed" field) and it's only decompressed on "legacy" images.
> 
> >
> > For the fast track, I prefer to ignore the compression property in ramdisk
> > node ... (may configurable through a Kconfig option with default to ignore)
> 
> I'm not too fond of adding such extra cases, but you're right that
> decompressing a ramdisk is probably never needed...

I think we have a case where intentions differed historically and now we
have to deal with it.  Back in the earlier thread this year where we
talked about this exact case, it was OK to start decompressing ramdisks
as that was the intention way back when, but it was silently broken
forever ago.  After it was broken is when FIT adoption finally took off
and we have the real life case of "set compression to the factual value,
but it's not used by U-Boot!" has now become "set compression to the
factual value and U-Boot decompresses it".

Maybe the best choice is to rework things so that we only check
compression on (and decompress) device trees and when we print ramdisk
information we note that it's not being decompressed?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190802/aca544c6/attachment.sig>