[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[panchaxari]

ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs
to S5P64X0 platforms.

Introduction of PHYS_VIRT config as default would enable phy-to-virt and
virt-to-phy translation function at boot and module loading time
and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
enable calculation of kernel load address at run time.

PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
systems with NOR flash devices, and ZRELADDR config is mutually exclusive
to ZBOOT_ROM.

CFT::Call For Testing

Requesting maintainers of S5P64X0 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 <panchaxari.prasannamurthy@linaro.org>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Tomasz Figa <tomasz.figa@gmail.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-samsung-soc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org

---
The samsung S5P64X0 vega has an average performing CPU with max speed 667 Mhz.
This SOC has two variants S5P6440 and S5P6450. It has one core based on
ARM1176JZF-S instruction set, and has 16KB data and instruction cache each.

SOC has a memory subsystem with support to NAND Flash interface with x8 data
bus, with 1/4/8/12/16 bit hardware ECC circuit and 4KB Page mode. It has
Mobile DDR interface with x16 or x32 data bus, and DDR2 interface with x16 or
x32 data bus it also supports eMMC4.4.

Below lkml link is a quoting by Russell which clears the concept of PHYS_VIRT
and ZRELADDR
-------------------------------------------------

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

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

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 934e26c..8986335 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -759,6 +759,8 @@ config ARCH_S3C64XX
 
 config ARCH_S5P64X0
 	bool "Samsung S5P6440 S5P6450"
+	select ARM_PATCH_PHYS_VIRT
+	select AUTO_ZRELADDR
 	select CLKDEV_LOOKUP
 	select CLKSRC_SAMSUNG_PWM
 	select CPU_V6
-- 
1.7.10.4

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Tomasz Figa]

Hi panchaxari,

On Thursday 12 of December 2013 10:42:32 panchaxari wrote:
> ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR have been enabled as default configs
> to S5P64X0 platforms.
> 
> Introduction of PHYS_VIRT config as default would enable phy-to-virt and
> virt-to-phy translation function at boot and module loading time
> and enforce dynamic reallocation of memory. AUTO_ZRELADDR config would
> enable calculation of kernel load address at run time.
> 
> PHYS_VIRT config is mutually exclusive to XIP_KERNEL, XIP_KERNEL is used in
> systems with NOR flash devices, and ZRELADDR config is mutually exclusive
> to ZBOOT_ROM.
> 
> CFT::Call For Testing
> 
> Requesting maintainers of S5P64X0 platforms to evaluate the changes on the
> board and comment, as I dont have the board for testing and also requesting
> an ACK

Could you explain the purpose of this change on S5P64x0?

This is actually quite a poor platform choice. As of today, the kernel
is stuck with supporting just SMDK6440/6450 boards, which are proprietary
development boards and it doesn't look like any further boards will show
up in future. Kukjin has actually proposed removing support for this
platform at all and I consider this reasonable.

Kukjin, should we proceed with removal?

Best regards,
Tomasz

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Panchaxari Prasannamurthy Tumkur]

Hi Tomasz

> Could you explain the purpose of this change on S5P64x0?
>
> This is actually quite a poor platform choice. As of today, the kernel
> is stuck with supporting just SMDK6440/6450 boards, which are proprietary
> development boards and it doesn't look like any further boards will show
> up in future. Kukjin has actually proposed removing support for this
> platform at all and I consider this reasonable.
>
> Kukjin, should we proceed with removal?

The purpose of this patch is with the greater intent of consolidating
ARM-32 kernel. Which means a generic kernel for ARM-32 processors.

Hence these platform supported configs are introduced as default for
that particular platform.

I hope i answered your question. Else please mail me with further queries.

thanks
Panchaxari

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Tomasz Figa]

On Thursday 12 of December 2013 16:33:46 Panchaxari Prasannamurthy Tumkur wrote:
> Hi Tomasz
> 
> > Could you explain the purpose of this change on S5P64x0?
> >
> > This is actually quite a poor platform choice. As of today, the kernel
> > is stuck with supporting just SMDK6440/6450 boards, which are proprietary
> > development boards and it doesn't look like any further boards will show
> > up in future. Kukjin has actually proposed removing support for this
> > platform at all and I consider this reasonable.
> >
> > Kukjin, should we proceed with removal?
> 
> The purpose of this patch is with the greater intent of consolidating
> ARM-32 kernel. Which means a generic kernel for ARM-32 processors.

OK. So do you have plans to send similar patches for other, more active
(and closer to having multiplatform support) platforms, such as s3c64xx,
s5pv210 and exynos?

In case of s5p64x0 probably the only person capable of testing it is
Kukjin, as we don't have any other active people with boards based on
these SoCs.

Best regards,
Tomasz

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Panchaxari Prasannamurthy Tumkur]

> OK. So do you have plans to send similar patches for other, more active
> (and closer to having multiplatform support) platforms, such as s3c64xx,
> s5pv210 and exynos?
>
> In case of s5p64x0 probably the only person capable of testing it is
> Kukjin, as we don't have any other active people with boards based on
> these SoCs.

Yes I have, Exynos is already sent, s3c64xx and s5pv210 are in pipeline.
I shall send them shortly.

thanks for your guidance.

regards
pancham

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Linus Walleij]

On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:

> This is actually quite a poor platform choice. As of today, the kernel
> is stuck with supporting just SMDK6440/6450 boards, which are proprietary
> development boards and it doesn't look like any further boards will show
> up in future. Kukjin has actually proposed removing support for this
> platform at all and I consider this reasonable.
>
> Kukjin, should we proceed with removal?

Isn't Mark Brown using that platform for some various stuff?

Yours,
Linus Walleij

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Tomasz Figa]

2013/12/12 Linus Walleij <linus.walleij@linaro.org>:
> On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>
>> This is actually quite a poor platform choice. As of today, the kernel
>> is stuck with supporting just SMDK6440/6450 boards, which are proprietary
>> development boards and it doesn't look like any further boards will show
>> up in future. Kukjin has actually proposed removing support for this
>> platform at all and I consider this reasonable.
>>
>> Kukjin, should we proceed with removal?
>
> Isn't Mark Brown using that platform for some various stuff?

Not as far as I know.

He's using Cragganmore board based on s3c6410, but this is a different
platform (s3c64xx).

Best regards,
Tomasz

[PATCH CFT] ARM:S5P64X0: Enable ARM_PATCH_PHYS_VIRT and AUTO_ZRELADDR by default

[Linus Walleij]

On Thu, Dec 12, 2013 at 10:22 PM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
> 2013/12/12 Linus Walleij <linus.walleij@linaro.org>:
>> On Thu, Dec 12, 2013 at 10:47 AM, Tomasz Figa <tomasz.figa@gmail.com> wrote:
>>
>>> This is actually quite a poor platform choice. As of today, the kernel
>>> is stuck with supporting just SMDK6440/6450 boards, which are proprietary
>>> development boards and it doesn't look like any further boards will show
>>> up in future. Kukjin has actually proposed removing support for this
>>> platform at all and I consider this reasonable.
>>>
>>> Kukjin, should we proceed with removal?
>>
>> Isn't Mark Brown using that platform for some various stuff?
>
> Not as far as I know.
>
> He's using Cragganmore board based on s3c6410, but this is a different
> platform (s3c64xx).

Ahhhh I see it now. So the S3C:s are actually in a lot of use
and the S5P is one of those stepping stones to Exynos that
never really was in any widespread use.

Yeah I'm all for deleteing that :-)

Thanks!
Linus Walleij