[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Magnus Damm]

ARM: 64-bit memory fixes, APE6EVM second memory bank

[PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
[PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
[PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM

This patch set contains two fixes and one mach-shmobile specific patch
to add a second memory bank. The fixes attempt to improve the memory bank
handling in the ARM kernel in case of 64-bit addresses.

Without patch 1/3 and 2/3 but with patch 3/3 by itself:

HIGHMEM=n, LPAE=n - OK (busted, second bank ignored with message [1])
HIGHMEM=y, LPAE=n - NG (busted, board hangs on boot)
HIGHMEM=n, LPAE=y - OK
HIGHMEM=y, LPAE=y - OK

[1] Ignoring RAM at 00000000-3fffffff (vmalloc region overlap).

With all patches applied:

HIGHMEM=n, LPAE=n - OK
HIGHMEM=y, LPAE=n - OK
HIGHMEM=n, LPAE=y - OK
HIGHMEM=y, LPAE=y - OK

My opinion is that LPAE should be handled in a similar way to x86 PAE.
This means the kernel should boot regardless of kernel config but 64-bit
memory banks may be truncated if needed like when LPAE=n or HIGHMEN=n.

Comments on how to implement this in a nicer way are very welcome!

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 Written against renesas.git renesas-next-20130604v2

 arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
 arch/arm/include/asm/setup.h          |    2 +-
 arch/arm/kernel/setup.c               |   22 +++++++++++++++-------
 3 files changed, 21 insertions(+), 8 deletions(-)

[PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

The DTB and/or the kernel command line may pass
64-bit addresses regardless of kernel configuration,
so update arm_add_memory() to take 64-bit arguments
independently of the phys_addr_t size.

This allows non-wrapping handling of high memory
banks such as the second memory bank of APE6EVM
(at 0x2_0000_0000) in case of 32-bit phys_addr_t.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/include/asm/setup.h |    2 +-
 arch/arm/kernel/setup.c      |    6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

--- 0001/arch/arm/include/asm/setup.h
+++ work/arch/arm/include/asm/setup.h	2013-06-05 18:47:09.000000000 +0900
@@ -49,7 +49,7 @@ extern struct meminfo meminfo;
 #define bank_phys_end(bank)	((bank)->start + (bank)->size)
 #define bank_phys_size(bank)	(bank)->size
 
-extern int arm_add_memory(phys_addr_t start, phys_addr_t size);
+extern int arm_add_memory(u64 start, u64 size);
 extern void early_print(const char *str, ...);
 extern void dump_machine_table(void);
 
--- 0001/arch/arm/kernel/setup.c
+++ work/arch/arm/kernel/setup.c	2013-06-05 18:47:34.000000000 +0900
@@ -527,7 +527,7 @@ void __init dump_machine_table(void)
 		/* can't use cpu_relax() here as it may require MMU setup */;
 }
 
-int __init arm_add_memory(phys_addr_t start, phys_addr_t size)
+int __init arm_add_memory(u64 start, u64 size)
 {
 	struct membank *bank = &meminfo.bank[meminfo.nr_banks];
 
@@ -577,8 +577,8 @@ int __init arm_add_memory(phys_addr_t st
 static int __init early_mem(char *p)
 {
 	static int usermem __initdata = 0;
-	phys_addr_t size;
-	phys_addr_t start;
+	u64 size;
+	u64 start;
 	char *endp;
 
 	/*

[PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t

[Magnus Damm]

From: Magnus Damm <damm@opensource.se>

Use CONFIG_ARCH_PHYS_ADDR_T_64BIT to determine
if ignoring or truncating of memory banks is
neccessary. This may be needed in the case of
64-bit memory bank addresses but when phys_addr_t
is kept 32-bit.

Signed-off-by: Magnus Damm <damm@opensource.se>
---

 Ignoring case tested on APE6EVM in cases when
 HIGHMEM=y/n and LPAE=y/n. Truncating not tested.

 arch/arm/kernel/setup.c |   16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

--- 0003/arch/arm/kernel/setup.c
+++ work/arch/arm/kernel/setup.c	2013-06-05 19:08:17.000000000 +0900
@@ -530,6 +530,7 @@ void __init dump_machine_table(void)
 int __init arm_add_memory(u64 start, u64 size)
 {
 	struct membank *bank = &meminfo.bank[meminfo.nr_banks];
+	u64 aligned_start;
 
 	if (meminfo.nr_banks >= NR_BANKS) {
 		printk(KERN_CRIT "NR_BANKS too low, "
@@ -542,10 +543,16 @@ int __init arm_add_memory(u64 start, u64
 	 * Size is appropriately rounded down, start is rounded up.
 	 */
 	size -= start & ~PAGE_MASK;
-	bank->start = PAGE_ALIGN(start);
+	aligned_start = PAGE_ALIGN(start);
 
-#ifndef CONFIG_ARM_LPAE
-	if (bank->start + size < bank->start) {
+#ifndef CONFIG_ARCH_PHYS_ADDR_T_64BIT
+	if (aligned_start > ULONG_MAX) {
+		printk(KERN_CRIT "Ignoring memory at 0x%08llx outside "
+		       "32-bit physical address space\n", (long long)start);
+		return -EINVAL;
+	}
+
+	if (aligned_start + size > ULONG_MAX) {
 		printk(KERN_CRIT "Truncating memory at 0x%08llx to fit in "
 			"32-bit physical address space\n", (long long)start);
 		/*
@@ -553,10 +560,11 @@ int __init arm_add_memory(u64 start, u64
 		 * 32 bits, we use ULONG_MAX as the upper limit rather than 4GB.
 		 * This means we lose a page after masking.
 		 */
-		size = ULONG_MAX - bank->start;
+		size = ULONG_MAX - aligned_start;
 	}
 #endif
 
+	bank->start = aligned_start;
 	bank->size = size & ~(phys_addr_t)(PAGE_SIZE - 1);
 
 	/*

[PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM

[Magnus Damm]

From: Takashi Yoshii <takashi.yoshii.zj@renesas.com>

Add 1GiB of DRAM at 0x2_0000_0000 to APE6EVM

Signed-off-by: Takashi Yoshii <takashi.yoshii.zj@renesas.com>
Signed-off-by: Magnus Damm <damm@opensource.se>
---

 arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
 1 file changed, 5 insertions(+)

--- 0001/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ work/arch/arm/boot/dts/r8a73a4-ape6evm.dts	2013-04-08 10:27:20.000000000 +0900
@@ -24,6 +24,11 @@
 		reg = <0 0x40000000 0 0x40000000>;
 	};
 
+	memory at 200000000 {
+		device_type = "memory";
+		reg = <2 0x00000000 0 0x40000000>;
+	};
+
 	ape6evm_fixed_3v3: fixedregulator at 0 {
 		compatible = "regulator-fixed";
 		regulator-name = "3V3";

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Arnd Bergmann]

On Wednesday 05 June 2013, Magnus Damm wrote:
> ARM: 64-bit memory fixes, APE6EVM second memory bank
> 
> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
> 
> This patch set contains two fixes and one mach-shmobile specific patch
> to add a second memory bank. The fixes attempt to improve the memory bank
> handling in the ARM kernel in case of 64-bit addresses.

Please have a look at this patch that Stepan Moskovchenko posted:

https://patchwork.kernel.org/patch/2639171/

I think we are going to need only one of the two approaches.

	Arnd

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Magnus Damm]

Hi Arnd,

On Wed, Jun 5, 2013 at 8:17 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 05 June 2013, Magnus Damm wrote:
>> ARM: 64-bit memory fixes, APE6EVM second memory bank
>>
>> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
>> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
>> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
>>
>> This patch set contains two fixes and one mach-shmobile specific patch
>> to add a second memory bank. The fixes attempt to improve the memory bank
>> handling in the ARM kernel in case of 64-bit addresses.
>
> Please have a look at this patch that Stepan Moskovchenko posted:
>
> https://patchwork.kernel.org/patch/2639171/
>
> I think we are going to need only one of the two approaches.

Thanks for pointing out this implementation. Is there anything I can
do to move this forward?

Cheers,

/ magnus

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Arnd Bergmann]

On Wednesday 12 June 2013, Magnus Damm wrote:
> On Wed, Jun 5, 2013 at 8:17 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Wednesday 05 June 2013, Magnus Damm wrote:
> >> ARM: 64-bit memory fixes, APE6EVM second memory bank
> >>
> >> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
> >> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
> >> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
> >>
> >> This patch set contains two fixes and one mach-shmobile specific patch
> >> to add a second memory bank. The fixes attempt to improve the memory bank
> >> handling in the ARM kernel in case of 64-bit addresses.
> >
> > Please have a look at this patch that Stepan Moskovchenko posted:
> >
> > https://patchwork.kernel.org/patch/2639171/
> >
> > I think we are going to need only one of the two approaches.
> 
> Thanks for pointing out this implementation. Is there anything I can
> do to move this forward?

I'm fine with either solution. If Russell doesn't have a preference
one way or the other, I'd suggest you agree with Stepan on one of the
two and put that into the patch tracker.

	Arnd

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Guennadi Liakhovetski]

On Wed, 5 Jun 2013, Magnus Damm wrote:

> ARM: 64-bit memory fixes, APE6EVM second memory bank
> 
> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
> 
> This patch set contains two fixes and one mach-shmobile specific patch
> to add a second memory bank. The fixes attempt to improve the memory bank
> handling in the ARM kernel in case of 64-bit addresses.
> 
> Without patch 1/3 and 2/3 but with patch 3/3 by itself:
> 
> HIGHMEM=n, LPAE=n - OK (busted, second bank ignored with message [1])
> HIGHMEM=y, LPAE=n - NG (busted, board hangs on boot)
> HIGHMEM=n, LPAE=y - OK
> HIGHMEM=y, LPAE=y - OK
> 
> [1] Ignoring RAM at 00000000-3fffffff (vmalloc region overlap).
> 
> With all patches applied:
> 
> HIGHMEM=n, LPAE=n - OK
> HIGHMEM=y, LPAE=n - OK

Confirmed: these patches fix the LPAE=n case

Tested-by: Guennadi Liakhovetski <g.liakhovetski+renesas@gmail.com>

Thanks
Guennadi

> HIGHMEM=n, LPAE=y - OK
> HIGHMEM=y, LPAE=y - OK
> 
> My opinion is that LPAE should be handled in a similar way to x86 PAE.
> This means the kernel should boot regardless of kernel config but 64-bit
> memory banks may be truncated if needed like when LPAE=n or HIGHMEN=n.
> 
> Comments on how to implement this in a nicer way are very welcome!
> 
> Signed-off-by: Magnus Damm <damm@opensource.se>
> ---
> 
>  Written against renesas.git renesas-next-20130604v2
> 
>  arch/arm/boot/dts/r8a73a4-ape6evm.dts |    5 +++++
>  arch/arm/include/asm/setup.h          |    2 +-
>  arch/arm/kernel/setup.c               |   22 +++++++++++++++-------
>  3 files changed, 21 insertions(+), 8 deletions(-)

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

[PATCH 00/03] ARM: 64-bit memory fixes, APE6EVM second memory bank

[Magnus Damm]

Hi Russel, Arnd, Stepan,

On Wed, Jun 12, 2013 at 9:41 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Wednesday 12 June 2013, Magnus Damm wrote:
>> On Wed, Jun 5, 2013 at 8:17 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Wednesday 05 June 2013, Magnus Damm wrote:
>> >> ARM: 64-bit memory fixes, APE6EVM second memory bank
>> >>
>> >> [PATCH 01/03] ARM: Let arm_add_memory() always use 64-bit arguments
>> >> [PATCH 02/03] ARM: Handle 64-bit memory in case of 32-bit phys_addr_t
>> >> [PATCH 03/03] ARM: shmobile: Add second memory bank to DTS for APE6EVM
>> >>
>> >> This patch set contains two fixes and one mach-shmobile specific patch
>> >> to add a second memory bank. The fixes attempt to improve the memory bank
>> >> handling in the ARM kernel in case of 64-bit addresses.
>> >
>> > Please have a look at this patch that Stepan Moskovchenko posted:
>> >
>> > https://patchwork.kernel.org/patch/2639171/
>> >
>> > I think we are going to need only one of the two approaches.
>>
>> Thanks for pointing out this implementation. Is there anything I can
>> do to move this forward?
>
> I'm fine with either solution. If Russell doesn't have a preference
> one way or the other, I'd suggest you agree with Stepan on one of the
> two and put that into the patch tracker.

Thanks for your guidance, Arnd. After pinging Stepan I assume that he
doesn't have any preference either.

Russel, what is your opinion?

Thanks,

/ magnus