[U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB
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; }
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)
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
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)
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
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.
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 into32-bits
* and will wrap. Clip the reported size to the maximum that a32-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
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
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).
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 itdoesn't.
*/if (gd->ram_top < CONFIG_SYS_SDRAM_BASE)/** Will wrap back to top of 32-bit space whenreservations
* 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
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?
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@wwwdotorg.org] Sent: Monday, January 19, 2015 3:57 PM To: u-boot@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. -----------------------------------------------------------------------------------
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@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@wwwdotorg.org] Sent: Monday, January 19, 2015 3:57 PM To: u-boot@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. -----------------------------------------------------------------------------------
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@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@wwwdotorg.org] Sent: Monday, January 19, 2015 3:57 PM To: u-boot@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.
participants (3)
-
Simon Glass -
Stephen Warren -
Tom Warren