[U-Boot] [PATCH] spl: fit: Enable GZIP compression also for no kernel partitions

[Michal Simek]

On 25.7.2018 12:14, Simon Goldschmidt wrote:
> 
> 
> On 25.07.2018 09:04, Michal Simek wrote:
>> On 25.7.2018 08:52, Simon Goldschmidt wrote:
>>> On 25.07.2018 08:40, Michal Simek wrote:
>>>> On 25.7.2018 08:26, Simon Goldschmidt wrote:
>>>>>
>>>>>
>>>>> On 24.07.2018 15:07, Michal Simek wrote:
>>>>>> There is no reason to limit gzip usage only for OS_BOOT and kernel
>>>>>> image
>>>>>> type. >
>>>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>>>> ---
>>>>>>
>>>>>>     common/spl/spl_fit.c | 5 +----
>>>>>>     1 file changed, 1 insertion(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
>>>>>> index 9eabb1c1058b..dbf5ac33a845 100644
>>>>>> --- a/common/spl/spl_fit.c
>>>>>> +++ b/common/spl/spl_fit.c
>>>>>> @@ -257,10 +257,7 @@ static int spl_load_fit_image(struct
>>>>>> spl_load_info *info, ulong sector,
>>>>>>         board_fit_image_post_process(&src, &length);
>>>>>>     #endif
>>>>>>     -    if (IS_ENABLED(CONFIG_SPL_OS_BOOT)    &&
>>>>>> -        IS_ENABLED(CONFIG_SPL_GZIP)        &&
>>>>>> -        image_comp == IH_COMP_GZIP        &&
>>>>>> -        type == IH_TYPE_KERNEL) {
>>>>>> +    if (IS_ENABLED(CONFIG_SPL_GZIP) && image_comp == IH_COMP_GZIP) {
>>>>>>             size = length;
>>>>>>             if (gunzip((void *)load_addr, CONFIG_SYS_BOOTM_LEN,
>>>>>>                    src, &size)) {
>>>>>>
>>>>>
>>>>> I suppose this is to support a gziped fpga image in a fit. Does this
>>>>> work for U-Boot proper already?
>>>>
>>>> Luis has tested it some days ago based on my suggestion. I have tried
>>>> that yesterday on zynq zc706 and it was also working for internal data.
>>>> Please take a look at second thread where also times are listed.
>>>
>>> Isn't that 2nd thread on SPL also? I was asking for U-Boot proper in
>>> comparison.
>>
>> I have tested several cases for this series.
>> https://lists.denx.de/pipermail/u-boot/2018-July/335193.html
>>
>> This is my script for generating images.
>>
>> mkimage -d download.bin -T firmware -C none -a 0x1000000 -e 0x1000000 -A
>> arm -n "fpga download.bin" download.ub
>>
>> gzip < download.bin > download.bin.gz
>> mkimage -d download.bin.gz -T firmware -C gzip -a 0x10000000 -e
>> 0x10000000 -A arm -n "fpga download.bin.gz" download.gz.ub
>>
>> mkimage -f fit.its  download-fit.ub
>>
>> fit.its unfortunately is not using gzip format.
> 
> I'm using the 'mkimage -f fit.its boot.itb' case (in U-Boot, not SPL),
> so I if I read your comments above correctly, this is still not
> supported for FIT images but only for "legacy" images?
> 
> But the recent patches add gzip support for FIT in SPL, did I get that
> correctly?

We need to solve one issue with socfpga support but yes it is enabling
gzip support for FIT in SPL.

> 
> If so, would it make sense to add FPGA gzip support in FIT to U-Boot
> proper?

Sure why not. I expect this shouldn't be hard to do.


>>
>>> We are programming the FPGA from U-Boot proper, not SPL, using a
>>> Multi-config FIT image including matching Kernel and Device tree. And
>>> here, using a gziped FPGA might be nice. But from reading the sources (I
>>> think I also tested it once), that doesn't work. That's why I ask.
>>
>> I am going to retest the whole series and I can try it but if this is
>> working in SPL I can't see any issue why this shouldn't work in full
>> u-boot. I am not using -E for mkimage but please test it and let me know
>> if this is working or not.
> 
> I'm not familiar with the -E option for mkimage. Does it apply to -f
> fit.its? Given the above statements, I think my use case just does not
> support gziped FPGA, yet.

-E should be external data format that data are not stored with
information about partition. It means you can load just header and then
images which you need that you don't need to load everything what it is
there. Imaging fit image with 10 bitstreams and 10 configurations and
you only want to load one which you want to load.
It is faster to read 1 bitstream from sd then 10.

Thanks,
Michal