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...
> - CONFIG_SYS_BOOTM_LEN is set to 64 MByte default in SPL, so it's
> a different default for SPL than for U-Boot !?!
> - CONFIG_SYS_BOOTM_LEN seemed to initially be used for kernel
> uncompression but is now used as a copy-only limit, too (no unzip)
> - Uncompression only works if a load address is given, what should
> happen if the FIT image does not contain a load address?
> - The whole memory management around FIT images is a bit messed up
> in that memory allocation is a mix of where U-Boot relocates itself
> (and which address ranges it used), the load addresses of the FIT
> image and the load addresses of the FIT image contents (and sizes).
> What's the point here to check CONFIG_SYS_BOOTM_LEN? Maybe it would
> be better to keep a memory map of allowed and already used data to
> check if we're overwriting things or to get the maximum size passed
> to gunzip etc.?
So I can at least give input on the memory map part :).
In efi_loader, we actually do maintain a full system memory map already,
including allocation functions that give you "safe" allocation
functionality (allocate somewhere in memory where you know nothing
overlaps).
Maybe we should move this into a more generic system and reuse it for
big memory allocations that really don't need to be in the U-Boot
preallocated regions?
Alex
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
