Hi, On 27 October 2014 12:50, Simon Glass <s...@chromium.org> wrote: > Hi Tom, > > On 27 October 2014 08:24, Tom Rini <tr...@ti.com> wrote: >> On Fri, Oct 24, 2014 at 02:04:00PM -0600, Simon Glass wrote: >>> Hi Tom, >>> >>> On 24 October 2014 12:49, Tom Rini <tr...@ti.com> wrote: >>> > On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote: >>> > >>> >> From: Michael Pratt <mpr...@chromium.org> >>> >> >>> >> Support a default memory bank, specified in reg, as well as >>> >> board-specific memory banks in subtree board-id nodes. >>> >> >>> >> This allows memory information to be provided in the device tree, >>> >> rather than hard-coded in, which will make it simpler to handle >>> >> similar devices with different memory banks, as the board-id values >>> >> or masks can be used to match devices. >>> > [snip] >>> >> +++ b/doc/device-tree-bindings/memory/memory.txt >>> >> @@ -0,0 +1,67 @@ >>> >> +* Memory binding >>> >> + >>> >> +The memory binding for U-Boot is as in the ePAPR with the following >>> >> additions: >>> > >>> > I am wary of being different from ePAPR / Linux Kernel. What do we need >>> > this for / when do we use it? >>> >>> This extends the existing binding. It allows the location and size of >>> memory to be set by a board ID. Unfortunately on sopme hardware you >>> get a hang if you try to access memory that doesn't exist, so this >>> allows the range of available memory to be defined - or at least the >>> maximum bound since we still probe the memory size within that range. >>> >>> This feature is used on several Exynos Chromebooks. >> >> So that you can use the same DT on several disjoint boards? How does >> this work with the kernel, does U-Boot then pass along only the correct >> map? Patches to the kernel to also deal with this? > > Typically a board may have variants with different amounts of memory, > detected at run-time by GPIOs. We want the option of using the same DT > for these, similar to what the Compulab people were talking about - > otherwise we have something of an explosion of combinations. > > Yes U-Boot (already) puts the correct memory map together for the > kernel, so it all works from start to finish.
Are there any more thoughts on this one? I'd like to pull this series into the u-boot-fdt tree. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
