[U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings

[Simon Glass]

Hi,

On 27 October 2014 12:50, Simon Glass <sjg at chromium.org> wrote:
> Hi Tom,
>
> On 27 October 2014 08:24, Tom Rini <trini at 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 <trini at ti.com> wrote:
>>> > On Thu, Oct 23, 2014 at 06:58:50PM -0600, Simon Glass wrote:
>>> >
>>> >> From: Michael Pratt <mpratt at 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