All of lore.kernel.org
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: i.MX consolidation patches
Date: Thu, 2 Jun 2011 12:23:02 +0100	[thread overview]
Message-ID: <20110602112302.GV3660@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110602103407.GA32632@pengutronix.de>

On Thu, Jun 02, 2011 at 12:34:07PM +0200, Sascha Hauer wrote:
> > * Assuming all ARM kernels are PIC (guaranteed, right?)
> 
> zImages are. The restriction here is:
> 
> config AUTO_ZRELADDR
>         bool "Auto calculation of the decompressed kernel image address"
>         depends on !ZBOOT_ROM && !ARCH_U300
>         help
>           ZRELADDR is the physical address where the decompressed kernel
>           image will be placed. If AUTO_ZRELADDR is selected, the address
>           will be determined at run-time by masking the current IP with
>           0xf8000000. This assumes the zImage being placed in the first 128MB
>           from start of memory.
> 
> So U-Boot could interpret load address being set to 0xffffffff as 'put it
> somewhere in the first 128MB it jump to this address'.

Sascha, I think you're mixing stuff up.

The decompressor is carefully coded to be relocatable provided ZBOOT_ROM=n.
This will be the case for all zImages built to run from RAM.  ZBOOT_ROM
needs to be set to 'y' if you're building a zImage to run directly from
flash, in which case you're not copying it into RAM first.

Even a ZBOOT_ROM=y image can be booted from RAM, but there are additional
restrictions on its placement (as it has the .bss address in RAM hard-coded.)
But let's ignore this case because it adds far more complexity than is
required.

The only thing to bear in mind is that we place the page tables at 16K
into RAM, so the zImage should not be loaded below the low 32K of RAM.
So that implies that uboot must not load a 'relocatable' uImage below
START_OF_RAM + 32K.

Now, AUTO_ZRELADDR allows us to calculate where to place the _decompressed_
kernel by placing it 32K into the start of the 128MB region which the
decompressor is running from.  So that restricts the upper boundary to
START_OF_RAM + 128M.

Note that it's fine to place the decompressor where the decompressed
image will be located, as the decompressor sorts itself out.  However,
that does add some additional overhead, so it may be worth making this
offset a parameter which can be set in uboot.  Default it to 32K, but
allow users to change it if they want to avoid that overlap.

> > * Assuming all ARM kernels start at entry point 0 (true for Image and zImage)
> 
> You mean that the entry point is load address + 0? That should be true.
> Even if not, when the load address is 0xffffffff, the entry point field
> could still describe an offset into the image.

All ARM kernels are entered at the first address of the image.

  reply	other threads:[~2011-06-02 11:23 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-19 16:47 Sascha Hauer
2011-05-19 16:47 ` [PATCH 1/8] ARM i.MX: fix last user of iomux.h and remove it Sascha Hauer
2011-05-19 16:47 ` [PATCH 2/8] ARM i.MX: define CLOCK_TICK_RATE to bogus value Sascha Hauer
2011-05-19 16:47 ` [PATCH 3/8] ARM i.MX: remove SoC defines around header includes Sascha Hauer
2011-05-19 16:47 ` [PATCH 4/8] ARM i.MX: dmav1: kill SoC ifdefs Sascha Hauer
2011-05-19 16:47 ` [PATCH 5/8] ARM i.MX Allow to compile together i.MX1/21/25/27 Sascha Hauer
2011-05-19 18:04   ` Uwe Kleine-König
2011-05-19 19:03     ` Sascha Hauer
2011-05-19 19:44       ` Nicolas Pitre
2011-05-19 19:50         ` Sascha Hauer
2011-06-01 13:22   ` [PATCH 5/8 v2] " Sascha Hauer
2011-06-01 13:25     ` Russell King - ARM Linux
2011-06-01 15:24     ` Arnd Bergmann
2011-06-01 16:47       ` Sascha Hauer
2011-06-01 17:59         ` Arnd Bergmann
2011-05-19 16:47 ` [PATCH 6/8] ARM i.MX mxc.h: use CONFIG_SOC_* instead of CONFIG_ARCH_* Sascha Hauer
2011-05-19 16:47 ` [PATCH 7/8] ARM i.MX debug macro: " Sascha Hauer
2011-05-19 16:54   ` Sergei Shtylyov
2011-05-19 19:07     ` Sascha Hauer
2011-05-19 16:47 ` [PATCH 8/8] ARM: mxc: update defconfigs Sascha Hauer
2011-05-30  7:57 ` i.MX consolidation patches Shawn Guo
2011-06-01 12:35   ` Sascha Hauer
2011-06-01 13:47     ` Russell King - ARM Linux
2011-06-01 14:18       ` Sascha Hauer
2011-06-01 14:24         ` Russell King - ARM Linux
2011-06-01 14:36           ` Sascha Hauer
2011-06-01 14:59             ` Uwe Kleine-König
2011-06-22  7:56           ` Sascha Hauer
2011-06-22  8:11             ` Russell King - ARM Linux
2011-06-22  8:32               ` Sascha Hauer
2011-06-22  9:03                 ` Russell King - ARM Linux
2011-06-22 14:58                   ` Sascha Hauer
2011-06-22 15:10                     ` Arnd Bergmann
2011-06-22 15:14                       ` Russell King - ARM Linux
2011-06-22 15:23                         ` Arnd Bergmann
2011-06-22 15:22                     ` Russell King - ARM Linux
2011-06-22 16:35                       ` Sascha Hauer
2011-06-01 21:08         ` Wolfgang Denk
2011-06-01 23:04           ` Matt Sealey
2011-06-02 10:34             ` Sascha Hauer
2011-06-02 11:23               ` Russell King - ARM Linux [this message]
2011-06-02 15:46             ` Wolfgang Denk
2011-06-02 23:59               ` Matt Sealey
2011-06-03 12:02               ` Sascha Hauer
2011-06-03 12:17                 ` Wolfgang Denk
2011-06-03 14:18                   ` Sascha Hauer

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=20110602112302.GV3660@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --subject='Re: i.MX consolidation patches' \
    /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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.