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

[Simon Glass]

Hi Tom,


On 12 November 2014 14:42, Tom Rini <trini at ti.com> wrote:
> 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.

(Note: I'm talking about the U-Boot device tree, and indeed for the
kernel we will have two different device trees)

That assumes that you can put a different binary on two different
boards. The same discussion came up with the Compulab series, where
they have different features but what to use the same U-Boot binary in
production for them, since it is such a pain to deal with different
incompatible binaries for board variants. It gets worse when you have
a module and want to support different base boards.

>
> 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).

I think here you are talking about setting up the device tree for the
kernel. Yes, U-Boot correctly sets up the memory for the kernel, by
copying information from the SDRAM bank list into the kernel's device
tree. The question is of course, how do we get the correct SDRAM bank
list in the first place.

What I am talking about here is the memory for U-Boot - i.e. how does
U-Boot know how much memory is available. The scheme here is that you
can have a board ID which controls this, with the U-Boot device tree
allowing the options to be specified (i.e. the mapping from board ID
to SDRAM banks)

Regards,
Simon