[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.

In this case, we can gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed to the OS. This is useful if the OS
implements LPAE, and can actually use the "extra" RAM.

However, U-Boot does not implement LPAE and so must deal with 32-bit
physical addresses. To this end, we enhance board_get_usable_ram_top() to
detect the "over-sized" case, and limit the relocation addres so that it
fits into 32-bits of physical address space.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 common/board_f.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/common/board_f.c b/common/board_f.c
index 98c9c728ce73..c1ada8d62009 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -360,6 +360,18 @@ static int setup_fdt(void)
 /* Get the top of usable RAM */
 __weak ulong board_get_usable_ram_top(ulong total_size)
 {
+#ifdef CONFIG_SYS_SDRAM_BASE
+	/*
+	 * Detect whether we have so much RAM it goes past the end of our
+	 * 32-bit address space. If so, clip the usable RAM so it doesn't.
+	 */
+	if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
+		/*
+		 * Will wrap back to top of 32-bit space when reservations
+		 * are made.
+		 */
+		return 0;
+#endif
 	return gd->ram_top;
 }
 
-- 
1.9.1

[U-Boot] [PATCH 2/3] ARM: tegra: fix variable naming in query_sdram_size()

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

size_mb is used to hold a value that's sometimes KB, sometimes MB,
and sometimes bytes. Use separate correctly named variables to avoid
confusion here. Also fix indentation of a conditional statement.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/cpu/tegra-common/board.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/arm/cpu/tegra-common/board.c b/arch/arm/cpu/tegra-common/board.c
index b6a84a577478..f16fe68a6649 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -32,23 +32,24 @@ enum {
 unsigned int query_sdram_size(void)
 {
 	struct mc_ctlr *const mc = (struct mc_ctlr *)NV_PA_MC_BASE;
-	u32 size_mb;
+	u32 emem_cfg, size_bytes;
 
-	size_mb = readl(&mc->mc_emem_cfg);
+	emem_cfg = readl(&mc->mc_emem_cfg);
 #if defined(CONFIG_TEGRA20)
-	debug("mc->mc_emem_cfg (MEM_SIZE_KB) = 0x%08x\n", size_mb);
-	size_mb = get_ram_size((void *)PHYS_SDRAM_1, size_mb * 1024);
+	debug("mc->mc_emem_cfg (MEM_SIZE_KB) = 0x%08x\n", emem_cfg);
+	size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
 #else
-	debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", size_mb);
-	size_mb = get_ram_size((void *)PHYS_SDRAM_1, size_mb * 1024 * 1024);
+	debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
+	size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 * 1024);
 #endif
 
 #if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
 	/* External memory limited to 2047 MB due to IROM/HI-VEC */
-	if (size_mb == SZ_2G) size_mb -= SZ_1M;
+	if (size_bytes == SZ_2G)
+		size_bytes -= SZ_1M;
 #endif
 
-	return size_mb;
+	return size_bytes;
 }
 
 int dram_init(void)
-- 
1.9.1

[U-Boot] [PATCH 2/3] ARM: tegra: fix variable naming in query_sdram_size()

[Simon Glass]

On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> size_mb is used to hold a value that's sometimes KB, sometimes MB,
> and sometimes bytes. Use separate correctly named variables to avoid
> confusion here. Also fix indentation of a conditional statement.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Reviewed-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes

[Stephen Warren]

From: Stephen Warren <swarren@nvidia.com>

Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.

In this case, we want gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed to the OS. This is useful if the OS
implements LPAE, and can actually use the "extra" RAM.

However, we can't use get_ram_size() to verify the actual amount of RAM
present on such systems, since some of the RAM can't be accesses, which
confuses that function. Avoid calling get_ram_size() when the RAM size
is too large for it to work correctly. It's never actually needed anyway,
since there's no reason for the BCT to report the wrong RAM size.

In systems with >=4GB RAM, we still need to clip the reported RAM size
since U-Boot uses a 32-bit variable to represent the RAM size in bytes.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 arch/arm/cpu/tegra-common/board.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/tegra-common/board.c b/arch/arm/cpu/tegra-common/board.c
index f16fe68a6649..87511a31df18 100644
--- a/arch/arm/cpu/tegra-common/board.c
+++ b/arch/arm/cpu/tegra-common/board.c
@@ -40,7 +40,27 @@ unsigned int query_sdram_size(void)
 	size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
 #else
 	debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
-	size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 * 1024);
+	/*
+	 * If >=4GB RAM is present, the byte RAM size won't fit into 32-bits
+	 * and will wrap. Clip the reported size to the maximum that a 32-bit
+	 * variable can represent (rounded to a page).
+	 */
+	if (emem_cfg >= 4096) {
+		size_bytes = U32_MAX & ~(0x1000 - 1);
+	} else {
+		/* RAM size EMC is programmed to. */
+		size_bytes = emem_cfg * 1024 * 1024;
+		/*
+		 * If all RAM fits within 32-bits, it can be accessed without
+		 * LPAE, so go test the RAM size. Otherwise, we can't access
+		 * all the RAM, and get_ram_size() would get confused, so
+		 * avoid using it. There's no reason we should need this
+		 * validation step anyway.
+		 */
+		if (emem_cfg <= (0 - PHYS_SDRAM_1) / (1024 * 1024))
+			size_bytes = get_ram_size((void *)PHYS_SDRAM_1,
+						  size_bytes);
+	}
 #endif
 
 #if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
-- 
1.9.1

[U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes

[Simon Glass]

Hi Stephen,

On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Some systems have so much RAM that the end of RAM is beyond 4GB. An
> example would be a Tegra124 system (where RAM starts at 2GB physical)
> that has more than 2GB of RAM.
>
> In this case, we want gd->ram_size to represent the actual RAM size, so
> that the actual RAM size is passed to the OS. This is useful if the OS
> implements LPAE, and can actually use the "extra" RAM.
>
> However, we can't use get_ram_size() to verify the actual amount of RAM
> present on such systems, since some of the RAM can't be accesses, which

accessed

> confuses that function. Avoid calling get_ram_size() when the RAM size
> is too large for it to work correctly. It's never actually needed anyway,
> since there's no reason for the BCT to report the wrong RAM size.
>
> In systems with >=4GB RAM, we still need to clip the reported RAM size
> since U-Boot uses a 32-bit variable to represent the RAM size in bytes.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Reviewed-by: Simon Glass <sjg@chromium.org>

> ---
>  arch/arm/cpu/tegra-common/board.c | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/tegra-common/board.c b/arch/arm/cpu/tegra-common/board.c
> index f16fe68a6649..87511a31df18 100644
> --- a/arch/arm/cpu/tegra-common/board.c
> +++ b/arch/arm/cpu/tegra-common/board.c
> @@ -40,7 +40,27 @@ unsigned int query_sdram_size(void)
>         size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
>  #else
>         debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
> -       size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 * 1024);
> +       /*
> +        * If >=4GB RAM is present, the byte RAM size won't fit into 32-bits
> +        * and will wrap. Clip the reported size to the maximum that a 32-bit
> +        * variable can represent (rounded to a page).
> +        */
> +       if (emem_cfg >= 4096) {
> +               size_bytes = U32_MAX & ~(0x1000 - 1);

Will this return 4GB - 4KB? Why not return the full size?

> +       } else {
> +               /* RAM size EMC is programmed to. */
> +               size_bytes = emem_cfg * 1024 * 1024;
> +               /*
> +                * If all RAM fits within 32-bits, it can be accessed without
> +                * LPAE, so go test the RAM size. Otherwise, we can't access
> +                * all the RAM, and get_ram_size() would get confused, so
> +                * avoid using it. There's no reason we should need this
> +                * validation step anyway.
> +                */
> +               if (emem_cfg <= (0 - PHYS_SDRAM_1) / (1024 * 1024))
> +                       size_bytes = get_ram_size((void *)PHYS_SDRAM_1,
> +                                                 size_bytes);
> +       }
>  #endif
>
>  #if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA114)
> --
> 1.9.1
>

Regards,
Simon

[U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes

[Stephen Warren]

On 12/23/2014 01:05 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>> that has more than 2GB of RAM.
>>
>> In this case, we want gd->ram_size to represent the actual RAM size, so
>> that the actual RAM size is passed to the OS. This is useful if the OS
>> implements LPAE, and can actually use the "extra" RAM.
>>
>> However, we can't use get_ram_size() to verify the actual amount of RAM
>> present on such systems, since some of the RAM can't be accesses, which
>> confuses that function. Avoid calling get_ram_size() when the RAM size
>> is too large for it to work correctly. It's never actually needed anyway,
>> since there's no reason for the BCT to report the wrong RAM size.
>>
>> In systems with >=4GB RAM, we still need to clip the reported RAM size
>> since U-Boot uses a 32-bit variable to represent the RAM size in bytes.

>> diff --git a/arch/arm/cpu/tegra-common/board.c b/arch/arm/cpu/tegra-common/board.c

>> @@ -40,7 +40,27 @@ unsigned int query_sdram_size(void)
>>          size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024);
>>   #else
>>          debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
>> -       size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 * 1024);
>> +       /*
>> +        * If >=4GB RAM is present, the byte RAM size won't fit into 32-bits
>> +        * and will wrap. Clip the reported size to the maximum that a 32-bit
>> +        * variable can represent (rounded to a page).
>> +        */
>> +       if (emem_cfg >= 4096) {
>> +               size_bytes = U32_MAX & ~(0x1000 - 1);
>
> Will this return 4GB - 4KB? Why not return the full size?

A U32 can only store 4GB-1 at most, so we can never put the full 4GB 
value into size_bytes.

I aligned the value down to page alignment rather than storing 4GB-1 
there to prevent surprises elsewhere. For example, not all adjustments 
to gd->relocaddr in board_f.c page-align the allocations. In particular, 
I have enabled reserve_pram() locally for other reasons, and it just 
blindly subtracts the size from the current value of gd->relocaddr. 
Arguably that's a bug in that code, but I figured it was simplest to 
return a sensibly aligned size irrespective of that.

[U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes

[Simon Glass]

Hi Stephen,

On 23 December 2014 at 13:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 12/23/2014 01:05 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>>> that has more than 2GB of RAM.
>>>
>>> In this case, we want gd->ram_size to represent the actual RAM size, so
>>> that the actual RAM size is passed to the OS. This is useful if the OS
>>> implements LPAE, and can actually use the "extra" RAM.
>>>
>>> However, we can't use get_ram_size() to verify the actual amount of RAM
>>> present on such systems, since some of the RAM can't be accesses, which
>>> confuses that function. Avoid calling get_ram_size() when the RAM size
>>> is too large for it to work correctly. It's never actually needed anyway,
>>> since there's no reason for the BCT to report the wrong RAM size.
>>>
>>> In systems with >=4GB RAM, we still need to clip the reported RAM size
>>> since U-Boot uses a 32-bit variable to represent the RAM size in bytes.
>
>
>>> diff --git a/arch/arm/cpu/tegra-common/board.c
>>> b/arch/arm/cpu/tegra-common/board.c
>
>
>>> @@ -40,7 +40,27 @@ unsigned int query_sdram_size(void)
>>>          size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg *
>>> 1024);
>>>   #else
>>>          debug("mc->mc_emem_cfg (MEM_SIZE_MB) = 0x%08x\n", emem_cfg);
>>> -       size_bytes = get_ram_size((void *)PHYS_SDRAM_1, emem_cfg * 1024 *
>>> 1024);
>>> +       /*
>>> +        * If >=4GB RAM is present, the byte RAM size won't fit into
>>> 32-bits
>>> +        * and will wrap. Clip the reported size to the maximum that a
>>> 32-bit
>>> +        * variable can represent (rounded to a page).
>>> +        */
>>> +       if (emem_cfg >= 4096) {
>>> +               size_bytes = U32_MAX & ~(0x1000 - 1);
>>
>>
>> Will this return 4GB - 4KB? Why not return the full size?
>
>
> A U32 can only store 4GB-1 at most, so we can never put the full 4GB value
> into size_bytes.
>
> I aligned the value down to page alignment rather than storing 4GB-1 there
> to prevent surprises elsewhere. For example, not all adjustments to
> gd->relocaddr in board_f.c page-align the allocations. In particular, I have
> enabled reserve_pram() locally for other reasons, and it just blindly
> subtracts the size from the current value of gd->relocaddr. Arguably that's
> a bug in that code, but I figured it was simplest to return a sensibly
> aligned size irrespective of that.

Sounds reasonable to me, thanks.

Regards,
Simon

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Simon Glass]

Hi Stephen,

On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Some systems have so much RAM that the end of RAM is beyond 4GB. An
> example would be a Tegra124 system (where RAM starts at 2GB physical)
> that has more than 2GB of RAM.
>
> In this case, we can gd->ram_size to represent the actual RAM size, so
> that the actual RAM size is passed to the OS. This is useful if the OS
> implements LPAE, and can actually use the "extra" RAM.
>
> However, U-Boot does not implement LPAE and so must deal with 32-bit
> physical addresses. To this end, we enhance board_get_usable_ram_top() to
> detect the "over-sized" case, and limit the relocation addres so that it
> fits into 32-bits of physical address space.
>
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

Reviewed-by: Simon Glass <sjg@chromium.org>

> ---
>  common/board_f.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 98c9c728ce73..c1ada8d62009 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -360,6 +360,18 @@ static int setup_fdt(void)
>  /* Get the top of usable RAM */
>  __weak ulong board_get_usable_ram_top(ulong total_size)
>  {
> +#ifdef CONFIG_SYS_SDRAM_BASE
> +       /*
> +        * Detect whether we have so much RAM it goes past the end of our
> +        * 32-bit address space. If so, clip the usable RAM so it doesn't.
> +        */
> +       if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
> +               /*
> +                * Will wrap back to top of 32-bit space when reservations
> +                * are made.
> +                */
> +               return 0;

I wonder whether (ulong)(1ULL << 32) would be more portable, but
perhaps it would just be confusing. We can worry about this when we do
more 64-bit things.

> +#endif
>         return gd->ram_top;
>  }
>
> --
> 1.9.1
>

Regards,
Simon

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Stephen Warren]

On 12/23/2014 01:01 PM, Simon Glass wrote:
> Hi Stephen,
>
> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>> that has more than 2GB of RAM.
>>
>> In this case, we can gd->ram_size to represent the actual RAM size, so
>> that the actual RAM size is passed to the OS. This is useful if the OS
>> implements LPAE, and can actually use the "extra" RAM.
>>
>> However, U-Boot does not implement LPAE and so must deal with 32-bit
>> physical addresses. To this end, we enhance board_get_usable_ram_top() to
>> detect the "over-sized" case, and limit the relocation addres so that it
>> fits into 32-bits of physical address space.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>
> Reviewed-by: Simon Glass <sjg@chromium.org>

>> diff --git a/common/board_f.c b/common/board_f.c

>>   /* Get the top of usable RAM */
>>   __weak ulong board_get_usable_ram_top(ulong total_size)
>>   {
>> +#ifdef CONFIG_SYS_SDRAM_BASE
>> +       /*
>> +        * Detect whether we have so much RAM it goes past the end of our
>> +        * 32-bit address space. If so, clip the usable RAM so it doesn't.
>> +        */
>> +       if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
>> +               /*
>> +                * Will wrap back to top of 32-bit space when reservations
>> +                * are made.
>> +                */
>> +               return 0;
>
> I wonder whether (ulong)(1ULL << 32) would be more portable, but
> perhaps it would just be confusing. We can worry about this when we do
> more 64-bit things.

I don't think it makes any difference while board_get_usable_ram_top() 
returns a 32-bit value.

If board_get_usable_ram_top() was modified to return a 32-bit value on 
32-bit systems and a 64-bit value on 64-bit systems then:

The value "0" means "top of addressable address space" (once wrapped 
from 0 backwards when allocations are made later).

The value 1ULL<<32 means 4GB, no matter what the address space size is. 
That's quite a different thing on 64-bit.

We really do want 0 here, not a masked/clipped/overflowed 4GB value, 
since on 64-bit, if gd->ram_top ended up less than 
CONFIG_SYS_SDRAM_BASE, we'd have the exact same situation as I'm fixing 
here on 32-bit, just with much larger numbers; consider a system where 
RAM starts at (U64_MAX + 1 - 2GB) and RAM is 4GB in size; we get the 
same wrapping effect. (Admittedly that physical layout would be quite 
unlikely to happen on 64-bit since presumably no SoC designer would ever 
set CONFIG_SYS_SDRAM_BASE that high if that much RAM were supported, 
since that'd require a 64-bit system with >64-bit LPAE, which hopefully 
is many many years in the future).

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Simon Glass]

Hi Stephen,

On 23 December 2014 at 13:22, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 12/23/2014 01:01 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 23 December 2014 at 10:34, Stephen Warren <swarren@wwwdotorg.org>
>> wrote:
>>>
>>> From: Stephen Warren <swarren@nvidia.com>
>>>
>>> Some systems have so much RAM that the end of RAM is beyond 4GB. An
>>> example would be a Tegra124 system (where RAM starts at 2GB physical)
>>> that has more than 2GB of RAM.
>>>
>>> In this case, we can gd->ram_size to represent the actual RAM size, so
>>> that the actual RAM size is passed to the OS. This is useful if the OS
>>> implements LPAE, and can actually use the "extra" RAM.
>>>
>>> However, U-Boot does not implement LPAE and so must deal with 32-bit
>>> physical addresses. To this end, we enhance board_get_usable_ram_top() to
>>> detect the "over-sized" case, and limit the relocation addres so that it
>>> fits into 32-bits of physical address space.
>>>
>>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>>
>>
>> Reviewed-by: Simon Glass <sjg@chromium.org>
>
>
>>> diff --git a/common/board_f.c b/common/board_f.c
>
>
>>>   /* Get the top of usable RAM */
>>>   __weak ulong board_get_usable_ram_top(ulong total_size)
>>>   {
>>> +#ifdef CONFIG_SYS_SDRAM_BASE
>>> +       /*
>>> +        * Detect whether we have so much RAM it goes past the end of our
>>> +        * 32-bit address space. If so, clip the usable RAM so it
>>> doesn't.
>>> +        */
>>> +       if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)
>>> +               /*
>>> +                * Will wrap back to top of 32-bit space when
>>> reservations
>>> +                * are made.
>>> +                */
>>> +               return 0;
>>
>>
>> I wonder whether (ulong)(1ULL << 32) would be more portable, but
>> perhaps it would just be confusing. We can worry about this when we do
>> more 64-bit things.
>
>
> I don't think it makes any difference while board_get_usable_ram_top()
> returns a 32-bit value.
>
> If board_get_usable_ram_top() was modified to return a 32-bit value on
> 32-bit systems and a 64-bit value on 64-bit systems then:
>
> The value "0" means "top of addressable address space" (once wrapped from 0
> backwards when allocations are made later).
>
> The value 1ULL<<32 means 4GB, no matter what the address space size is.
> That's quite a different thing on 64-bit.
>
> We really do want 0 here, not a masked/clipped/overflowed 4GB value, since
> on 64-bit, if gd->ram_top ended up less than CONFIG_SYS_SDRAM_BASE, we'd
> have the exact same situation as I'm fixing here on 32-bit, just with much
> larger numbers; consider a system where RAM starts at (U64_MAX + 1 - 2GB)
> and RAM is 4GB in size; we get the same wrapping effect. (Admittedly that
> physical layout would be quite unlikely to happen on 64-bit since presumably
> no SoC designer would ever set CONFIG_SYS_SDRAM_BASE that high if that much
> RAM were supported, since that'd require a 64-bit system with >64-bit LPAE,
> which hopefully is many many years in the future).

Yes it's best to avoid predicting the future, and what you have looks
right for 32-bit.

Regards,
Simon

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Stephen Warren]

On 12/23/2014 10:34 AM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Some systems have so much RAM that the end of RAM is beyond 4GB. An
> example would be a Tegra124 system (where RAM starts at 2GB physical)
> that has more than 2GB of RAM.
>
> In this case, we can gd->ram_size to represent the actual RAM size, so
> that the actual RAM size is passed to the OS. This is useful if the OS
> implements LPAE, and can actually use the "extra" RAM.
>
> However, U-Boot does not implement LPAE and so must deal with 32-bit
> physical addresses. To this end, we enhance board_get_usable_ram_top() to
> detect the "over-sized" case, and limit the relocation addres so that it
> fits into 32-bits of physical address space.

TomW, TomR, does this series look good?

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Tom Warren]

Sorry, missed this. Yes, looks good to me. I can apply it to u-boot-tegra/master, or TomR can take it in to master U-Boot directly.

Tom

> -----Original Message-----
> From: Stephen Warren [mailto:swarren at wwwdotorg.org]
> Sent: Monday, January 19, 2015 3:57 PM
> To: u-boot at lists.denx.de; Simon Glass; Tom Warren; Stephen Warren
> Cc: Tom Rini
> Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with
> where RAM ends beyond 4GB
> 
> On 12/23/2014 10:34 AM, Stephen Warren wrote:
> > From: Stephen Warren <swarren@nvidia.com>
> >
> > Some systems have so much RAM that the end of RAM is beyond 4GB. An
> > example would be a Tegra124 system (where RAM starts at 2GB physical)
> > that has more than 2GB of RAM.
> >
> > In this case, we can gd->ram_size to represent the actual RAM size, so
> > that the actual RAM size is passed to the OS. This is useful if the OS
> > implements LPAE, and can actually use the "extra" RAM.
> >
> > However, U-Boot does not implement LPAE and so must deal with 32-bit
> > physical addresses. To this end, we enhance board_get_usable_ram_top()
> > to detect the "over-sized" case, and limit the relocation addres so
> > that it fits into 32-bits of physical address space.
> 
> TomW, TomR, does this series look good?
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Tom Warren]

I've merged that patch series w/u-boot-tegra/next and /master, done a MAKEALL -s tegra, and rebased against ARM /master and pushed to denx.de.

Stephen - please test and if it looks OK, I'll prepare a PR.

> -----Original Message-----
> From: Tom Warren
> Sent: Tuesday, January 20, 2015 8:28 AM
> To: 'Stephen Warren'; u-boot at lists.denx.de; Simon Glass; Stephen Warren
> Cc: Tom Rini
> Subject: RE: [U-Boot] [PATCH 1/3] common: board: support systems with
> where RAM ends beyond 4GB
> 
> Sorry, missed this. Yes, looks good to me. I can apply it to u-boot-
> tegra/master, or TomR can take it in to master U-Boot directly.
> 
> Tom
> 
> > -----Original Message-----
> > From: Stephen Warren [mailto:swarren at wwwdotorg.org]
> > Sent: Monday, January 19, 2015 3:57 PM
> > To: u-boot at lists.denx.de; Simon Glass; Tom Warren; Stephen Warren
> > Cc: Tom Rini
> > Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with
> > where RAM ends beyond 4GB
> >
> > On 12/23/2014 10:34 AM, Stephen Warren wrote:
> > > From: Stephen Warren <swarren@nvidia.com>
> > >
> > > Some systems have so much RAM that the end of RAM is beyond 4GB.
> An
> > > example would be a Tegra124 system (where RAM starts at 2GB
> > > physical) that has more than 2GB of RAM.
> > >
> > > In this case, we can gd->ram_size to represent the actual RAM size,
> > > so that the actual RAM size is passed to the OS. This is useful if
> > > the OS implements LPAE, and can actually use the "extra" RAM.
> > >
> > > However, U-Boot does not implement LPAE and so must deal with 32-bit
> > > physical addresses. To this end, we enhance
> > > board_get_usable_ram_top() to detect the "over-sized" case, and
> > > limit the relocation addres so that it fits into 32-bits of physical address
> space.
> >
> > TomW, TomR, does this series look good?
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------

[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB

[Stephen Warren]

On 01/20/2015 08:56 AM, Tom Warren wrote:
> I've merged that patch series w/u-boot-tegra/next and /master, done a MAKEALL -s tegra, and rebased against ARM /master and pushed to denx.de.
>
> Stephen - please test and if it looks OK, I'll prepare a PR.

This works great on my Jetson TK1. Thanks.

>
>> -----Original Message-----
>> From: Tom Warren
>> Sent: Tuesday, January 20, 2015 8:28 AM
>> To: 'Stephen Warren'; u-boot at lists.denx.de; Simon Glass; Stephen Warren
>> Cc: Tom Rini
>> Subject: RE: [U-Boot] [PATCH 1/3] common: board: support systems with
>> where RAM ends beyond 4GB
>>
>> Sorry, missed this. Yes, looks good to me. I can apply it to u-boot-
>> tegra/master, or TomR can take it in to master U-Boot directly.
>>
>> Tom
>>
>>> -----Original Message-----
>>> From: Stephen Warren [mailto:swarren at wwwdotorg.org]
>>> Sent: Monday, January 19, 2015 3:57 PM
>>> To: u-boot at lists.denx.de; Simon Glass; Tom Warren; Stephen Warren
>>> Cc: Tom Rini
>>> Subject: Re: [U-Boot] [PATCH 1/3] common: board: support systems with
>>> where RAM ends beyond 4GB
>>>
>>> On 12/23/2014 10:34 AM, Stephen Warren wrote:
>>>> From: Stephen Warren <swarren@nvidia.com>
>>>>
>>>> Some systems have so much RAM that the end of RAM is beyond 4GB.
>> An
>>>> example would be a Tegra124 system (where RAM starts at 2GB
>>>> physical) that has more than 2GB of RAM.
>>>>
>>>> In this case, we can gd->ram_size to represent the actual RAM size,
>>>> so that the actual RAM size is passed to the OS. This is useful if
>>>> the OS implements LPAE, and can actually use the "extra" RAM.
>>>>
>>>> However, U-Boot does not implement LPAE and so must deal with 32-bit
>>>> physical addresses. To this end, we enhance
>>>> board_get_usable_ram_top() to detect the "over-sized" case, and
>>>> limit the relocation addres so that it fits into 32-bits of physical address
>> space.
>>>
>>> TomW, TomR, does this series look good?
> -----------------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and may contain
> confidential information.  Any unauthorized review, use, disclosure or distribution
> is prohibited.  If you are not the intended recipient, please contact the sender by
> reply email and destroy all copies of the original message.
> -----------------------------------------------------------------------------------
>