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

Marek Vasut marek.vasut at gmail.com
Tue Apr 30 19:11:01 UTC 2019


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 ?

> 
> (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 .

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


-- 
Best regards,
Marek Vasut


More information about the U-Boot mailing list