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

[Tom Rini]

On Mon, Oct 27, 2014 at 12:50:39PM -0600, Simon Glass 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.

I'm still not super happy here.  If you have different boards then you
provide different device trees and the binary that can deal with board A
or B, based on what the DT says.

If you can't just use get_ram_size, can't you use one of the other
existing hooks such as ft_board_setup (which runs after arch_fixup_fdt)
to set the memory size?  On PowerPC boards for example this is where the
memory node is set anyhow, not arch_fixup_fdt (which is one of those ARM
vs PowerPC/everyone-else things I dislike).

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20141112/eb7c5bcd/attachment.pgp>