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...
- 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?
Hmm, inspecting this further, it seems that there is such an allocator for bootm (using lmb_*() functions and struct lmb). Maybe this should be better integrated into the fit loading function. I don't know if the lmb functions correctly detect overlapping of regions allocated by known addresses though.
Thanks for your thoughts!
Simon