[U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti.

[Atish Patra]

On 4/30/19 12:11 PM, Marek Vasut wrote:
> On 4/30/19 8:13 PM, Atish Patra wrote:
>> On 4/30/19 2:52 AM, Marek Vasut wrote:
>>> On 4/30/19 3:27 AM, Atish Patra wrote:
>>>
>>> [...]
>>>
>>>>>> Yes. FIT image parsing can be done in that way. However, the idea was
>>>>>> here to load Image.gz directly. Image.gz is default compressed Linux
>>>>>> kernel image format in RISC-V.
>>>>>
>>>>> Sigh, and the image header is compressed as well, so there's no way to
>>>>> identify the image format, right ? And there's no decompressor, so the
>>>>> dcompressing has to be done by bootloader, which would need some
>>>>> sort of
>>>>> very smart way of figuring out which exact compression method is used ?
>>>>>
>>>> Yes. Image.gz is always gunzip. So checking first two bytes is enough to
>>>> confirm that it is a gz file.
>>>
>>> What happens once people start feeding it more exotic compression
>>> methods, like LZ4 or LZO or LZMA for example ?
>>>
>>
>> booti command help will clearly state that it can only boot kernel from
>> Image or Image.gz.
>>
>> static char booti_help_text[] =
>>       "[addr [initrd[:size]] [fdt]]\n"
>> -    "    - boot arm64 Linux Image stored in memory\n"
>> +    "    - boot arm64 Linux Image or riscv Linux Image/Image.gz stored
>> in memory\n"
> 
> Obvious question -- does this Image.gz stuff apply to arm64 ?
> 

arm64 builds Image.gz but booti for arm64 doesn't use it. I guess 
Image.gz can be used in FIT image for ARM64 but I am not sure which 
platform actually uses it.

This patch only enables support for RISC-V.

>>
>> (I will update the help text with Image.gz part)
>>
>> Anything other than that, it will fail with following error.
>>
>> "Bad Linux RISCV Image magic!"
> 
> Right, so we're implementing file(1)-lite here to detect the format.
> 
>>>> The tricky part is length of the compressed file. I took another look at
>>>> the gunzip implementation in U-Boot. It looks like to me that compressed
>>>> header length just to parse the header correctly. It doesn't actually
>>>> use the "length" to decompress. In fact, it updates the length with
>>>> uncompressed bytes after the decompression.
>>>
>>> That's possible.
>>>
>>
>> David suggested a better idea.
>>
>> 1. User can supply kernel_size and we can store in environment variable.
>> 2. If the size is empty or greater than CONFIG_SYS_BOOTM_LEN, booti
>> fails with appropriate error message.
> 
> You can keep decompressing until you reach $bootm_len, sure .

Decompression happens for actual uncompressed length which is encoded 
into the compressed file footer. So we don't have to worry about how 
much we decompress. But a correct file_size helps to avoid decompressing 
a possible corrupt compressed file.

I will update the patch as per David's suggestion.

Regards,
Atish
> 
>> We will update the documents to add the additional step for Image.gz
>>
>> I am fine with either approach. Any preference ?
>>
>> Regards,
>> Atish
> 
>