From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm/tegra: select AUTO_ZRELADDR by default
Date: Fri, 14 Oct 2011 20:20:11 +0100 [thread overview]
Message-ID: <20111014192011.GS21648@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <CAOesGMgDwMeVmwo1WJ3tU+ZdjCSJ6F8mY42e_KwTmzAkGQsqmg@mail.gmail.com>
On Fri, Oct 14, 2011 at 09:44:34AM -0700, Olof Johansson wrote:
> That is likely to get messy.
>
> Seems like there could be some use for a (silent) option for a
> platform to indicate that it can do XIP kernel (or zImage), and thus
> not able to use AUTO_ZRELADDR (or other options that require rewriting
> text segment of zImage or kernel).
It's not that.
The options are:
AUTO_ZRELADDR=n ZBOOT_ROM=n => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address.
AUTO_ZRELADDR=y ZBOOT_ROM=n => address for decompressed kernel calculated
from location of zImage in RAM, decompressor must be loaded to
the correct place in RAM and must always copy itself out of
the way prior to decompressing.
AUTO_ZRELADDR=n ZBOOT_ROM=y => fixed address for decompressed kernel
image to be decompressed to from zreladdr make variable,
decompressor can be loaded to any RAM address which doesn't
overlap its BSS segment, or decompressor programmed into
read-only memory at the address to which it was compiled.
AUTO_ZRELADDR=y ZBOOT_ROM=y => invalid (think about it - this results
in a zImage which is built to be run from read-only memory,
and try to write the decompressed image into that read-only
memory.)
This has nothing to do with XIP or not - XIP is a completely separate story,
and if you're building an XIP kernel you're not using the decompressor (so
AUTO_ZRELADDR and ZBOOT_ROM don't even feature.) Neither does the dynamic
code patching stuff like ARM_PATCH_PHYS_VIRT.
ARM_PATCH_PHYS_VIRT has no bearing on AUTO_ZRELADDR or ZBOOT_ROM; that is
a property of the decompressed kernel image itself, and while your
decompressor may restrict where it can decompress the kernel image to,
the decompressed image itself remains free of those dependencies (and
eg, can be turned into a uImage with the appropriate load address
for other platforms.)
As I've said in the past, what I'd _like_ to see is that ARM_PATCH_PHYS_VIRT
be enabled for everything irrespective of any other configuration, and
we're just left with AUTO_ZRELADDR / ZBOOT_ROM to worry about. The
overhead from the P:V patching is soo small that it's not really worth
even having the option in the general case - the only time when P:V
patching doesn't work is with non-linear translations found on some
sparsemem platforms.
But... one thing to note is that it _is_ common to load the decompressor
at a _different_ address to that where the kernel ultimately ends up
residing to avoid the additional copy in the decompressor. My experience
shows that this is quite common on the platforms I had supplied. This
means that if we default to AUTO_ZRELADDR for !ZBOOT_ROM, we end up
having to have developers change their uboot setups to avoid unexpected
results.
next prev parent reply other threads:[~2011-10-14 19:20 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-28 1:07 [PATCH] arm/tegra: select AUTO_ZRELADDR by default Peter De Schrijver
2011-09-28 17:50 ` Stephen Warren
2011-10-13 23:38 ` Olof Johansson
2011-10-14 7:15 ` Russell King - ARM Linux
2011-10-14 14:45 ` Stephen Warren
2011-10-14 15:29 ` Arnd Bergmann
2011-10-14 16:12 ` Stephen Warren
2011-10-14 16:27 ` Arnd Bergmann
2011-10-14 16:44 ` Olof Johansson
2011-10-14 18:03 ` Nicolas Pitre
2011-10-14 19:20 ` Russell King - ARM Linux [this message]
2011-10-14 20:06 ` Nicolas Pitre
2011-10-14 20:12 ` Russell King - ARM Linux
2011-10-14 20:16 ` Stephen Warren
2011-10-14 20:19 ` Russell King - ARM Linux
2011-10-15 15:29 ` Tixy
2011-10-14 20:26 ` Nicolas Pitre
2011-10-14 20:14 ` Stephen Warren
2011-10-14 20:45 ` Nicolas Pitre
2011-10-14 21:01 ` Stephen Warren
2011-10-14 21:28 ` Nicolas Pitre
2011-10-14 22:06 ` Rob Herring
2011-10-14 18:01 ` Nicolas Pitre
2011-10-14 19:20 ` Russell King - ARM Linux
2011-10-14 20:14 ` Nicolas Pitre
2011-10-14 20:17 ` Russell King - ARM Linux
2011-10-14 20:31 ` Nicolas Pitre
2011-10-14 21:13 ` Russell King - ARM Linux
2011-10-14 22:26 ` Nicolas Pitre
2011-10-14 17:53 ` Nicolas Pitre
2011-10-14 17:58 ` Olof Johansson
2011-10-14 18:00 ` Olof Johansson
2011-10-14 15:59 ` [PATCH] ARM: mutually exclude ZBOOT_ROM and AUTO_ZRELADDR Olof Johansson
2011-10-14 16:29 ` Arnd Bergmann
2011-10-14 18:07 ` Nicolas Pitre
2011-10-14 18:04 ` Nicolas Pitre
-- strict thread matches above, loose matches on Subject: below --
2011-10-03 13:06 [PATCH v6 0/3] Add support for tegra2 based ventana board Peter De Schrijver
2011-10-03 13:06 ` [PATCH] arm/tegra: select AUTO_ZRELADDR by default Peter De Schrijver
2011-10-03 13:13 ` Peter De Schrijver
2011-10-03 16:22 ` Stephen Warren
2011-10-04 8:51 ` Peter De Schrijver
2011-09-22 13:27 Peter De Schrijver
2011-09-22 16:26 ` Stephen Warren
2011-09-22 17:58 ` Peter De Schrijver
2011-09-22 18:06 ` Colin Cross
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=20111014192011.GS21648@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).