From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 06 Aug 2014 10:03:13 -0600 Subject: [U-Boot] [PATCH] lib: lmb: fix overflow in __lmb_alloc_base w/ large RAM In-Reply-To: <1406835607-14879-1-git-send-email-swarren@wwwdotorg.org> References: <1406835607-14879-1-git-send-email-swarren@wwwdotorg.org> Message-ID: <53E251C1.5040601@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 07/31/2014 01:40 PM, Stephen Warren wrote: > From: Stephen Warren > > If a 32-bit system has 2GB of RAM, and the base address of that RAM is > 2GB, then start+size will overflow a 32-bit value (to a value of 0). > > __lmb_alloc_base is affected by this; it calculates the minimum of > (start+size of RAM) and max_addr. However, when start+size is 0, it > is always less than max_addr, which causes the value of max_addr not > to be taken into account when restricting the allocation's location. > > Fix this by calculating start+size separately, and if that calculation > underflows, using -1 (interpreted as the max unsigned value) as the > value instead, and then taking the min of that and max_addr. Now that > start+size doesn't overflow, it's typically large, and max_addr > dominates the min() call, and is taken into account. > > The user-visible symptom of this bug is that CONFIG_BOOTMAP_SZ is ignored > on Tegra124 systems with 2GB of RAM, which in turn causes the DT to be > relocated at the very end of RAM, which the ARM Linux kernel doesn't map > during early boot, and which causes boot failures. With this fix, > CONFIG_BOOTMAP_SZ correctly restricts the relocated DT to a much lower > address, and everything works. TomR, Does this patch look OK to you? I imagine that TomW is holding off applying "ARM: tegra: Use mem size from MC rather than ODMDATA" since it depends on this patch, which isn't applied yet. Thanks.