On Tue, Nov 05, 2019 at 03:51:54PM +0000, Atish Patra wrote:
On Mon, 2019-11-04 at 17:35 -0500, Tom Rini wrote:
On Mon, Nov 04, 2019 at 10:20:33PM +0000, Atish Patra wrote:
On Fri, 2019-11-01 at 09:29 -0400, Tom Rini wrote:
On Thu, Oct 10, 2019 at 02:23:17PM -0700, Atish Patra wrote:
Add gz parsing logic so that booti can parse both Image and Image.gz to boot Linux. Currently, it is difficult to calculate a safe address for every board where the Image.gz can be decompressed. It is also not possible to figure out the size of the compressed file as well. Thus, user need to set two additional environment variables kernel_gz_addr_r and kernel_gz_size to make Image.gz work.
Tested on HiFive Unleashed and Qemu for RISC-V.
Signed-off-by: Atish Patra atish.patra@wdc.com
I could not test this patch on any ARM64 devices due to lack of access to any ARM64 board. If anybody can test it on ARM64, that would be great.
Oh, I missed this part before. You should be able to get fairly far with qemu :)
I did verify with qemu. I was requesting some tested-by on ARM64 hardware. Sorry for the confusion. I will update the commit text in next version.
Ah, OK.
Can we do the compression check more generally? I'd like to be able to see Image.xz/lz4/etc be able to be handled cleanly.
This patch is intended only handle Image.gz which is a compressed version of kernel "Image" file. That's why relevant code is only added to booti command.
Right. But the linux kernel will happily spit out a handful of other compressed Image files on arm64. I see riscv is only .gz today, but I want to be able to handle whatever the compression is, so long as we have it available.
Ahh I misunderstood that part. I could not find any existing code to detect to different compression formats.
If I have not missed anything, I can add that code in common/image.c and use that function in booti.c.
Right, it's something we don't have today. But I _think_ we have enough of a general abstraction setup such that just like how we have "load" and "ls" and such that will figure out the underlying filesystem we could have "uncompress" (or perhaps something else, that might be an alias for gunzip already) that will figure out what the compression is based on the header and do the right thing. Thanks!