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

[Tom Rini]

On Fri, Aug 02, 2019 at 02:50:40PM +0200, Simon Goldschmidt wrote:
> 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...?

OK.  So lets special case ramdisk to just note that we see it's
compressed ("compression: %s, ignored" ?) and then we'll find out if
there's really a bunch of cases where people assumed it was decompressed
by us or not.

-- 
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/26024af6/attachment.sig>