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



_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Reply via email to