Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
Hi Tom, On 20 November 2014 at 10:42, Simon Glass s...@chromium.org wrote: Hi Tom, On 20 November 2014 14:37, Tom Rini tr...@ti.com wrote: On Wed, Nov 12, 2014 at 03:14:35PM -0700, Simon Glass wrote: [snip, and sorry for the late reply] 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) OK. So what I'm getting at is how is this different from other boards where we say Oh, this is $FOO, it has $X LPDRR2 RAM and Oh, this is $BAR, it has $Y DDR3 RAM ? The only thing I'm able to think of is that we cannot call get_ram_size() to see the _size_ of the RAM after doing $whatever to see what board we're on and doing the right configuration for the DDR controller or whatever. Yes the memory type can go in the FDT too (and does for snow and pit). That's right, we can call get_ram_size() but only within the known boundaries. If we try to probe a 2GB machine as if it has 4GB of RAM it will hang. So we have to *know*. I have left this one out so far, but would like to apply it. With this I can support Pit and Pi (and with a bit more work Snow and Spring) with the same U-Boot board, dealing with the memory differences between the boards. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
On Wed, Nov 12, 2014 at 03:14:35PM -0700, Simon Glass wrote: [snip, and sorry for the late reply] 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) OK. So what I'm getting at is how is this different from other boards where we say Oh, this is $FOO, it has $X LPDRR2 RAM and Oh, this is $BAR, it has $Y DDR3 RAM ? The only thing I'm able to think of is that we cannot call get_ram_size() to see the _size_ of the RAM after doing $whatever to see what board we're on and doing the right configuration for the DDR controller or whatever. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
Hi Tom, On 20 November 2014 14:37, Tom Rini tr...@ti.com wrote: On Wed, Nov 12, 2014 at 03:14:35PM -0700, Simon Glass wrote: [snip, and sorry for the late reply] 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) OK. So what I'm getting at is how is this different from other boards where we say Oh, this is $FOO, it has $X LPDRR2 RAM and Oh, this is $BAR, it has $Y DDR3 RAM ? The only thing I'm able to think of is that we cannot call get_ram_size() to see the _size_ of the RAM after doing $whatever to see what board we're on and doing the right configuration for the DDR controller or whatever. Yes the memory type can go in the FDT too (and does for snow and pit). That's right, we can call get_ram_size() but only within the known boundaries. If we try to probe a 2GB machine as if it has 4GB of RAM it will hang. So we have to *know*. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
On Mon, Oct 27, 2014 at 12:50:39PM -0600, Simon Glass 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. 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 signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
Hi Tom, On 12 November 2014 14:42, Tom Rini tr...@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 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. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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? -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/11] fdt: Add device tree memory bindings
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.
Signed-off-by: Michael Pratt mpr...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Vadim Bendebury vben...@chromium.org
---
Changes in v2: None
common/fdt_support.c | 2 +-
doc/device-tree-bindings/memory/memory.txt | 67 ++
include/fdtdec.h | 33 +
lib/fdtdec.c | 107 +
4 files changed, 208 insertions(+), 1 deletion(-)
create mode 100644 doc/device-tree-bindings/memory/memory.txt
diff --git a/common/fdt_support.c b/common/fdt_support.c
index 46a15e7..6da5297 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -382,7 +382,7 @@ void do_fixup_by_compat_u32(void *fdt, const char *compat,
/*
* fdt_pack_reg - pack address and size array into the reg-suitable stream
*/
-static int fdt_pack_reg(const void *fdt, void *buf, uint64_t *address,
+int fdt_pack_reg(const void *fdt, void *buf, uint64_t *address,
uint64_t *size, int n)
{
int i;
diff --git a/doc/device-tree-bindings/memory/memory.txt
b/doc/device-tree-bindings/memory/memory.txt
new file mode 100644
index 000..321894e
--- /dev/null
+++ 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:
+
+Optional subnodes can be used defining the memory layout for different board
+ID masks. To match a set of board ids, a board-id node may define match-mask
+and match-value ints to define a mask to apply to the board id, and the value
+that the result should have for the match to be considered valid. The mask
+defaults to -1, meaning that the value must fully match the board id.
+
+If subnodes are present, then the /memory node must define these properties:
+
+- #address-cells: should be 1.
+- #size-cells: should be 0.
+
+Each subnode must define
+
+ reg - board ID or mask for this subnode
+ memory-banks - list of memory banks in the same format as normal
+
+Each subnode may optionally define:
+
+ match-mask - A mask to apply to the board id. This must be accompanied by
+ match-value.
+ match-value - The required resulting value of the board id mask for the given
+ node to be considered a match.
+ auto-size - Indicates that the value given for a bank is the maximum size,
+each bank is probed to determine its actual size, which may be
+smaller
+
+
+The board id determination is up to the vendor and is not defined by this
+binding.
+
+Example:
+
+memory {
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0x2000 0x2000
+ 0x4000 0x2000
+ 0x6000 0x2000
+ 0x8000 0x2000;
+ auto-size;
+ board-id@0 {
+ match-value = 17;
+ reg = 0x2000 0x2000
+ 0x4000 0x2000;
+ };
+ board-id@1 {
+ match-mask = 2;
+ match-value = 2;
+ reg = 0x2000 0x2000
+ 0x4000 0x2000
+ 0x6000 0x2000
+ 0x8000 0x2000
+ 0xa000 0x2000
+ 0xc000 0x2000
+ 0xe000 0x2000;
+ };
+};
+
+
+This shows a system with the following properties:
+* Default of 2GB of memory, auto-sized, so could be smaller
+* 3.5GB of memory (with no auto-size) if (board id 2) is 2
+* 1GB of memory (with no auto-size) if board id is 17.
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 4ae77be..5fb86b0 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -661,4 +661,37 @@ int fdt_get_named_resource(const void *fdt, int node,
const char *property,
*/
int fdtdec_pci_get_bdf(const void *fdt, int node, int *bdf);
+/**
+ * Decode the size of memory
+ *
+ * RAM size is normally set in a /memory node and consists of a list of
+ * (base, size) cells in the 'reg' property. This information is used to
+ * determine the total available memory as well as the address and size
+ * of each bank.
+ *
+ * Optionally the memory configuration can vary depending on a board id,
+ * typically read from strapping resistors or an EEPROM on the board.
+ *
+ * Finally, memory size can be detected (within certain limits) by probing
+ * the available memory. It is safe to do so within the limits provides by
+ * the board's device tree information. This makes it possible to produce
+ * boards
