diff mbox

arm: Handle device tree memory regions larger than 4GB

Message ID 1341506761-22016-1-git-send-email-peter.maydell@linaro.org
State Superseded
Headers show

Commit Message

Peter Maydell July 5, 2012, 4:46 p.m. UTC
Device tree memory regions may have sizes larger than 4GB.
Instead of silently truncating a 64 bit size when we pass it
to arm_add_memory(), split large regions into 2GB chunks.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
With this patch, I can take a device tree which has been tweaked
so its #address-cells and #size-cells are both 2, and boot it on
a QEMU vexpress-a15 model with >4GB of RAM, and have the kernel
actually detect the right amount of RAM. [the qemu bit needs some
patches I haven't posted yet.]

Since I'm not really a kernel dev I thought I'd post this to
linaro-dev first in the hope of a bit of friendly local review
before venturing onto lkml :-)

 arch/arm/kernel/devtree.c |    5 +++++
 1 file changed, 5 insertions(+)

Comments

Dave Martin July 6, 2012, 11:31 a.m. UTC | #1
On Thu, Jul 05, 2012 at 05:46:01PM +0100, Peter Maydell wrote:
> Device tree memory regions may have sizes larger than 4GB.
> Instead of silently truncating a 64 bit size when we pass it
> to arm_add_memory(), split large regions into 2GB chunks.
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> With this patch, I can take a device tree which has been tweaked
> so its #address-cells and #size-cells are both 2, and boot it on
> a QEMU vexpress-a15 model with >4GB of RAM, and have the kernel
> actually detect the right amount of RAM. [the qemu bit needs some
> patches I haven't posted yet.]
> 
> Since I'm not really a kernel dev I thought I'd post this to
> linaro-dev first in the hope of a bit of friendly local review
> before venturing onto lkml :-)
> 
>  arch/arm/kernel/devtree.c |    5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index bee7f9d..79a6e66 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -26,6 +26,11 @@
>  
>  void __init early_init_dt_add_memory_arch(u64 base, u64 size)
>  {
> +	while (size > 0x80000000) {
> +		arm_add_memory(base, 0x80000000);
> +		base += 0x80000000;
> +		size -= 0x80000000;
> +	}
>  	arm_add_memory(base, size);
>  }

Do we ever expect non-page-aligned regions here?

arm_add_memory squashes the supplied region to be page-aligned,
so if this function is called with a non-page-aligned base address
then the resulting mappings will include a page-sized hole every
2GB.

While non-page-aligned DT memory regions > 2GB are theoretically
possible, they don't sound likely to be common, or useful.  The
initial partial page would not be usable by the kernel anyway.

On the other hand, adding a BUG() for this would probably enlarge
the kernel more than the code required to fix the alignment.

Cheers
---Dave
diff mbox

Patch

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index bee7f9d..79a6e66 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -26,6 +26,11 @@ 
 
 void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 {
+	while (size > 0x80000000) {
+		arm_add_memory(base, 0x80000000);
+		base += 0x80000000;
+		size -= 0x80000000;
+	}
 	arm_add_memory(base, size);
 }