On Wed, May 15, 2013 at 08:58:03AM -0700, Vadim Bendebury wrote: > On Tue, Apr 30, 2013 at 2:14 PM, Tom Rini <tr...@ti.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On 04/30/2013 04:49 PM, Doug Anderson wrote: > >> Tom, > >> > >> On Tue, Apr 30, 2013 at 1:35 PM, Tom Rini <tr...@ti.com> wrote: > >>> And I guess having this knowledge correct for the kernel is > >>> useful in other contexts like when we want to power down some > >>> banks of memory but not others? I mean, there's "lots" of > >>> platforms that lie and say 1 bank since we require contiguous > >>> mapping. Thanks! > >> > >> Thanks for the review! > >> > >> At the moment I'm _not_ convinced that there's a good reason to > >> specify 8 banks. We appear to have lied and said 1 bank on > >> exynos5250-snow (ARM Chromebook) and I don't know of any bad side > >> effects. > >> > >> The code I'm looking at right now indicates 8 banks. We need to > >> track down why someone did that but it doesn't seem totally crazy > >> to allow specifying the proper number of banks so I figured I'd > >> send this patch up. > >> > >> If you prefer, we can leave this patch hanging until we actually > >> track down if specifying 8 banks was really needed. > > > > Yes please, lets hold. Thanks! > > > > I looked into this a bit more, what happens on this particular target > (Exynos5420 with 4GB DRAM onboard) is that out of 4GB of memory only > 3.5GB is usable, as the lower .5 GB of address range is taken by the > architecture, and the address bus width is 32 bits. > > U-boot code makes several assumptions: > - bank size is a power of 2 > - bank base is aligned with bank size > - all bank sizes are the same > > with this in mind, the only way to describe our memory situation is to > define 7 banks, .5GB each, the lowest one starting at 0x20000000 > (.5GB). > > This is not a big deal for u-boot (maybe very marginally inefficient > when determining the actual memory size). Is this a big deal for > kernel? I mean it is easy to squash these seven memory banks into one > when filling out the memory node of the device tree, the question is > is it even necessary?
OK, this would be the second case of needing to describe the memory in the DT in a way that conflicts with how we dynamically do the node. Lets go and try again at a patch that lets boards opt-in to "do not override the memory property, it was already correct and you broke it". -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
