From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: AArch64 kernel image decompression
Date: Tue, 14 Jan 2014 07:14:51 +0100 [thread overview]
Message-ID: <201401140714.52400.arnd@arndb.de> (raw)
In-Reply-To: <CAOesGMi_QY6z_3QSdAs-3JaEUufgymJg=kiqpb9D6RNNjZF5sA@mail.gmail.com>
On Tuesday 14 January 2014, Olof Johansson wrote:
> On Mon, Jan 13, 2014 at 7:52 PM, bhupesh.sharma at freescale.com
> <bhupesh.sharma@freescale.com> wrote:
>
> > AFAIK, u-boot requires a u-boot specific header (see [1]) on top of any image it wants to
> > boot - whether it's a uncompressed vmlinux or a compressed vmlinux.gz
> >
> > In the ARM32 code base we had the Makefile rule to generate a uImage automatically (see [2]), with ARM64
> > now, I am forced to compress the vmlinux and put a u-boot header on top of it using 'mkimage' and then
> > feed the 'uImage' thus generated to the u-boot.
> >
> > So, it would be good if the ARM64 Makefile can mimic the ARM32 one in this aspect - now that we have
> > a working u-boot capable of booting vanilla linux on an ARMv8 foundation model.
>
> No, there should be no uImage target on arm64. Newer u-boots can
> already boot an ARM zImage (through the bootz command), and should be
> enhanced as needed to boot a vmlinux if needed.
Right. We've been trying to deprecate the uImage target on arm32 for a while,
but it's hard when all the documentation points to it. Hopefully not having
it on arm64 will teach people about the fact that it's not really needed
anyway.
Note that uImage is fundamentally incompatible with multiplatform kernels,
since it hardcodes the load address in the image file.
I thought we could already boot both zImage and vmlinux on arm32. I have
to correct myself about saying we should boot a vmlinux on arm64 though:
the documented interface is booting Image, which includes a Linux-defined
header, or Image.gz.
> Bringing in uImage as a target on ARM might have been a mistake, since
> now people want to bring in new targets for whatever boot format they
> happen to want. So it's a good idea to keep arm64 from going down the
> same path and stick to the native, raw, formats.
Yes. Not sure if there was much choice about uImage at the time arm32
u-boot was done, and multiplatform wasn't on the radar back then, but
we should have made the switch much earlier.
Arnd
next prev parent reply other threads:[~2014-01-14 6:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 17:04 AArch64 kernel image decompression Josh Cartwright
2014-01-13 11:17 ` Will Deacon
2014-01-13 11:29 ` bhupesh.sharma at freescale.com
2014-01-13 11:42 ` Arnd Bergmann
2014-01-14 3:52 ` bhupesh.sharma at freescale.com
2014-01-14 5:19 ` Olof Johansson
2014-01-14 6:14 ` Arnd Bergmann [this message]
2014-01-14 10:59 ` Russell King - ARM Linux
2014-01-14 16:48 ` Stephen Warren
2014-01-14 12:51 ` Marek Vasut
2014-01-14 13:38 ` bhupesh.sharma at freescale.com
2014-01-14 13:47 ` Wolfgang Denk
2014-01-14 17:19 ` Olof Johansson
2014-01-14 18:53 ` Wolfgang Denk
2014-01-15 4:37 ` Olof Johansson
2014-01-13 22:10 ` Josh Cartwright
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201401140714.52400.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).