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