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

PATCH New Magnus Damm 3 participants 9 messages Jun 5, 2013 – Jul 2, 2013

Subsystems (3)

Device tree bindings Arm (32-bit) SuperH

lore

Share & tools

lore

Magnus Damm

author

2013-06-05 10:44 UTC #0 lore raw

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

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 <[email protected]>

---

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(-)

Magnus Damm

author

2013-06-05 10:44 UTC #1 lore raw

PATCH 1/3 ARM: Let arm_add_memory() always use 64-bit arguments

From: Magnus Damm <[email protected]>

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 <[email protected]>

---

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

arch/arm/include/asm/setup.h +1 -1

@@ -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);

arch/arm/kernel/setup.c +3 -3

@@ -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;
 
 	/*

Magnus Damm

author

2013-06-05 10:44 UTC #2 lore raw

PATCH 2/3 ARM: Handle 64-bit memory in case of 32-bit phys_addr_t

In reply to Magnus Damm

From: Magnus Damm <[email protected]>

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 <[email protected]>

---

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(-)

arch/arm/kernel/setup.c +12 -4

@@ -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);
 
 	/*

Magnus Damm

author

2013-06-05 10:44 UTC #3 lore raw

PATCH 3/3 ARM: shmobile: Add second memory bank to DTS for APE6EVM

In reply to Magnus Damm

From: Takashi Yoshii <[email protected]>

Add 1GiB of DRAM at 0x2_0000_0000 to APE6EVM

Signed-off-by Takashi Yoshii <[email protected]>

Signed-off-by Magnus Damm <[email protected]>

---

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

arch/arm/boot/dts/r8a73a4-ape6evm.dts +5 -0

@@ -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";

Arnd Bergmann

2013-06-05 11:17 UTC #4 lore raw

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

In reply to Magnus Damm

Quoted 9 lines · 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.

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

Magnus Damm

author

2013-06-12 10:57 UTC #5 lore raw

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

Hi Arnd,

Quoted 11 lines · Arnd Bergmann

Quoted 9 lines · 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.

Quoted 5 lines

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

Arnd Bergmann

2013-06-12 12:41 UTC #6 lore raw

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

Quoted 12 lines · Magnus Damm

Quoted 11 lines · Arnd Bergmann
Quoted 9 lines · 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.

Quoted 8 lines

Quoted 5 lines
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

Guennadi Liakhovetski

2013-06-17 12:44 UTC #8 lore raw

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

In reply to Magnus Damm

Quoted 17 lines · 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

Quoted 6 lines

[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 <[email protected]>

Thanks
Guennadi

Quoted 10 lines

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 <[email protected]>

Quoted 8 lines

---

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/

Magnus Damm

author

2013-07-02 05:52 UTC #7 lore raw

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

In reply to Arnd Bergmann

Hi Russel, Arnd, Stepan,

Quoted 17 lines · Arnd Bergmann

Quoted 16 lines · Magnus Damm
Quoted 15 lines · Arnd Bergmann
Quoted 9 lines · 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.
Please have a look at this patch that Stepan Moskovchenko posted:
https://patchwork.kernel.org/patch/2639171/

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
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