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

[Simon Goldschmidt]

On Fri, Aug 2, 2019 at 2:36 PM Tom Rini <trini at konsulko.com> wrote:
>
> 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?

While I can understand that point of view, please note that my intention is
not having a compressed devicetree (where we save some KByte) but having a
compressed FPGA image (where I save about 2 MByte!).

Given that, please don't start a positive list (e.g. only decompress
devicetree and Kernel). But if we actually need to do this differently per
type, just implement Heiko's suggestion and don't decompress ramdisks.

That way, we could show an error when seeing this setting for ramdisks and
probably remove this special case handling in some years...?

Regards,
Simon