linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD
Date: Wed, 7 Mar 2012 21:28:05 +0000	[thread overview]
Message-ID: <20120307212805.GE18787@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <4F57C4C6.2070602@wwwdotorg.org>

On Wed, Mar 07, 2012 at 01:27:50PM -0700, Stephen Warren wrote:
> Thinking more about this, I guess the reliance on AUTO_ZRELADDR is wrong
> here; Russell, Nico, is the ARM decompressor fully position-independent
> irrespective of the AUTO_ZRELADDR setting.

The standard decompressor is fully relocatable into any part of the system
which contains sufficient _RAM_ to contain the size of the zImage plus 64k
malloc space (that's including the BSS for the zImage.)

AUTO_ZRELADDR controls how the _decompressed_ kernel is placed, whether
it is placed at a fixed address controlled by the zreladdr-y symbol
in arch/arm/mach-*/Makefile.boot, or whether it is controlled by where
the zImage is placed - iow, (phys address & 0xf8000000) + TEXT_OFFSET.

> That setting just determines
> where the decompressor writes its output, not what address the
> decompressor can run at, right? So, this KERNEL_NOLOAD feature could be
> enabled in all cases on ARM, not only when AUTO_ZRELADDR is enabled.

I'm not entirely sure about that - there's at least the uboot on some
of the ARM devel platforms which relocates things like the ATAG list if
it's loading a uImage at 0x60008000 vs 0x00008000 (and we want it to be
at the 0x60008000 address so it can see 1GB of memory rather than just
256MB via the low mapping.)

So in some cases we do need control over where the uImage (or zImage)
is loaded by the boot loader.

> In other words:
> 
> We already have and need ZRELADDR no matter what, for reasons unrelated
> to U-Boot/uImage.

That's a tad icky... because a !AUTO_ZRELADDR kernel has no need for a
load address provided it ends up in RAM.  So, uboot enforcing a specific
load address more of an inconvenience rather than a problem.

However, for AUTO_ZRELADDR, the zImage does have to be placed in the
same 128M aligned block of RAM which you want the start of it to be
called PHYS_OFFSET.  So in that sense, an AUTO_ZRELADDR kernel is
more critical with its placement than a !AUTO_ZRELADDR kernel.

  parent reply	other threads:[~2012-03-07 21:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-07  0:30 [PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions Stephen Warren
2012-03-07  0:30 ` [PATCH 2/3] Kbuild: Implement CONFIG_UIMAGE_KERNEL_NOLOAD Stephen Warren
2012-03-07  0:52   ` Julian Calaby
2012-03-07  6:52   ` Guan Xuetao
2012-03-07 18:10     ` Stephen Warren
2012-03-07 18:08   ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 18:40     ` Stephen Warren
2012-03-07 18:36       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 19:02         ` Nicolas Pitre
2012-03-07 20:27         ` Stephen Warren
2012-03-07 21:03           ` Nicolas Pitre
2012-03-07 21:30             ` Russell King - ARM Linux
2012-03-07 22:43               ` Nicolas Pitre
2012-03-07 21:28           ` Russell King - ARM Linux [this message]
2012-03-07 18:50     ` Nicolas Pitre
2012-03-07 19:08       ` Jean-Christophe PLAGNIOL-VILLARD
2012-03-07 19:31         ` Nicolas Pitre
2012-03-07  0:30 ` [PATCH 3/3] ARM: Allow the user to enable UIMAGE_KERNEL_NOLOAD Stephen Warren
2012-03-07  3:56 ` [PATCH 1/3] Kbuild: centralize MKIMAGE and cmd_uimage definitions Mike Frysinger
2012-03-07 17:41   ` Stephen Warren
2012-03-07 18:25     ` Mike Frysinger
2012-03-07  9:00 ` Hans-Christian Egtvedt
2012-03-07 14:15 ` Josh Boyer
2012-03-07 18:29   ` Stephen Warren

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=20120307212805.GE18787@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --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).