2014-01-09 04:45:33

by panchaxari

[permalink] [raw]
Subject: [PATCH CFT] ARM:REALVIEW: Enable AUTO_ZRELADDR by default

This patch enables AUTO_ZRELADDR as default config to Realview platform.

AUTO_ZRELADDR config enables auto calculation of the decompressed kernel image
address. AUTO_ZRELADDR config is mutually exclusive to ZBOOT_ROM, and also
assumes zImage to be loaded in the first 128MiB from start of memory.

CFT::Call For Testing

Requesting maintainers of Realview platforms to evaluate the changes on the
board and comment, as I dont have the board for testing, and also requesting
an ACK.

Signed-off-by: panchaxari <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Pawel Moll <[email protected]>
Cc: Russell King <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Viresh Kumar <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Linus Walleij <[email protected]>
Cc: [email protected]
Cc: [email protected]

---
Below lkml link is a quoting by Russell, which explains more on concept of
PHYS_VIRT and ZRELADDR
-------------------------------------------------

https://lkml.org/lkml/2011/10/14/434

-------------------------------------------------
---
arch/arm/Kconfig | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3dfc3b8..077ef9d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -332,6 +332,7 @@ config ARCH_REALVIEW
select ARCH_WANT_OPTIONAL_GPIOLIB
select ARM_AMBA
select ARM_TIMER_SP804
+ select AUTO_ZRELADDR
select COMMON_CLK
select COMMON_CLK_VERSATILE
select GENERIC_CLOCKEVENTS
--
1.7.10.4


2014-01-09 10:03:08

by Russell King - ARM Linux

[permalink] [raw]
Subject: Re: [PATCH CFT] ARM:REALVIEW: Enable AUTO_ZRELADDR by default

On Thu, Jan 09, 2014 at 10:14:14AM +0530, panchaxari wrote:
> Below lkml link is a quoting by Russell, which explains more on concept of
> PHYS_VIRT and ZRELADDR
> -------------------------------------------------
>
> https://lkml.org/lkml/2011/10/14/434
>
> -------------------------------------------------

Okay, so you're just going around changing stuff, basing it on an old mail,
and not testing the results of it. Stop this please.

Note that the result of the above email was this:

commit c1becedc8871645278832fabdc6fe138082a495b
Author: Russell King <[email protected]>
Date: Wed Aug 10 10:23:45 2011 +0100

ARM: enable ARM_PATCH_PHYS_VIRT by default

Enable virtual to physical translation patching by default in all
kernels. Hide the option behind EMBEDDED.

This can still be turned off if people desire, and they know what
they're doing, to shrink the size of the kernel to a minimum.

Acked-by: Will Deacon <[email protected]>
Signed-off-by: Russell King <[email protected]>

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5ebc5d922ea1..8882a535cf44 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -195,7 +195,8 @@ config VECTORS_BASE
The base address of exception vectors.

config ARM_PATCH_PHYS_VIRT
- bool "Patch physical to virtual translations at runtime"
+ bool "Patch physical to virtual translations at runtime" if EMBEDDED
+ default y
depends on !XIP_KERNEL && MMU
depends on !ARCH_REALVIEW || !SPARSEMEM
help
@@ -207,6 +208,10 @@ config ARM_PATCH_PHYS_VIRT
of physical memory is at a 16MB boundary, or theoretically 64K
for the MSM machine class.

+ Only disable this option if you know that you do not require
+ this feature (eg, building a kernel for a single machine) and
+ you need to shrink the kernel to the minimal size.


which means that ARM_PATCH_PHYS_VIRT is enabled for virtually everything
unless you decide that you want to enable EMBEDDED mode, in which case
you get the chance to manually disable it.

In fact, all those select ARM_PATCH_PHYS_VIRT are wrong, and add reverse
dependencies that make maintanence of the Kconfig harder. I'd rather kill
all those select statements rather than introduce yet more of them.

Hence, all your recent patches adding "select ARM_PATCH_PHYS_VIRT" I say
a very strong NAK to.

--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".