[U-Boot] [RFC/RFT U-Boot PATCH] image: Add Image.gz parsing support in booti.
Tom Rini
trini at konsulko.com
Tue Nov 5 16:43:18 UTC 2019
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 at 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!
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20191105/52b29b80/attachment.sig>
More information about the U-Boot
mailing list