On Thu, Aug 14, 2014 at 08:11:49PM +0100, Tom Rini wrote:
> On Thu, Aug 14, 2014 at 04:16:50PM +0100, Mark Rutland wrote:
> > Hi Tom,
> >
> > On Thu, Aug 14, 2014 at 11:42:36AM +0100, Tom Rini wrote:
> > > The default format for arm64 Linux kernels is the "Image" format,
> > > described in Documentation/arm64/booting.txt. This, along with an
> > > optional gzip compression on top is all that is generated by default.
> > > The Image format has a magic number within the header for verification,
> > > a text_offset where the Image must be run from, an image_size that
> > > includes the BSS and reserved fields.
> > >
> > > This does not support automatic detection of a gzip compressed image.
> > >
> > > Signed-off-by: Tom Rini <tr...@ti.com>
> > >
> > > ---
> > > Changes in v1:
> > > - Adopt to Mark Rutland's changes now in mainline kernel wrt text_offset
> > > / image_size
> > > ---
> > > README | 1 +
> > > common/cmd_bootm.c | 140
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > include/bootm.h | 2 +-
> > > 3 files changed, 142 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/README b/README
> > > index 1d71359..b9af7ac 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -959,6 +959,7 @@ The following options need to be configured:
> > > CONFIG_CMD_BMP * BMP support
> > > CONFIG_CMD_BSP * Board specific commands
> > > CONFIG_CMD_BOOTD bootd
> > > + CONFIG_CMD_BOOTI * ARM64 Linux kernel Image support
> > > CONFIG_CMD_CACHE * icache, dcache
> > > CONFIG_CMD_CLK * clock command support
> > > CONFIG_CMD_CONSOLE coninfo
> > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
> > > index 8b897c8d..843ec6e 100644
> > > --- a/common/cmd_bootm.c
> > > +++ b/common/cmd_bootm.c
> > > @@ -627,3 +627,143 @@ U_BOOT_CMD(
> > > "boot Linux zImage image from memory", bootz_help_text
> > > );
> > > #endif /* CONFIG_CMD_BOOTZ */
> > > +
> > > +#ifdef CONFIG_CMD_BOOTI
> > > +/* See Documentation/arm64/booting.txt in the Linux kernel */
> > > +struct Image_header {
> > > + uint32_t code0; /* Executable code */
> > > + uint32_t code1; /* Executable code */
> > > + uint64_t text_offset; /* Image load offset, LE */
> > > + uint64_t image_size; /* Effective Image size, LE */
> > > + uint64_t res1; /* reserved */
> > > + uint64_t res2; /* reserved */
> > > + uint64_t res3; /* reserved */
> > > + uint64_t res4; /* reserved */
> > > + uint32_t magic; /* Magic number */
> > > + uint32_t res5;
> > > +};
> > > +
> > > +#define LINUX_ARM64_IMAGE_MAGIC 0x644d5241
> > > +
> > > +static int booti_setup(bootm_headers_t *images)
> > > +{
> > > + struct Image_header *ih;
> > > + uint64_t dst;
> > > +
> > > + ih = (struct Image_header *)map_sysmem(images->ep, 0);
> > > +
> > > + if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
> > > + puts("Bad Linux ARM64 Image magic!\n");
> > > + return 1;
> > > + }
> > > +
> > > + if (ih->image_size == 0) {
> > > + puts("Image lacks image_size field, assuming 16MiB\n");
> > > + ih->image_size = (16 << 20);
> > > + }
> >
> > This should work for a defconfig, but it might be possible to build a
> > larger kernel. From experiments with an allyesconfig, I can build a
> > ~60MB kernel with ~20MB of uninitialised data after the end of the
> > Image.
>
> Part of me just wants to error out in this case. Today people are
> wrapping vmlinux up with a legacy header and making uImages. My hope is
> that with this and 3.17 we can encourage Image/Image.*/FIT Image usage
> instead. We could just as easily whack in 128MB, all the same.
Sure, it's unlikely that someone will build that big a (< v3.17) kernel
for reasons other than breaking things. I just thought I should mention
in case this crops up again.
> > Modifying the Image feels a little dodgy, but I can't think of anything
> > this would break.
>
> Yeah. In my mind, an Image without this information is the corner case,
> not the normal case. Doing it this way (a fixup to the data) means we
> don't have to error check this twice or play some other games.
Ok. As I said I can't think of anything this should break. This should
only affect older kernels so shouldn't be a problem going forward.
Prior to v3.17 you'll also find the text_offset field could be in an
arbitrary endianness, though should always have value 0x80000. So if you
want to boot BE (< v3.17) kernels you'd have to fix that up too. Post
v3.17 it's subject to randomization.
Cheers,
Mark.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
