[U-Boot] [RFC] fit: include uncompression into fit_image_load

[Simon Glass]

Hi Simon,

On Tue, 20 Nov 2018 at 14:03, Simon Goldschmidt
<simon.k.r.goldschmidt at gmail.com> wrote:
>
> On Fri, Nov 16, 2018 at 3:05 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi,
> >
> > On 22 October 2018 at 11:55, Simon Goldschmidt
> > <simon.k.r.goldschmidt at gmail.com> wrote:
> > > On 22.10.2018 19:49, Simon Glass wrote:
> > >>
> > >> Hi Simon,
> > >>
> > >> On 19 October 2018 at 00:33, Simon Goldschmidt
> > >> <simon.k.r.goldschmidt at gmail.com> wrote:
> > >>>
> > >>> On 19.10.2018 05:25, Simon Glass wrote:
> > >>>>
> > >>>> Hi Simon,
> > >>>>
> > >>>> On 17 October 2018 at 03:41, Simon Goldschmidt
> > >>>> <simon.k.r.goldschmidt at gmail.com> wrote:
> > >>>>>
> > >>>>> On Wed, Oct 17, 2018 at 8:54 AM Alexander Graf <agraf at suse.de> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 16.10.18 21:33, Simon Goldschmidt wrote:
> > >>>>>>>
> > >>>>>>> Currently, only the kernel can be compressed in a FIT image.
> > >>>>>>> By moving the uncompression logic to 'fit_image_load()', all types
> > >>>>>>> of images can be compressed.
> > >>>>>>>
> > >>>>>>> This works perfectly for me when using a gzip'ed FPGA image in
> > >>>>>>> a FIT image on a cyclone5 board (socrates). Also, a gzip'ed initrd
> > >>>>>>> being unzipped by U-Boot (not the kernel) worked.
> > >>>>>>>
> > >>>>>>> To clean this up, the uncompression function would have to be moved
> > >>>>>>> from bootm.c ('bootm_decomp_image()') to a more generic location,
> > >>>>>>> but I decided to keep it for now to make the patch easier to read.
> > >>>>>>> Because of this setup, the kernel is currently uncompressed twice.
> > >>>>>>> which doesn't work...
> > >>>>>>>
> > >>>>>>> There are, however, some more things to discuss:
> > >>>>>>> - The max. size passed to gunzip() (etc.) is not known before, so
> > >>>>>>>     we currently configure this to 8 MByte in U-Boot (via
> > >>>>>>>     CONFIG_SYS_BOOTM_LEN), which proved too small for my initrd...
> > >>>>
> > >>>> We need the uncompressed size. If the legacy header doesn't have, stop
> > >>>> using it and use FIT?
> > >>>>
> > >>>> Some compression formats include that in a header I think. But we
> > >>>> should record it in the U-Boot header.
> > >>>
> > >>>
> > >>> OK, we could embed this information into the FIT by extracting in
> > >>> 'mkimage'?
> > >>> That way, we know the uncompressed size...
> > >>
> > >> Yes. In fact I don't like the way it works at present. We have to
> > >> compress the data before putting it in the FIT, since the .its file
> > >> refers to the compressed data.
> > >>
> > >> I think it would be better for the ,its to refer to the original file,
> > >> and then mkimage do the compression as it generates the FIT. That way
> > >> it knows the size of the original data, and it is simpler for people
> > >> to build images, since they don't need to compress everything
> > >> beforehand.
> > >
> > >
> > > Hmm, OK, I think it should not be a problem to add this to mkimage.
> > > Only I don't know if this workflow change would be accepted by everyone or
> > > if the old style of using pre-compressed files would have to be somehow kept
> > > working?
> >
> > I suggest supporting the old way with a flag. Also is it possible to
> > detect an already-compressed file and print an warning?
>
> I'm working on this and have it partly running, but I had to add this
> ugly "#ifndef USE_HOSTCC" thing to many files in lib/ to get the
> compression algorithms to compile for the tools.
>
> Is this acceptable? Or should we find a more generic approach, i.e.
> fixing the central include files (common.h, etc.) to handle
> USE_HOSTCC?

What sort of things don't build? It's not great, but it may be necessary.

Bonus points if the #ifdefs can be just in a header file, like mkimage.h

Regards,
Simon