Hi Simon,
On Tue, 20 Nov 2018 at 14:03, Simon Goldschmidt simon.k.r.goldschmidt@gmail.com wrote:
On Fri, Nov 16, 2018 at 3:05 AM Simon Glass sjg@chromium.org wrote:
Hi,
On 22 October 2018 at 11:55, Simon Goldschmidt simon.k.r.goldschmidt@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@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@gmail.com wrote: > > On Wed, Oct 17, 2018 at 8:54 AM Alexander Graf agraf@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