From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Tue, 30 Apr 2019 11:52:20 +0200 Subject: [U-Boot] [PATCH v2 2/2] RISCV: image: Parse Image.gz support in booti. In-Reply-To: <6a65fac9-fafd-35d9-ef0b-d5e62514cec0@wdc.com> References: <20190425195643.7104-1-atish.patra@wdc.com> <20190425195643.7104-2-atish.patra@wdc.com> <10a880f3-e63d-ff99-4553-d85568cf3517@gmail.com> <6a65fac9-fafd-35d9-ef0b-d5e62514cec0@wdc.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 ? > 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. -- Best regards, Marek Vasut