From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 23 Dec 2014 13:22:41 -0700 Subject: [U-Boot] [PATCH 1/3] common: board: support systems with where RAM ends beyond 4GB In-Reply-To: References: <1419356091-13121-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <5499CF11.2080904@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:01 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 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 > > Reviewed-by: Simon Glass >> 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).