From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 23 Dec 2014 13:34:04 -0700 Subject: [U-Boot] [PATCH 3/3] ARM: tegra: support large RAM sizes In-Reply-To: References: <1419356091-13121-1-git-send-email-swarren@wwwdotorg.org> <1419356091-13121-3-git-send-email-swarren@wwwdotorg.org> Message-ID: <5499D1BC.6030206@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 12/23/2014 01:05 PM, Simon Glass wrote: > Hi Stephen, > > On 23 December 2014 at 10:34, Stephen Warren wrote: >> From: Stephen Warren >> >> 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.