[PATCH 0/14] fdt: Add various device tree utilities and features

[PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

This series contains a number of features related to CONFIG_OF_CONTROL,
such as:

- reading fdt values
- reading configuration from the fdt
- allowing the fdt to specify a boot command


Abhilash Kesavan (2):
  fdt: Add function to get config int from device tree
  fdt: Add function for decoding multiple gpios globally available

Che-Liang Chiou (2):
  fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property
  fdt: Load boot command from device tree

Doug Anderson (1):
  fdt: Allow device tree to specify secure booting

Gabe Black (3):
  fdt: Add function to read boolean property
  fdt: Tell the FDT library where the device tree is
  fdt: Add option to default to most compatible conf in a fit image

Sean Paul (1):
  fdt: Add polarity-aware gpio functions to fdtdec

Simon Glass (5):
  fdt: Add function to get a config string from device tree
  fdt: Add fdtdec_decode_region() to decode memory region
  fdt: Export fdtdec_find_alias_node() function
  fdt: Export fdtdec_lookup() and fix the name
  fdt: Set kernaddr if fdt indicates a kernel is present

 README             |   11 +++++
 common/cmd_bootm.c |   11 +++++
 common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
 include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/image.h    |    1 +
 lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
 7 files changed, 472 insertions(+), 8 deletions(-)

-- 
1.7.7.3

[U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

This series contains a number of features related to CONFIG_OF_CONTROL,
such as:

- reading fdt values
- reading configuration from the fdt
- allowing the fdt to specify a boot command


Abhilash Kesavan (2):
  fdt: Add function to get config int from device tree
  fdt: Add function for decoding multiple gpios globally available

Che-Liang Chiou (2):
  fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property
  fdt: Load boot command from device tree

Doug Anderson (1):
  fdt: Allow device tree to specify secure booting

Gabe Black (3):
  fdt: Add function to read boolean property
  fdt: Tell the FDT library where the device tree is
  fdt: Add option to default to most compatible conf in a fit image

Sean Paul (1):
  fdt: Add polarity-aware gpio functions to fdtdec

Simon Glass (5):
  fdt: Add function to get a config string from device tree
  fdt: Add fdtdec_decode_region() to decode memory region
  fdt: Export fdtdec_find_alias_node() function
  fdt: Export fdtdec_lookup() and fix the name
  fdt: Set kernaddr if fdt indicates a kernel is present

 README             |   11 +++++
 common/cmd_bootm.c |   11 +++++
 common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
 include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
 include/image.h    |    1 +
 lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
 7 files changed, 472 insertions(+), 8 deletions(-)

-- 
1.7.7.3

[PATCH 01/14] fdt: Add function to get config int from device tree

[Simon Glass]

From: Abhilash Kesavan <a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Add a function to look up a configuration item such as machine id
and return its value.

Note: The code has been taken as is from the Chromium u-boot development
tree and needs Simon Glass' sign-off.

Signed-off-by: Abhilash Kesavan <a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |   22 ++++++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 0b14075..d880fe8 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -354,6 +354,19 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
  */
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob		FDT blob to use
+ * @param prop_name	Node property name
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+		int default_val);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4c23f45..1f50022 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -512,3 +512,25 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 		return NULL;
 	return cell;
 }
+
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob		FDT blob to use
+ * @param prop_name	Node property name
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+		int default_val)
+{
+	int config_node;
+
+	debug("%s: %s\n", __func__, prop_name);
+	config_node = fdt_path_offset(blob, "/config");
+	if (config_node < 0)
+		return default_val;
+	return fdtdec_get_int(blob, config_node, prop_name, default_val);
+}
-- 
1.7.7.3

[U-Boot] [PATCH 01/14] fdt: Add function to get config int from device tree

[Simon Glass]

From: Abhilash Kesavan <a.kesavan@samsung.com>

Add a function to look up a configuration item such as machine id
and return its value.

Note: The code has been taken as is from the Chromium u-boot development
tree and needs Simon Glass' sign-off.

Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |   22 ++++++++++++++++++++++
 2 files changed, 35 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 0b14075..d880fe8 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -354,6 +354,19 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
  */
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob		FDT blob to use
+ * @param prop_name	Node property name
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+		int default_val);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4c23f45..1f50022 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -512,3 +512,25 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 		return NULL;
 	return cell;
 }
+
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a 32-bit integer. The property must have at least 4 bytes of data. The
+ * value of the first cell is returned.
+ *
+ * @param blob		FDT blob to use
+ * @param prop_name	Node property name
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+int fdtdec_get_config_int(const void *blob, const char *prop_name,
+		int default_val)
+{
+	int config_node;
+
+	debug("%s: %s\n", __func__, prop_name);
+	config_node = fdt_path_offset(blob, "/config");
+	if (config_node < 0)
+		return default_val;
+	return fdtdec_get_int(blob, config_node, prop_name, default_val);
+}
-- 
1.7.7.3

[PATCH 02/14] fdt: Add function to get a config string from device tree

[Simon Glass]

Add a function to look up a configuration string such as board name
and returns its value. We look in the "/config" node for this.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   10 ++++++++++
 lib/fdtdec.c     |   28 ++++++++++++++++++----------
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index d880fe8..e828662 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -367,6 +367,16 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a string.
+ *
+ * @param blob          FDT blob
+ * @param prop_name     property name to look up
+ * @returns property string, NULL on error.
+ */
+char *fdtdec_get_config_string(const void *blob, const char *prop_name);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 1f50022..2d60c8a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -513,16 +513,6 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 	return cell;
 }
 
-/**
- * Look in the FDT for a config item with the given name and return its value
- * as a 32-bit integer. The property must have at least 4 bytes of data. The
- * value of the first cell is returned.
- *
- * @param blob		FDT blob to use
- * @param prop_name	Node property name
- * @param default_val	default value to return if the property is not found
- * @return integer value, if found, or default_val if not
- */
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val)
 {
@@ -534,3 +524,21 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		return default_val;
 	return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
+
+char *fdtdec_get_config_string(const void *blob, const char *prop_name)
+{
+	const char *nodep;
+	int nodeoffset;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	nodeoffset = fdt_path_offset(blob, "/config");
+	if (nodeoffset < 0)
+		return NULL;
+
+	nodep = fdt_getprop(blob, nodeoffset, prop_name, &len);
+	if (!nodep)
+		return NULL;
+
+	return (char *)nodep;
+}
-- 
1.7.7.3

[U-Boot] [PATCH 02/14] fdt: Add function to get a config string from device tree

[Simon Glass]

Add a function to look up a configuration string such as board name
and returns its value. We look in the "/config" node for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   10 ++++++++++
 lib/fdtdec.c     |   28 ++++++++++++++++++----------
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index d880fe8..e828662 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -367,6 +367,16 @@ int fdtdec_setup_gpio(struct fdt_gpio_state *gpio);
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val);
 
+/**
+ * Look in the FDT for a config item with the given name and return its value
+ * as a string.
+ *
+ * @param blob          FDT blob
+ * @param prop_name     property name to look up
+ * @returns property string, NULL on error.
+ */
+char *fdtdec_get_config_string(const void *blob, const char *prop_name);
+
 /*
  * Look up a property in a node and return its contents in a byte
  * array of given length. The property must have at least enough data for
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 1f50022..2d60c8a 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -513,16 +513,6 @@ const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 	return cell;
 }
 
-/**
- * Look in the FDT for a config item with the given name and return its value
- * as a 32-bit integer. The property must have at least 4 bytes of data. The
- * value of the first cell is returned.
- *
- * @param blob		FDT blob to use
- * @param prop_name	Node property name
- * @param default_val	default value to return if the property is not found
- * @return integer value, if found, or default_val if not
- */
 int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val)
 {
@@ -534,3 +524,21 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		return default_val;
 	return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
+
+char *fdtdec_get_config_string(const void *blob, const char *prop_name)
+{
+	const char *nodep;
+	int nodeoffset;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	nodeoffset = fdt_path_offset(blob, "/config");
+	if (nodeoffset < 0)
+		return NULL;
+
+	nodep = fdt_getprop(blob, nodeoffset, prop_name, &len);
+	if (!nodep)
+		return NULL;
+
+	return (char *)nodep;
+}
-- 
1.7.7.3

[PATCH 03/14] fdt: Add fdtdec_decode_region() to decode memory region

[Simon Glass]

A memory region has a start and a size and is often specified in
a node by a 'reg' property. Add a function to decode this information
from the fdt.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   19 +++++++++++++++++++
 lib/fdtdec.c     |   17 +++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e828662..341e6a1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -40,10 +40,12 @@
 typedef u64 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1ULL)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
 #else
 typedef u32 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
 #endif
 
 /* Information obtained about memory from the FDT */
@@ -408,4 +410,21 @@ int fdtdec_get_byte_array(const void *blob, int node, const char *prop_name,
  */
 const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 			     const char *prop_name, int count);
+
+/**
+ * Look up a property in a node which contains a memory region address and
+ * size. Then return a pointer to this address.
+ *
+ * The property must hold one address with a length. This is only tested on
+ * 32-bit machines.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param ptrp		returns pointer to region, or NULL if no address
+ * @param size		returns size of region
+ * @return 0 if ok, -1 on error (propery not found)
+ */
+int fdtdec_decode_region(const void *blob, int node,
+		const char *prop_name, void **ptrp, size_t *size);
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 2d60c8a..5570972 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -542,3 +542,20 @@ char *fdtdec_get_config_string(const void *blob, const char *prop_name)
 
 	return (char *)nodep;
 }
+
+int fdtdec_decode_region(const void *blob, int node,
+		const char *prop_name, void **ptrp, size_t *size)
+{
+	const fdt_addr_t *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	if (!cell || (len != sizeof(fdt_addr_t) * 2))
+		return -1;
+
+	*ptrp = (void *)fdt_addr_to_cpu(*cell);
+	*size = fdt_size_to_cpu(cell[1]);
+	debug("%s: size=%zx\n", __func__, *size);
+	return 0;
+}
-- 
1.7.7.3

[U-Boot] [PATCH 03/14] fdt: Add fdtdec_decode_region() to decode memory region

[Simon Glass]

A memory region has a start and a size and is often specified in
a node by a 'reg' property. Add a function to decode this information
from the fdt.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   19 +++++++++++++++++++
 lib/fdtdec.c     |   17 +++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e828662..341e6a1 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -40,10 +40,12 @@
 typedef u64 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1ULL)
 #define fdt_addr_to_cpu(reg) be64_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be64_to_cpu(reg)
 #else
 typedef u32 fdt_addr_t;
 #define FDT_ADDR_T_NONE (-1U)
 #define fdt_addr_to_cpu(reg) be32_to_cpu(reg)
+#define fdt_size_to_cpu(reg) be32_to_cpu(reg)
 #endif
 
 /* Information obtained about memory from the FDT */
@@ -408,4 +410,21 @@ int fdtdec_get_byte_array(const void *blob, int node, const char *prop_name,
  */
 const u8 *fdtdec_locate_byte_array(const void *blob, int node,
 			     const char *prop_name, int count);
+
+/**
+ * Look up a property in a node which contains a memory region address and
+ * size. Then return a pointer to this address.
+ *
+ * The property must hold one address with a length. This is only tested on
+ * 32-bit machines.
+ *
+ * @param blob		FDT blob
+ * @param node		node to examine
+ * @param prop_name	name of property to find
+ * @param ptrp		returns pointer to region, or NULL if no address
+ * @param size		returns size of region
+ * @return 0 if ok, -1 on error (propery not found)
+ */
+int fdtdec_decode_region(const void *blob, int node,
+		const char *prop_name, void **ptrp, size_t *size);
 #endif
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 2d60c8a..5570972 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -542,3 +542,20 @@ char *fdtdec_get_config_string(const void *blob, const char *prop_name)
 
 	return (char *)nodep;
 }
+
+int fdtdec_decode_region(const void *blob, int node,
+		const char *prop_name, void **ptrp, size_t *size)
+{
+	const fdt_addr_t *cell;
+	int len;
+
+	debug("%s: %s\n", __func__, prop_name);
+	cell = fdt_getprop(blob, node, prop_name, &len);
+	if (!cell || (len != sizeof(fdt_addr_t) * 2))
+		return -1;
+
+	*ptrp = (void *)fdt_addr_to_cpu(*cell);
+	*size = fdt_size_to_cpu(cell[1]);
+	debug("%s: size=%zx\n", __func__, *size);
+	return 0;
+}
-- 
1.7.7.3

[PATCH 04/14] fdt: Add function for decoding multiple gpios globally available

[Simon Glass]

From: Abhilash Kesavan <a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Samsung's SDHCI bindings require multiple gpios to be parsed and
configured at a time. Export the already available fdtdec_decode_gpios
for this purpose.

Signed-off-by: Abhilash Kesavan <a.kesavan-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Commit-Ready: Che-Liang Chiou <clchiou-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   16 ++++++++++++++++
 lib/fdtdec.c     |    5 ++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 341e6a1..e70714b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -345,6 +345,22 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
 		struct fdt_gpio_state *gpio);
 
 /**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob         FDT blob to use
+ * @param node         Node to look at
+ * @param prop_name    Node property name
+ * @param gpio         Array of gpio elements to fill from FDT. This will be
+ *                     untouched if either 0 or an error is returned
+ * @param max_count    Maximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio, int max_count);
+
+/**
  * Set up a GPIO pin according to the provided gpio information. At present this
  * just requests the GPIO.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5570972..32f03cc 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -426,9 +426,8 @@ int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
  * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
  * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
  */
-static int fdtdec_decode_gpios(const void *blob, int node,
-		const char *prop_name, struct fdt_gpio_state *gpio,
-		int max_count)
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio, int max_count)
 {
 	const struct fdt_property *prop;
 	const u32 *cell;
-- 
1.7.7.3

[U-Boot] [PATCH 04/14] fdt: Add function for decoding multiple gpios globally available

[Simon Glass]

From: Abhilash Kesavan <a.kesavan@samsung.com>

Samsung's SDHCI bindings require multiple gpios to be parsed and
configured at a time. Export the already available fdtdec_decode_gpios
for this purpose.

Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Commit-Ready: Che-Liang Chiou <clchiou@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   16 ++++++++++++++++
 lib/fdtdec.c     |    5 ++---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 341e6a1..e70714b 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -345,6 +345,22 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
 		struct fdt_gpio_state *gpio);
 
 /**
+ * Decode a list of GPIOs from an FDT. This creates a list of GPIOs with no
+ * terminating item.
+ *
+ * @param blob         FDT blob to use
+ * @param node         Node to look at
+ * @param prop_name    Node property name
+ * @param gpio         Array of gpio elements to fill from FDT. This will be
+ *                     untouched if either 0 or an error is returned
+ * @param max_count    Maximum number of elements allowed
+ * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
+ * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
+ */
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio, int max_count);
+
+/**
  * Set up a GPIO pin according to the provided gpio information. At present this
  * just requests the GPIO.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 5570972..32f03cc 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -426,9 +426,8 @@ int fdtdec_get_bool(const void *blob, int node, const char *prop_name)
  * @return number of GPIOs read if ok, -FDT_ERR_BADLAYOUT if max_count would
  * be exceeded, or -FDT_ERR_NOTFOUND if the property is missing.
  */
-static int fdtdec_decode_gpios(const void *blob, int node,
-		const char *prop_name, struct fdt_gpio_state *gpio,
-		int max_count)
+int fdtdec_decode_gpios(const void *blob, int node, const char *prop_name,
+		struct fdt_gpio_state *gpio, int max_count)
 {
 	const struct fdt_property *prop;
 	const u32 *cell;
-- 
1.7.7.3

[PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[Simon Glass]

This function is useful outside fdtdec, so export it.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |    9 +++++++++
 lib/fdtdec.c     |    6 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e70714b..e566e47 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,15 @@ int fdtdec_next_alias(const void *blob, const char *name,
 		enum fdt_compat_id id, int *upto);
 
 /**
+ * Look in the FDT for an alias with the given name and return its node.
+ *
+ * @param blob	FDT blob
+ * @param name	alias name to look up
+ * @return node offset if found, or an error code < 0 otherwise
+ */
+int fdtdec_find_alias_node(const void *blob, const char *name);
+
+/**
  * Find the next compatible node for a peripheral.
  *
  * Do the first call with node = 0. This function will return a pointer to
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 32f03cc..16435b7 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -59,12 +59,12 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id)
  * @param name	alias name to look up
  * @return node offset if found, or an error code < 0 otherwise
  */
-static int find_alias_node(const void *blob, const char *name)
+int fdtdec_find_alias_node(const void *blob, const char *name)
 {
 	const char *path;
 	int alias_node;
 
-	debug("find_alias_node: %s\n", name);
+	debug("%s: %s\n", __func__, name);
 	alias_node = fdt_path_offset(blob, "/aliases");
 	if (alias_node < 0)
 		return alias_node;
@@ -171,7 +171,7 @@ int fdtdec_next_alias(const void *blob, const char *name,
 	/* snprintf() is not available */
 	assert(strlen(name) < MAX_STR_LEN);
 	sprintf(str, "%.*s%d", MAX_STR_LEN, name, *upto);
-	node = find_alias_node(blob, str);
+	node = fdtdec_find_alias_node(blob, str);
 	if (node < 0)
 		return node;
 	err = fdt_node_check_compatible(blob, node, compat_names[id]);
-- 
1.7.7.3

[U-Boot] [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[Simon Glass]

This function is useful outside fdtdec, so export it.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |    9 +++++++++
 lib/fdtdec.c     |    6 +++---
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e70714b..e566e47 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,15 @@ int fdtdec_next_alias(const void *blob, const char *name,
 		enum fdt_compat_id id, int *upto);
 
 /**
+ * Look in the FDT for an alias with the given name and return its node.
+ *
+ * @param blob	FDT blob
+ * @param name	alias name to look up
+ * @return node offset if found, or an error code < 0 otherwise
+ */
+int fdtdec_find_alias_node(const void *blob, const char *name);
+
+/**
  * Find the next compatible node for a peripheral.
  *
  * Do the first call with node = 0. This function will return a pointer to
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 32f03cc..16435b7 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -59,12 +59,12 @@ const char *fdtdec_get_compatible(enum fdt_compat_id id)
  * @param name	alias name to look up
  * @return node offset if found, or an error code < 0 otherwise
  */
-static int find_alias_node(const void *blob, const char *name)
+int fdtdec_find_alias_node(const void *blob, const char *name)
 {
 	const char *path;
 	int alias_node;
 
-	debug("find_alias_node: %s\n", name);
+	debug("%s: %s\n", __func__, name);
 	alias_node = fdt_path_offset(blob, "/aliases");
 	if (alias_node < 0)
 		return alias_node;
@@ -171,7 +171,7 @@ int fdtdec_next_alias(const void *blob, const char *name,
 	/* snprintf() is not available */
 	assert(strlen(name) < MAX_STR_LEN);
 	sprintf(str, "%.*s%d", MAX_STR_LEN, name, *upto);
-	node = find_alias_node(blob, str);
+	node = fdtdec_find_alias_node(blob, str);
 	if (node < 0)
 		return node;
 	err = fdt_node_check_compatible(blob, node, compat_names[id]);
-- 
1.7.7.3

Re: [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[David Gibson]

On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote:
> This function is useful outside fdtdec, so export it.

Hrm.  fdt_path_offset() in libfdt itself will already look up aliases
if given a path that doesn't start with '/'.  So it's not clear why
you need this function at all.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[U-Boot] [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[David Gibson]

On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote:
> This function is useful outside fdtdec, so export it.

Hrm.  fdt_path_offset() in libfdt itself will already look up aliases
if given a path that doesn't start with '/'.  So it's not clear why
you need this function at all.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[Simon Glass]

Hi David,

On Thu, Oct 25, 2012 at 9:24 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote:
>> This function is useful outside fdtdec, so export it.
>
> Hrm.  fdt_path_offset() in libfdt itself will already look up aliases
> if given a path that doesn't start with '/'.  So it's not clear why
> you need this function at all.

Ahh, well I won't be needing that patch, then. I will submit one to
remove this function. Thank you.

Regards,
Simon

>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson

[U-Boot] [PATCH 05/14] fdt: Export fdtdec_find_alias_node() function

[Simon Glass]

Hi David,

On Thu, Oct 25, 2012 at 9:24 PM, David Gibson
<david@gibson.dropbear.id.au> wrote:
> On Thu, Oct 25, 2012 at 07:31:02PM -0700, Simon Glass wrote:
>> This function is useful outside fdtdec, so export it.
>
> Hrm.  fdt_path_offset() in libfdt itself will already look up aliases
> if given a path that doesn't start with '/'.  So it's not clear why
> you need this function at all.

Ahh, well I won't be needing that patch, then. I will submit one to
remove this function. Thank you.

Regards,
Simon

>
> --
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson

[PATCH 06/14] fdt: Export fdtdec_lookup() and fix the name

[Simon Glass]

The name of this function is not consistent, so fix it, and export
the function for external use.

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |    2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e566e47..3f1840c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,19 @@ int fdtdec_next_alias(const void *blob, const char *name,
 		enum fdt_compat_id id, int *upto);
 
 /**
+ * Find the compatible ID for a given node.
+ *
+ * Generally each node has at least one compatible string attached to it.
+ * This function looks through our list of known compatible strings and
+ * returns the corresponding ID which matches the compatible string.
+ *
+ * @param blob		FDT blob to use
+ * @param node		Node containing compatible string to find
+ * @return compatible ID, or COMPAT_UNKNOWN if we cannot find a match
+ */
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node);
+
+/**
  * Look in the FDT for an alias with the given name and return its node.
  *
  * @param blob	FDT blob
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16435b7..efe9afe 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -128,7 +128,7 @@ int fdtdec_get_is_enabled(const void *blob, int node)
 	return 1;
 }
 
-enum fdt_compat_id fd_dec_lookup(const void *blob, int node)
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node)
 {
 	enum fdt_compat_id id;
 
-- 
1.7.7.3

[U-Boot] [PATCH 06/14] fdt: Export fdtdec_lookup() and fix the name

[Simon Glass]

The name of this function is not consistent, so fix it, and export
the function for external use.

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   13 +++++++++++++
 lib/fdtdec.c     |    2 +-
 2 files changed, 14 insertions(+), 1 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index e566e47..3f1840c 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -110,6 +110,19 @@ int fdtdec_next_alias(const void *blob, const char *name,
 		enum fdt_compat_id id, int *upto);
 
 /**
+ * Find the compatible ID for a given node.
+ *
+ * Generally each node has at least one compatible string attached to it.
+ * This function looks through our list of known compatible strings and
+ * returns the corresponding ID which matches the compatible string.
+ *
+ * @param blob		FDT blob to use
+ * @param node		Node containing compatible string to find
+ * @return compatible ID, or COMPAT_UNKNOWN if we cannot find a match
+ */
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node);
+
+/**
  * Look in the FDT for an alias with the given name and return its node.
  *
  * @param blob	FDT blob
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 16435b7..efe9afe 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -128,7 +128,7 @@ int fdtdec_get_is_enabled(const void *blob, int node)
 	return 1;
 }
 
-enum fdt_compat_id fd_dec_lookup(const void *blob, int node)
+enum fdt_compat_id fdtdec_lookup(const void *blob, int node)
 {
 	enum fdt_compat_id id;
 
-- 
1.7.7.3

[PATCH 07/14] fdt: Add function to read boolean property

[Simon Glass]

From: Gabe Black <gabeblack-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Signed-off-by: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Commit-Ready: Vincent Palatin <vpalatin-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Commit-Ready: Gabe Black <gabeblack-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   10 ++++++++++
 lib/fdtdec.c     |   14 ++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3f1840c..82fdb99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -408,6 +408,16 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val);
 
 /**
+ * Look in the FDT for a config item with the given name
+ * and return whether it exists.
+ *
+ * @param blob		FDT blob
+ * @param prop_name	property name to look up
+ * @return 1, if it exists, or 0 if not
+ */
+int fdtdec_get_config_bool(const void *blob, const char *prop_name);
+
+/**
  * Look in the FDT for a config item with the given name and return its value
  * as a string.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index efe9afe..fbb2827 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -524,6 +524,20 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 	return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
 
+int fdtdec_get_config_bool(const void *blob, const char *prop_name)
+{
+	int config_node;
+	const void *prop;
+
+	debug("%s: %s\n", __func__, prop_name);
+	config_node = fdt_path_offset(blob, "/config");
+	if (config_node < 0)
+		return 0;
+	prop = fdt_get_property(blob, config_node, prop_name, NULL);
+
+	return prop != NULL;
+}
+
 char *fdtdec_get_config_string(const void *blob, const char *prop_name)
 {
 	const char *nodep;
-- 
1.7.7.3

[U-Boot] [PATCH 07/14] fdt: Add function to read boolean property

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Commit-Ready: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   10 ++++++++++
 lib/fdtdec.c     |   14 ++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 3f1840c..82fdb99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -408,6 +408,16 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 		int default_val);
 
 /**
+ * Look in the FDT for a config item with the given name
+ * and return whether it exists.
+ *
+ * @param blob		FDT blob
+ * @param prop_name	property name to look up
+ * @return 1, if it exists, or 0 if not
+ */
+int fdtdec_get_config_bool(const void *blob, const char *prop_name);
+
+/**
  * Look in the FDT for a config item with the given name and return its value
  * as a string.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index efe9afe..fbb2827 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -524,6 +524,20 @@ int fdtdec_get_config_int(const void *blob, const char *prop_name,
 	return fdtdec_get_int(blob, config_node, prop_name, default_val);
 }
 
+int fdtdec_get_config_bool(const void *blob, const char *prop_name)
+{
+	int config_node;
+	const void *prop;
+
+	debug("%s: %s\n", __func__, prop_name);
+	config_node = fdt_path_offset(blob, "/config");
+	if (config_node < 0)
+		return 0;
+	prop = fdt_get_property(blob, config_node, prop_name, NULL);
+
+	return prop != NULL;
+}
+
 char *fdtdec_get_config_string(const void *blob, const char *prop_name)
 {
 	const char *nodep;
-- 
1.7.7.3

[PATCH 08/14] fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property

[Simon Glass]

From: Che-Liang Chiou <clchiou-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

It decodes a 64-bit value from a property that is at least 8 bytes long.

Signed-off-by: Che-Liang Chiou <clchiou-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   15 +++++++++++++++
 lib/fdtdec.c     |   13 +++++++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 82fdb99..12f73a7 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -191,6 +191,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 		s32 default_val);
 
 /**
+ * Look up a 64-bit integer property in a node and return it. The property
+ * must have at least 8 bytes of data (2 cells). The first two cells are
+ * concatenated to form a 8 bytes value, where the first cell is top half and
+ * the second cell is bottom half.
+ *
+ * @param blob	FDT blob
+ * @param node	node to examine
+ * @param prop_name	name of property to find
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+		uint64_t default_val);
+
+/**
  * Checks whether a node is enabled.
  * This looks for a 'status' property. If this exists, then returns 1 if
  * the status is 'ok' and 0 otherwise. If there is no status property,
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fbb2827..6c417d2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -111,6 +111,19 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 	return default_val;
 }
 
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+		uint64_t default_val)
+{
+	const uint64_t *cell64;
+	int length;
+
+	cell64 = fdt_getprop(blob, node, prop_name, &length);
+	if (!cell64 || length < sizeof(*cell64))
+		return default_val;
+
+	return fdt64_to_cpu(*cell64);
+}
+
 int fdtdec_get_is_enabled(const void *blob, int node)
 {
 	const char *cell;
-- 
1.7.7.3

[U-Boot] [PATCH 08/14] fdt: Add fdtdec_get_uint64 to decode a 64-bit value from a property

[Simon Glass]

From: Che-Liang Chiou <clchiou@chromium.org>

It decodes a 64-bit value from a property that is at least 8 bytes long.

Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   15 +++++++++++++++
 lib/fdtdec.c     |   13 +++++++++++++
 2 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 82fdb99..12f73a7 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -191,6 +191,21 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 		s32 default_val);
 
 /**
+ * Look up a 64-bit integer property in a node and return it. The property
+ * must have at least 8 bytes of data (2 cells). The first two cells are
+ * concatenated to form a 8 bytes value, where the first cell is top half and
+ * the second cell is bottom half.
+ *
+ * @param blob	FDT blob
+ * @param node	node to examine
+ * @param prop_name	name of property to find
+ * @param default_val	default value to return if the property is not found
+ * @return integer value, if found, or default_val if not
+ */
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+		uint64_t default_val);
+
+/**
  * Checks whether a node is enabled.
  * This looks for a 'status' property. If this exists, then returns 1 if
  * the status is 'ok' and 0 otherwise. If there is no status property,
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index fbb2827..6c417d2 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -111,6 +111,19 @@ s32 fdtdec_get_int(const void *blob, int node, const char *prop_name,
 	return default_val;
 }
 
+uint64_t fdtdec_get_uint64(const void *blob, int node, const char *prop_name,
+		uint64_t default_val)
+{
+	const uint64_t *cell64;
+	int length;
+
+	cell64 = fdt_getprop(blob, node, prop_name, &length);
+	if (!cell64 || length < sizeof(*cell64))
+		return default_val;
+
+	return fdt64_to_cpu(*cell64);
+}
+
 int fdtdec_get_is_enabled(const void *blob, int node)
 {
 	const char *cell;
-- 
1.7.7.3

[PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

From: Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

Add get and set gpio functions to fdtdec that take into account the
polarity field in fdtdec_gpio_state.flags.

Signed-off-by: Sean Paul <seanpaul-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 include/fdtdec.h |   16 ++++++++++++++++
 lib/fdtdec.c     |   20 ++++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 12f73a7..17daa99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,22 @@ struct fdt_gpio_state {
 #define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
 
 /**
+ * Read the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio		pointer to the decoded gpio
+ * @return value of the gpio if successful, < 0 if unsuccessful
+ */
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Write the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio		pointer to the decoded gpio
+ * @return 0 if successful
+ */
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
+
+/**
  * Find the next numbered alias for a peripheral. This is used to enumerate
  * all the peripherals of a certain type.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6c417d2..91ba558 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
 	return err == 1 ? 0 : err;
 }
 
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
+{
+	int val;
+
+	if (!fdt_gpio_isvalid(gpio))
+		return -1;
+
+	val = gpio_get_value(gpio->gpio);
+	return gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+}
+
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
+{
+	if (!fdt_gpio_isvalid(gpio))
+		return -1;
+
+	val = gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+	return gpio_set_value(gpio->gpio, val);
+}
+
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
 {
 	/*
-- 
1.7.7.3

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

From: Sean Paul <seanpaul@chromium.org>

Add get and set gpio functions to fdtdec that take into account the
polarity field in fdtdec_gpio_state.flags.

Signed-off-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 include/fdtdec.h |   16 ++++++++++++++++
 lib/fdtdec.c     |   20 ++++++++++++++++++++
 2 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/include/fdtdec.h b/include/fdtdec.h
index 12f73a7..17daa99 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -90,6 +90,22 @@ struct fdt_gpio_state {
 #define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
 
 /**
+ * Read the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio		pointer to the decoded gpio
+ * @return value of the gpio if successful, < 0 if unsuccessful
+ */
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
+
+/**
+ * Write the GPIO taking into account the polarity of the pin.
+ *
+ * @param gpio		pointer to the decoded gpio
+ * @return 0 if successful
+ */
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
+
+/**
  * Find the next numbered alias for a peripheral. This is used to enumerate
  * all the peripherals of a certain type.
  *
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 6c417d2..91ba558 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
 	return err == 1 ? 0 : err;
 }
 
+int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
+{
+	int val;
+
+	if (!fdt_gpio_isvalid(gpio))
+		return -1;
+
+	val = gpio_get_value(gpio->gpio);
+	return gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+}
+
+int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
+{
+	if (!fdt_gpio_isvalid(gpio))
+		return -1;
+
+	val = gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
+	return gpio_set_value(gpio->gpio, val);
+}
+
 int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
 {
 	/*
-- 
1.7.7.3

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Lucas Stach]

Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
> From: Sean Paul <seanpaul@chromium.org>
> 
> Add get and set gpio functions to fdtdec that take into account the
> polarity field in fdtdec_gpio_state.flags.
> 
In another thread Stephen Warren and I came to the conclusion that we
most likely should remove this polarity flag from the GPIO bindings.

Currently it is only for the USB VBUS GPIO which should move over to
regulators once they land in U-Boot. Do you have any other applications
for this flag, so we might reconsider removing it?

> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/fdtdec.h |   16 ++++++++++++++++
>  lib/fdtdec.c     |   20 ++++++++++++++++++++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 12f73a7..17daa99 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -90,6 +90,22 @@ struct fdt_gpio_state {
>  #define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
>  
>  /**
> + * Read the GPIO taking into account the polarity of the pin.
> + *
> + * @param gpio		pointer to the decoded gpio
> + * @return value of the gpio if successful, < 0 if unsuccessful
> + */
> +int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
> +
> +/**
> + * Write the GPIO taking into account the polarity of the pin.
> + *
> + * @param gpio		pointer to the decoded gpio
> + * @return 0 if successful
> + */
> +int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
> +
> +/**
>   * Find the next numbered alias for a peripheral. This is used to enumerate
>   * all the peripherals of a certain type.
>   *
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 6c417d2..91ba558 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
>  	return err == 1 ? 0 : err;
>  }
>  
> +int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
> +{
> +	int val;
> +
> +	if (!fdt_gpio_isvalid(gpio))
> +		return -1;
> +
> +	val = gpio_get_value(gpio->gpio);
> +	return gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
> +}
> +
> +int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
> +{
> +	if (!fdt_gpio_isvalid(gpio))
> +		return -1;
> +
> +	val = gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
> +	return gpio_set_value(gpio->gpio, val);
> +}
> +
>  int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
>  {
>  	/*

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Lucas Stach]

Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
> From: Sean Paul <seanpaul@chromium.org>
> 
> Add get and set gpio functions to fdtdec that take into account the
> polarity field in fdtdec_gpio_state.flags.
> 
In another thread Stephen Warren and I came to the conclusion that we
most likely should remove this polarity flag from the GPIO bindings.

Currently it is only for the USB VBUS GPIO which should move over to
regulators once they land in U-Boot. Do you have any other applications
for this flag, so we might reconsider removing it?

> Signed-off-by: Sean Paul <seanpaul@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  include/fdtdec.h |   16 ++++++++++++++++
>  lib/fdtdec.c     |   20 ++++++++++++++++++++
>  2 files changed, 36 insertions(+), 0 deletions(-)
> 
> diff --git a/include/fdtdec.h b/include/fdtdec.h
> index 12f73a7..17daa99 100644
> --- a/include/fdtdec.h
> +++ b/include/fdtdec.h
> @@ -90,6 +90,22 @@ struct fdt_gpio_state {
>  #define fdt_gpio_isvalid(x) ((x)->gpio != FDT_GPIO_NONE)
>  
>  /**
> + * Read the GPIO taking into account the polarity of the pin.
> + *
> + * @param gpio		pointer to the decoded gpio
> + * @return value of the gpio if successful, < 0 if unsuccessful
> + */
> +int fdtdec_get_gpio(struct fdt_gpio_state *gpio);
> +
> +/**
> + * Write the GPIO taking into account the polarity of the pin.
> + *
> + * @param gpio		pointer to the decoded gpio
> + * @return 0 if successful
> + */
> +int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val);
> +
> +/**
>   * Find the next numbered alias for a peripheral. This is used to enumerate
>   * all the peripherals of a certain type.
>   *
> diff --git a/lib/fdtdec.c b/lib/fdtdec.c
> index 6c417d2..91ba558 100644
> --- a/lib/fdtdec.c
> +++ b/lib/fdtdec.c
> @@ -487,6 +487,26 @@ int fdtdec_decode_gpio(const void *blob, int node, const char *prop_name,
>  	return err == 1 ? 0 : err;
>  }
>  
> +int fdtdec_get_gpio(struct fdt_gpio_state *gpio)
> +{
> +	int val;
> +
> +	if (!fdt_gpio_isvalid(gpio))
> +		return -1;
> +
> +	val = gpio_get_value(gpio->gpio);
> +	return gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
> +}
> +
> +int fdtdec_set_gpio(struct fdt_gpio_state *gpio, int val)
> +{
> +	if (!fdt_gpio_isvalid(gpio))
> +		return -1;
> +
> +	val = gpio->flags & FDT_GPIO_ACTIVE_LOW ? val ^ 1 : val;
> +	return gpio_set_value(gpio->gpio, val);
> +}
> +
>  int fdtdec_setup_gpio(struct fdt_gpio_state *gpio)
>  {
>  	/*

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi,

On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>> From: Sean Paul <seanpaul@chromium.org>
>>
>> Add get and set gpio functions to fdtdec that take into account the
>> polarity field in fdtdec_gpio_state.flags.
>>
> In another thread Stephen Warren and I came to the conclusion that we
> most likely should remove this polarity flag from the GPIO bindings.
>
> Currently it is only for the USB VBUS GPIO which should move over to
> regulators once they land in U-Boot. Do you have any other applications
> for this flag, so we might reconsider removing it?
>

Well, any time you have a flag which is inverted in meaning, it can be
useful. We have several switches on the board which can be active high
or low, and polarity is used for that.

In fact, it would be nice IMO to be able to specify input/output as
well. I know the exynos bindings do this. There is a noddy function
called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
out. I discussed with Stephen some time ago how GPIOs should be
SOC-specific and it should be possible to set up a GPIO with a single
call, as Linux does. The more information there is in the binding, the
more it can do automatically.

Does the Tegra Linux GPIO binding still have a polarity?

Regards,
Simon

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi,

On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>> From: Sean Paul <seanpaul@chromium.org>
>>
>> Add get and set gpio functions to fdtdec that take into account the
>> polarity field in fdtdec_gpio_state.flags.
>>
> In another thread Stephen Warren and I came to the conclusion that we
> most likely should remove this polarity flag from the GPIO bindings.
>
> Currently it is only for the USB VBUS GPIO which should move over to
> regulators once they land in U-Boot. Do you have any other applications
> for this flag, so we might reconsider removing it?
>

Well, any time you have a flag which is inverted in meaning, it can be
useful. We have several switches on the board which can be active high
or low, and polarity is used for that.

In fact, it would be nice IMO to be able to specify input/output as
well. I know the exynos bindings do this. There is a noddy function
called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
out. I discussed with Stephen some time ago how GPIOs should be
SOC-specific and it should be possible to set up a GPIO with a single
call, as Linux does. The more information there is in the binding, the
more it can do automatically.

Does the Tegra Linux GPIO binding still have a polarity?

Regards,
Simon

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Stephen Warren]

On 10/31/2012 05:59 PM, Simon Glass wrote:
> Hi,
> 
> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>> From: Sean Paul <seanpaul@chromium.org>
>>>
>>> Add get and set gpio functions to fdtdec that take into account the
>>> polarity field in fdtdec_gpio_state.flags.
>>>
>> In another thread Stephen Warren and I came to the conclusion that we
>> most likely should remove this polarity flag from the GPIO bindings.
>>
>> Currently it is only for the USB VBUS GPIO which should move over to
>> regulators once they land in U-Boot. Do you have any other applications
>> for this flag, so we might reconsider removing it?
>>
> 
> Well, any time you have a flag which is inverted in meaning, it can be
> useful. We have several switches on the board which can be active high
> or low, and polarity is used for that.
> 
> In fact, it would be nice IMO to be able to specify input/output as
> well. I know the exynos bindings do this. There is a noddy function
> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
> out. I discussed with Stephen some time ago how GPIOs should be
> SOC-specific and it should be possible to set up a GPIO with a single
> call, as Linux does. The more information there is in the binding, the
> more it can do automatically.
> 
> Does the Tegra Linux GPIO binding still have a polarity?

Yes it does, although in practice it can't be used (and hence should
really be removed), since not all GPIO bindings have such a flag, so
there is always a need for a separate property to indicate the polarity
(c.f. fixed-regulator with GPIO control bindings for example).

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Stephen Warren]

On 10/31/2012 05:59 PM, Simon Glass wrote:
> Hi,
> 
> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>> From: Sean Paul <seanpaul@chromium.org>
>>>
>>> Add get and set gpio functions to fdtdec that take into account the
>>> polarity field in fdtdec_gpio_state.flags.
>>>
>> In another thread Stephen Warren and I came to the conclusion that we
>> most likely should remove this polarity flag from the GPIO bindings.
>>
>> Currently it is only for the USB VBUS GPIO which should move over to
>> regulators once they land in U-Boot. Do you have any other applications
>> for this flag, so we might reconsider removing it?
>>
> 
> Well, any time you have a flag which is inverted in meaning, it can be
> useful. We have several switches on the board which can be active high
> or low, and polarity is used for that.
> 
> In fact, it would be nice IMO to be able to specify input/output as
> well. I know the exynos bindings do this. There is a noddy function
> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
> out. I discussed with Stephen some time ago how GPIOs should be
> SOC-specific and it should be possible to set up a GPIO with a single
> call, as Linux does. The more information there is in the binding, the
> more it can do automatically.
> 
> Does the Tegra Linux GPIO binding still have a polarity?

Yes it does, although in practice it can't be used (and hence should
really be removed), since not all GPIO bindings have such a flag, so
there is always a need for a separate property to indicate the polarity
(c.f. fixed-regulator with GPIO control bindings for example).

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/31/2012 05:59 PM, Simon Glass wrote:
>> Hi,
>>
>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>
>>>> Add get and set gpio functions to fdtdec that take into account the
>>>> polarity field in fdtdec_gpio_state.flags.
>>>>
>>> In another thread Stephen Warren and I came to the conclusion that we
>>> most likely should remove this polarity flag from the GPIO bindings.
>>>
>>> Currently it is only for the USB VBUS GPIO which should move over to
>>> regulators once they land in U-Boot. Do you have any other applications
>>> for this flag, so we might reconsider removing it?
>>>
>>
>> Well, any time you have a flag which is inverted in meaning, it can be
>> useful. We have several switches on the board which can be active high
>> or low, and polarity is used for that.
>>
>> In fact, it would be nice IMO to be able to specify input/output as
>> well. I know the exynos bindings do this. There is a noddy function
>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>> out. I discussed with Stephen some time ago how GPIOs should be
>> SOC-specific and it should be possible to set up a GPIO with a single
>> call, as Linux does. The more information there is in the binding, the
>> more it can do automatically.
>>
>> Does the Tegra Linux GPIO binding still have a polarity?
>
> Yes it does, although in practice it can't be used (and hence should
> really be removed), since not all GPIO bindings have such a flag, so
> there is always a need for a separate property to indicate the polarity
> (c.f. fixed-regulator with GPIO control bindings for example).
>

I've had a bit of time to look into this. I see that the regulator
framework in the kernel seems to be used for various control purposes,
and provides useful polarity stuff. I was rather hoping that GPIOs
could be a bit more high level in U-Boot, with information about:

- input/output
- drive strength
- polarity
- pull up/down

In fact most of these are actually supported in most kernel bindings,
but of course it is binding-specific. Would it be useful to ask for a
polarity setting in the GPIO. When it is not available, the polarity
would then always be normal.

This might avoid moving polarity and input/output selecting down into
each client of the gpio, which seems undesirable in general.

Should we consider a second level of indirection for GPIOs to support
these non-binding features? It seems a bit complicated though.

However, if it is too late to do this, or not desirable for some
reason, then we should just drop this patch.

Regards,
Simon

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 10/31/2012 05:59 PM, Simon Glass wrote:
>> Hi,
>>
>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>
>>>> Add get and set gpio functions to fdtdec that take into account the
>>>> polarity field in fdtdec_gpio_state.flags.
>>>>
>>> In another thread Stephen Warren and I came to the conclusion that we
>>> most likely should remove this polarity flag from the GPIO bindings.
>>>
>>> Currently it is only for the USB VBUS GPIO which should move over to
>>> regulators once they land in U-Boot. Do you have any other applications
>>> for this flag, so we might reconsider removing it?
>>>
>>
>> Well, any time you have a flag which is inverted in meaning, it can be
>> useful. We have several switches on the board which can be active high
>> or low, and polarity is used for that.
>>
>> In fact, it would be nice IMO to be able to specify input/output as
>> well. I know the exynos bindings do this. There is a noddy function
>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>> out. I discussed with Stephen some time ago how GPIOs should be
>> SOC-specific and it should be possible to set up a GPIO with a single
>> call, as Linux does. The more information there is in the binding, the
>> more it can do automatically.
>>
>> Does the Tegra Linux GPIO binding still have a polarity?
>
> Yes it does, although in practice it can't be used (and hence should
> really be removed), since not all GPIO bindings have such a flag, so
> there is always a need for a separate property to indicate the polarity
> (c.f. fixed-regulator with GPIO control bindings for example).
>

I've had a bit of time to look into this. I see that the regulator
framework in the kernel seems to be used for various control purposes,
and provides useful polarity stuff. I was rather hoping that GPIOs
could be a bit more high level in U-Boot, with information about:

- input/output
- drive strength
- polarity
- pull up/down

In fact most of these are actually supported in most kernel bindings,
but of course it is binding-specific. Would it be useful to ask for a
polarity setting in the GPIO. When it is not available, the polarity
would then always be normal.

This might avoid moving polarity and input/output selecting down into
each client of the gpio, which seems undesirable in general.

Should we consider a second level of indirection for GPIOs to support
these non-binding features? It seems a bit complicated though.

However, if it is too late to do this, or not desirable for some
reason, then we should just drop this patch.

Regards,
Simon

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Stephen Warren]

On 11/15/2012 04:31 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 10/31/2012 05:59 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>>
>>>>> Add get and set gpio functions to fdtdec that take into account the
>>>>> polarity field in fdtdec_gpio_state.flags.
>>>>>
>>>> In another thread Stephen Warren and I came to the conclusion that we
>>>> most likely should remove this polarity flag from the GPIO bindings.
>>>>
>>>> Currently it is only for the USB VBUS GPIO which should move over to
>>>> regulators once they land in U-Boot. Do you have any other applications
>>>> for this flag, so we might reconsider removing it?
>>>>
>>>
>>> Well, any time you have a flag which is inverted in meaning, it can be
>>> useful. We have several switches on the board which can be active high
>>> or low, and polarity is used for that.
>>>
>>> In fact, it would be nice IMO to be able to specify input/output as
>>> well. I know the exynos bindings do this. There is a noddy function
>>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>>> out. I discussed with Stephen some time ago how GPIOs should be
>>> SOC-specific and it should be possible to set up a GPIO with a single
>>> call, as Linux does. The more information there is in the binding, the
>>> more it can do automatically.
>>>
>>> Does the Tegra Linux GPIO binding still have a polarity?
>>
>> Yes it does, although in practice it can't be used (and hence should
>> really be removed), since not all GPIO bindings have such a flag, so
>> there is always a need for a separate property to indicate the polarity
>> (c.f. fixed-regulator with GPIO control bindings for example).
>>
> 
> I've had a bit of time to look into this. I see that the regulator
> framework in the kernel seems to be used for various control purposes,
> and provides useful polarity stuff. I was rather hoping that GPIOs
> could be a bit more high level in U-Boot, with information about:
> 
> - input/output
> - drive strength
> - polarity
> - pull up/down
> 
> In fact most of these are actually supported in most kernel bindings,
> but of course it is binding-specific. Would it be useful to ask for a
> polarity setting in the GPIO. When it is not available, the polarity
> would then always be normal.
> 
> This might avoid moving polarity and input/output selecting down into
> each client of the gpio, which seems undesirable in general.
> 
> Should we consider a second level of indirection for GPIOs to support
> these non-binding features? It seems a bit complicated though.
> 
> However, if it is too late to do this, or not desirable for some
> reason, then we should just drop this patch.

The issue may not be bad enough we have to drop flag usage. It's also
being discussed at:

http://www.spinics.net/lists/arm-kernel/msg206299.html

I'd recommend seeing how that pans out before making a decision whether
to start/keep using flags or not.

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Stephen Warren]

On 11/15/2012 04:31 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>> On 10/31/2012 05:59 PM, Simon Glass wrote:
>>> Hi,
>>>
>>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>>
>>>>> Add get and set gpio functions to fdtdec that take into account the
>>>>> polarity field in fdtdec_gpio_state.flags.
>>>>>
>>>> In another thread Stephen Warren and I came to the conclusion that we
>>>> most likely should remove this polarity flag from the GPIO bindings.
>>>>
>>>> Currently it is only for the USB VBUS GPIO which should move over to
>>>> regulators once they land in U-Boot. Do you have any other applications
>>>> for this flag, so we might reconsider removing it?
>>>>
>>>
>>> Well, any time you have a flag which is inverted in meaning, it can be
>>> useful. We have several switches on the board which can be active high
>>> or low, and polarity is used for that.
>>>
>>> In fact, it would be nice IMO to be able to specify input/output as
>>> well. I know the exynos bindings do this. There is a noddy function
>>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>>> out. I discussed with Stephen some time ago how GPIOs should be
>>> SOC-specific and it should be possible to set up a GPIO with a single
>>> call, as Linux does. The more information there is in the binding, the
>>> more it can do automatically.
>>>
>>> Does the Tegra Linux GPIO binding still have a polarity?
>>
>> Yes it does, although in practice it can't be used (and hence should
>> really be removed), since not all GPIO bindings have such a flag, so
>> there is always a need for a separate property to indicate the polarity
>> (c.f. fixed-regulator with GPIO control bindings for example).
>>
> 
> I've had a bit of time to look into this. I see that the regulator
> framework in the kernel seems to be used for various control purposes,
> and provides useful polarity stuff. I was rather hoping that GPIOs
> could be a bit more high level in U-Boot, with information about:
> 
> - input/output
> - drive strength
> - polarity
> - pull up/down
> 
> In fact most of these are actually supported in most kernel bindings,
> but of course it is binding-specific. Would it be useful to ask for a
> polarity setting in the GPIO. When it is not available, the polarity
> would then always be normal.
> 
> This might avoid moving polarity and input/output selecting down into
> each client of the gpio, which seems undesirable in general.
> 
> Should we consider a second level of indirection for GPIOs to support
> these non-binding features? It seems a bit complicated though.
> 
> However, if it is too late to do this, or not desirable for some
> reason, then we should just drop this patch.

The issue may not be bad enough we have to drop flag usage. It's also
being discussed at:

http://www.spinics.net/lists/arm-kernel/msg206299.html

I'd recommend seeing how that pans out before making a decision whether
to start/keep using flags or not.

Re: [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Thu, Nov 15, 2012 at 3:46 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/15/2012 04:31 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 10/31/2012 05:59 PM, Simon Glass wrote:
>>>> Hi,
>>>>
>>>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>>>
>>>>>> Add get and set gpio functions to fdtdec that take into account the
>>>>>> polarity field in fdtdec_gpio_state.flags.
>>>>>>
>>>>> In another thread Stephen Warren and I came to the conclusion that we
>>>>> most likely should remove this polarity flag from the GPIO bindings.
>>>>>
>>>>> Currently it is only for the USB VBUS GPIO which should move over to
>>>>> regulators once they land in U-Boot. Do you have any other applications
>>>>> for this flag, so we might reconsider removing it?
>>>>>
>>>>
>>>> Well, any time you have a flag which is inverted in meaning, it can be
>>>> useful. We have several switches on the board which can be active high
>>>> or low, and polarity is used for that.
>>>>
>>>> In fact, it would be nice IMO to be able to specify input/output as
>>>> well. I know the exynos bindings do this. There is a noddy function
>>>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>>>> out. I discussed with Stephen some time ago how GPIOs should be
>>>> SOC-specific and it should be possible to set up a GPIO with a single
>>>> call, as Linux does. The more information there is in the binding, the
>>>> more it can do automatically.
>>>>
>>>> Does the Tegra Linux GPIO binding still have a polarity?
>>>
>>> Yes it does, although in practice it can't be used (and hence should
>>> really be removed), since not all GPIO bindings have such a flag, so
>>> there is always a need for a separate property to indicate the polarity
>>> (c.f. fixed-regulator with GPIO control bindings for example).
>>>
>>
>> I've had a bit of time to look into this. I see that the regulator
>> framework in the kernel seems to be used for various control purposes,
>> and provides useful polarity stuff. I was rather hoping that GPIOs
>> could be a bit more high level in U-Boot, with information about:
>>
>> - input/output
>> - drive strength
>> - polarity
>> - pull up/down
>>
>> In fact most of these are actually supported in most kernel bindings,
>> but of course it is binding-specific. Would it be useful to ask for a
>> polarity setting in the GPIO. When it is not available, the polarity
>> would then always be normal.
>>
>> This might avoid moving polarity and input/output selecting down into
>> each client of the gpio, which seems undesirable in general.
>>
>> Should we consider a second level of indirection for GPIOs to support
>> these non-binding features? It seems a bit complicated though.
>>
>> However, if it is too late to do this, or not desirable for some
>> reason, then we should just drop this patch.
>
> The issue may not be bad enough we have to drop flag usage. It's also
> being discussed at:
>
> http://www.spinics.net/lists/arm-kernel/msg206299.html
>
> I'd recommend seeing how that pans out before making a decision whether
> to start/keep using flags or not.
>

Thanks, will await news.

Regards,
Simon

[U-Boot] [PATCH 09/14] fdt: Add polarity-aware gpio functions to fdtdec

[Simon Glass]

Hi Stephen,

On Thu, Nov 15, 2012 at 3:46 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 11/15/2012 04:31 PM, Simon Glass wrote:
>> Hi Stephen,
>>
>> On Wed, Oct 31, 2012 at 9:50 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
>>> On 10/31/2012 05:59 PM, Simon Glass wrote:
>>>> Hi,
>>>>
>>>> On Fri, Oct 26, 2012 at 12:17 AM, Lucas Stach <dev@lynxeye.de> wrote:
>>>>> Am Donnerstag, den 25.10.2012, 19:31 -0700 schrieb Simon Glass:
>>>>>> From: Sean Paul <seanpaul@chromium.org>
>>>>>>
>>>>>> Add get and set gpio functions to fdtdec that take into account the
>>>>>> polarity field in fdtdec_gpio_state.flags.
>>>>>>
>>>>> In another thread Stephen Warren and I came to the conclusion that we
>>>>> most likely should remove this polarity flag from the GPIO bindings.
>>>>>
>>>>> Currently it is only for the USB VBUS GPIO which should move over to
>>>>> regulators once they land in U-Boot. Do you have any other applications
>>>>> for this flag, so we might reconsider removing it?
>>>>>
>>>>
>>>> Well, any time you have a flag which is inverted in meaning, it can be
>>>> useful. We have several switches on the board which can be active high
>>>> or low, and polarity is used for that.
>>>>
>>>> In fact, it would be nice IMO to be able to specify input/output as
>>>> well. I know the exynos bindings do this. There is a noddy function
>>>> called fdtdec_setup_gpio() in U-Boot which really needs to be sorted
>>>> out. I discussed with Stephen some time ago how GPIOs should be
>>>> SOC-specific and it should be possible to set up a GPIO with a single
>>>> call, as Linux does. The more information there is in the binding, the
>>>> more it can do automatically.
>>>>
>>>> Does the Tegra Linux GPIO binding still have a polarity?
>>>
>>> Yes it does, although in practice it can't be used (and hence should
>>> really be removed), since not all GPIO bindings have such a flag, so
>>> there is always a need for a separate property to indicate the polarity
>>> (c.f. fixed-regulator with GPIO control bindings for example).
>>>
>>
>> I've had a bit of time to look into this. I see that the regulator
>> framework in the kernel seems to be used for various control purposes,
>> and provides useful polarity stuff. I was rather hoping that GPIOs
>> could be a bit more high level in U-Boot, with information about:
>>
>> - input/output
>> - drive strength
>> - polarity
>> - pull up/down
>>
>> In fact most of these are actually supported in most kernel bindings,
>> but of course it is binding-specific. Would it be useful to ask for a
>> polarity setting in the GPIO. When it is not available, the polarity
>> would then always be normal.
>>
>> This might avoid moving polarity and input/output selecting down into
>> each client of the gpio, which seems undesirable in general.
>>
>> Should we consider a second level of indirection for GPIOs to support
>> these non-binding features? It seems a bit complicated though.
>>
>> However, if it is too late to do this, or not desirable for some
>> reason, then we should just drop this patch.
>
> The issue may not be bad enough we have to drop flag usage. It's also
> being discussed at:
>
> http://www.spinics.net/lists/arm-kernel/msg206299.html
>
> I'd recommend seeing how that pans out before making a decision whether
> to start/keep using flags or not.
>

Thanks, will await news.

Regards,
Simon

[PATCH 11/14] fdt: Tell the FDT library where the device tree is

[Simon Glass]

From: Gabe Black <gabeblack-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

This change adds a call to set_working_fdt_addr near the end of u-boot
initialization which tells the fdt command/library where the device tree is.
This makes it possible to use the fdt command to look at the active device tree
since otherwise there would be no way to know what address it was at to set
things up manually.

Signed-off-by: Gabe Black <gabeblack-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 common/main.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 23a68ee..cf1b5f9 100644
--- a/common/main.c
+++ b/common/main.c
@@ -45,6 +45,10 @@
 #include <fdtdec.h>
 #endif
 
+#ifdef CONFIG_OF_LIBFDT
+#include <fdt_support.h>
+#endif /* CONFIG_OF_LIBFDT */
+
 #include <post.h>
 #include <linux/ctype.h>
 #include <menu.h>
@@ -418,6 +422,10 @@ void main_loop (void)
 #endif /* CONFIG_MENUKEY */
 #endif /* CONFIG_BOOTDELAY */
 
+#if defined CONFIG_OF_CONTROL
+	set_working_fdt_addr((void *)gd->fdt_blob);
+#endif /* CONFIG_OF_CONTROL */
+
 	/*
 	 * Main Loop for Monitor Command Processing
 	 */
-- 
1.7.7.3

[U-Boot] [PATCH 11/14] fdt: Tell the FDT library where the device tree is

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

This change adds a call to set_working_fdt_addr near the end of u-boot
initialization which tells the fdt command/library where the device tree is.
This makes it possible to use the fdt command to look at the active device tree
since otherwise there would be no way to know what address it was at to set
things up manually.

Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 23a68ee..cf1b5f9 100644
--- a/common/main.c
+++ b/common/main.c
@@ -45,6 +45,10 @@
 #include <fdtdec.h>
 #endif
 
+#ifdef CONFIG_OF_LIBFDT
+#include <fdt_support.h>
+#endif /* CONFIG_OF_LIBFDT */
+
 #include <post.h>
 #include <linux/ctype.h>
 #include <menu.h>
@@ -418,6 +422,10 @@ void main_loop (void)
 #endif /* CONFIG_MENUKEY */
 #endif /* CONFIG_BOOTDELAY */
 
+#if defined CONFIG_OF_CONTROL
+	set_working_fdt_addr((void *)gd->fdt_blob);
+#endif /* CONFIG_OF_CONTROL */
+
 	/*
 	 * Main Loop for Monitor Command Processing
 	 */
-- 
1.7.7.3

[PATCH 12/14] fdt: Allow device tree to specify secure booting

[Simon Glass]

From: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>

When secure booting is chosen:
* The u-boot shell is never invoked during boot--we just do a simple
  table lookup to find the command.  This means we could even remove
  the shell parsing from u-boot and still be able to boot.
* The boot command can't be interruped.
* Failure doesn't cause us to fall back to the shell.

Signed-off-by: Gabe Black <gabeblack-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Signed-off-by: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
 common/main.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index cf1b5f9..03c63b4 100644
--- a/common/main.c
+++ b/common/main.c
@@ -283,6 +283,59 @@ int abortboot(int bootdelay)
 # endif	/* CONFIG_AUTOBOOT_KEYED */
 #endif	/* CONFIG_BOOTDELAY >= 0  */
 
+/*
+ * Runs the given boot command securely.  Specifically:
+ * - Doesn't run the command with the shell (run_command or parse_string_outer),
+ *   since that's a lot of code surface that an attacker might exploit.
+ *   Because of this, we don't do any argument parsing--the secure boot command
+ *   has to be a full-fledged u-boot command.
+ * - Doesn't check for keypresses before booting, since that could be a
+ *   security hole; also disables Ctrl-C.
+ * - Doesn't allow the command to return.
+ *
+ * Upon any failures, this function will drop into an infinite loop after
+ * printing the error message to console.
+ */
+
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+	defined(CONFIG_OF_CONTROL)
+static void secure_boot_cmd(char *cmd)
+{
+	cmd_tbl_t *cmdtp;
+	int rc;
+
+	if (!cmd) {
+		printf("## Error: Secure boot command not specified\n");
+		goto err;
+	}
+
+	/* Disable Ctrl-C just in case some command is used that checks it. */
+	disable_ctrlc(1);
+
+	/* Find the command directly. */
+	cmdtp = find_cmd(cmd);
+	if (!cmdtp) {
+		printf("## Error: \"%s\" not defined\n", cmd);
+		goto err;
+	}
+
+	/* Run the command, forcing no flags and faking argc and argv. */
+	rc = (cmdtp->cmd)(cmdtp, 0, 1, &cmd);
+
+	/* Shouldn't ever return from boot command. */
+	printf("## Error: \"%s\" returned (code %d)\n", cmd, rc);
+
+err:
+	/*
+	 * Not a whole lot to do here.  Rebooting won't help much, since we'll
+	 * just end up right back here.  Just loop.
+	 */
+	hang();
+}
+
+#endif /* CONFIG_OF_CONTROL */
+
+
 /****************************************************************************/
 
 void main_loop (void)
@@ -397,6 +450,15 @@ void main_loop (void)
 	env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
 	if (env)
 		s = env;
+
+	/*
+	 * If the bootsecure option was chosen, use secure_boot_cmd().
+	 * Always use 'env' in this case, since bootsecure requres that the
+	 * bootcmd was specified in the FDT too.
+	 */
+	if (fdtdec_get_config_int(gd->fdt_blob, "bootsecure", 0))
+		secure_boot_cmd(env);
+
 #endif /* CONFIG_OF_CONTROL */
 
 	debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
-- 
1.7.7.3

[U-Boot] [PATCH 12/14] fdt: Allow device tree to specify secure booting

[Simon Glass]

From: Doug Anderson <dianders@chromium.org>

When secure booting is chosen:
* The u-boot shell is never invoked during boot--we just do a simple
  table lookup to find the command.  This means we could even remove
  the shell parsing from u-boot and still be able to boot.
* The boot command can't be interruped.
* Failure doesn't cause us to fall back to the shell.

Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |   62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 62 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index cf1b5f9..03c63b4 100644
--- a/common/main.c
+++ b/common/main.c
@@ -283,6 +283,59 @@ int abortboot(int bootdelay)
 # endif	/* CONFIG_AUTOBOOT_KEYED */
 #endif	/* CONFIG_BOOTDELAY >= 0  */
 
+/*
+ * Runs the given boot command securely.  Specifically:
+ * - Doesn't run the command with the shell (run_command or parse_string_outer),
+ *   since that's a lot of code surface that an attacker might exploit.
+ *   Because of this, we don't do any argument parsing--the secure boot command
+ *   has to be a full-fledged u-boot command.
+ * - Doesn't check for keypresses before booting, since that could be a
+ *   security hole; also disables Ctrl-C.
+ * - Doesn't allow the command to return.
+ *
+ * Upon any failures, this function will drop into an infinite loop after
+ * printing the error message to console.
+ */
+
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+	defined(CONFIG_OF_CONTROL)
+static void secure_boot_cmd(char *cmd)
+{
+	cmd_tbl_t *cmdtp;
+	int rc;
+
+	if (!cmd) {
+		printf("## Error: Secure boot command not specified\n");
+		goto err;
+	}
+
+	/* Disable Ctrl-C just in case some command is used that checks it. */
+	disable_ctrlc(1);
+
+	/* Find the command directly. */
+	cmdtp = find_cmd(cmd);
+	if (!cmdtp) {
+		printf("## Error: \"%s\" not defined\n", cmd);
+		goto err;
+	}
+
+	/* Run the command, forcing no flags and faking argc and argv. */
+	rc = (cmdtp->cmd)(cmdtp, 0, 1, &cmd);
+
+	/* Shouldn't ever return from boot command. */
+	printf("## Error: \"%s\" returned (code %d)\n", cmd, rc);
+
+err:
+	/*
+	 * Not a whole lot to do here.  Rebooting won't help much, since we'll
+	 * just end up right back here.  Just loop.
+	 */
+	hang();
+}
+
+#endif /* CONFIG_OF_CONTROL */
+
+
 /****************************************************************************/
 
 void main_loop (void)
@@ -397,6 +450,15 @@ void main_loop (void)
 	env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
 	if (env)
 		s = env;
+
+	/*
+	 * If the bootsecure option was chosen, use secure_boot_cmd().
+	 * Always use 'env' in this case, since bootsecure requres that the
+	 * bootcmd was specified in the FDT too.
+	 */
+	if (fdtdec_get_config_int(gd->fdt_blob, "bootsecure", 0))
+		secure_boot_cmd(env);
+
 #endif /* CONFIG_OF_CONTROL */
 
 	debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
-- 
1.7.7.3

[PATCH 10/14] fdt: Load boot command from device tree

[Simon Glass]

From: Che-Liang Chiou <clchiou@chromium.org>

Load boot command from /config/bootcmd of device tree if present.

Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/common/main.c b/common/main.c
index 9507cec..23a68ee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -30,6 +30,7 @@
 #include <common.h>
 #include <watchdog.h>
 #include <command.h>
+#include <fdtdec.h>
 #include <malloc.h>
 #include <version.h>
 #ifdef CONFIG_MODEM_SUPPORT
@@ -40,6 +41,10 @@
 #include <hush.h>
 #endif
 
+#ifdef CONFIG_OF_CONTROL
+#include <fdtdec.h>
+#endif
+
 #include <post.h>
 #include <linux/ctype.h>
 #include <menu.h>
@@ -284,7 +289,10 @@ void main_loop (void)
 	int rc = 1;
 	int flag;
 #endif
-
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+		defined(CONFIG_OF_CONTROL)
+	char *env;
+#endif
 #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
 	char *s;
 	int bootdelay;
@@ -380,6 +388,12 @@ void main_loop (void)
 	else
 #endif /* CONFIG_BOOTCOUNT_LIMIT */
 		s = getenv ("bootcmd");
+#ifdef CONFIG_OF_CONTROL
+	/* Allow the fdt to override the boot command */
+	env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
+	if (env)
+		s = env;
+#endif /* CONFIG_OF_CONTROL */
 
 	debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
 
-- 
1.7.7.3

[U-Boot] [PATCH 10/14] fdt: Load boot command from device tree

[Simon Glass]

From: Che-Liang Chiou <clchiou@chromium.org>

Load boot command from /config/bootcmd of device tree if present.

Signed-off-by: Tom Wai-Hong Tam <waihong@chromium.org>
Signed-off-by: Che-Liang Chiou <clchiou@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |   16 +++++++++++++++-
 1 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/common/main.c b/common/main.c
index 9507cec..23a68ee 100644
--- a/common/main.c
+++ b/common/main.c
@@ -30,6 +30,7 @@
 #include <common.h>
 #include <watchdog.h>
 #include <command.h>
+#include <fdtdec.h>
 #include <malloc.h>
 #include <version.h>
 #ifdef CONFIG_MODEM_SUPPORT
@@ -40,6 +41,10 @@
 #include <hush.h>
 #endif
 
+#ifdef CONFIG_OF_CONTROL
+#include <fdtdec.h>
+#endif
+
 #include <post.h>
 #include <linux/ctype.h>
 #include <menu.h>
@@ -284,7 +289,10 @@ void main_loop (void)
 	int rc = 1;
 	int flag;
 #endif
-
+#if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0) && \
+		defined(CONFIG_OF_CONTROL)
+	char *env;
+#endif
 #if defined(CONFIG_BOOTDELAY) && (CONFIG_BOOTDELAY >= 0)
 	char *s;
 	int bootdelay;
@@ -380,6 +388,12 @@ void main_loop (void)
 	else
 #endif /* CONFIG_BOOTCOUNT_LIMIT */
 		s = getenv ("bootcmd");
+#ifdef CONFIG_OF_CONTROL
+	/* Allow the fdt to override the boot command */
+	env = fdtdec_get_config_string(gd->fdt_blob, "bootcmd");
+	if (env)
+		s = env;
+#endif /* CONFIG_OF_CONTROL */
 
 	debug ("### main_loop: bootcmd=\"%s\"\n", s ? s : "<UNDEFINED>");
 
-- 
1.7.7.3

[PATCH 13/14] fdt: Add option to default to most compatible conf in a fit image

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.

In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.

Signed-off-by: Gabe Black <gabeblack@google.com>

Commit-Ready: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 README             |   11 +++++
 common/cmd_bootm.c |   11 +++++
 common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/image.h    |    1 +
 4 files changed, 150 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 69da2b8..3912150 100644
--- a/README
+++ b/README
@@ -2582,6 +2582,17 @@ FIT uImage format:
  -150	common/cmd_nand.c	Incorrect FIT image format
   151	common/cmd_nand.c	FIT image format OK
 
+- FIT image support:
+		CONFIG_FIT
+		Enable support for the FIT uImage format.
+
+		CONFIG_FIT_BEST_MATCH
+		When no configuration is explicitly selected, default to the
+		one whose fdt's compatibility field best matches that of
+		U-Boot itself. A match is considered "best" if it matches the
+		most specific compatibility entry of U-Boot's fdt's root node.
+		The order of entries in the configuration's fdt is ignored.
+
 - Standalone program support:
 		CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 83fa5d7..4e6042c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -949,8 +949,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
 			 * node
 			 */
 			bootstage_mark(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
+#ifdef CONFIG_FIT_BEST_MATCH
+			if (fit_uname_config)
+				cfg_noffset =
+					fit_conf_get_node(fit_hdr,
+							  fit_uname_config);
+			else
+				cfg_noffset =
+					fit_conf_find_compat(fit_hdr,
+							     gd->fdt_blob);
+#else
 			cfg_noffset = fit_conf_get_node(fit_hdr,
 							fit_uname_config);
+#endif
 			if (cfg_noffset < 0) {
 				bootstage_error(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
 				return NULL;
diff --git a/common/image.c b/common/image.c
index 750a98b..8877395 100644
--- a/common/image.c
+++ b/common/image.c
@@ -3049,6 +3049,133 @@ int fit_check_format(const void *fit)
 	return 1;
 }
 
+
+/**
+ * fit_conf_find_compat
+ * @fit: pointer to the FIT format image header
+ * @fdt: pointer to the device tree to compare against
+ *
+ * fit_conf_find_compat() attempts to find the configuration whose fdt is the
+ * most compatible with the passed in device tree.
+ *
+ * Example:
+ *
+ * / o image-tree
+ *   |-o images
+ *   | |-o fdt@1
+ *   | |-o fdt@2
+ *   |
+ *   |-o configurations
+ *     |-o config@1
+ *     | |-fdt = fdt@1
+ *     |
+ *     |-o config@2
+ *       |-fdt = fdt@2
+ *
+ * / o U-Boot fdt
+ *   |-compatible = "foo,bar", "bim,bam"
+ *
+ * / o kernel fdt1
+ *   |-compatible = "foo,bar",
+ *
+ * / o kernel fdt2
+ *   |-compatible = "bim,bam", "baz,biz"
+ *
+ * Configuration 1 would be picked because the first string in U-Boot's
+ * compatible list, "foo,bar", matches a compatible string in the root of fdt1.
+ * "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
+ *
+ * returns:
+ *     offset to the configuration to use if one was found
+ *     -1 otherwise
+ */
+int fit_conf_find_compat(const void *fit, const void *fdt)
+{
+	int ndepth = 0;
+	int noffset, confs_noffset, images_noffset;
+	const void *fdt_compat;
+	int fdt_compat_len;
+	int best_match_offset = 0;
+	int best_match_pos = 0;
+
+	confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
+	images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+	if (confs_noffset < 0 || images_noffset < 0) {
+		debug("Can't find configurations or images nodes.\n");
+		return -1;
+	}
+
+	fdt_compat = fdt_getprop(fdt, 0, "compatible", &fdt_compat_len);
+	if (!fdt_compat) {
+		debug("Fdt for comparison has no \"compatible\" property.\n");
+		return -1;
+	}
+
+	/*
+	 * Loop over the configurations in the FIT image.
+	 */
+	for (noffset = fdt_next_node(fit, confs_noffset, &ndepth);
+			(noffset >= 0) && (ndepth > 0);
+			noffset = fdt_next_node(fit, noffset, &ndepth)) {
+		const void *kfdt;
+		const char *kfdt_name;
+		int kfdt_noffset;
+		const char *cur_fdt_compat;
+		int len;
+		size_t size;
+		int i;
+
+		if (ndepth > 1)
+			continue;
+
+		kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
+		if (!kfdt_name) {
+			debug("No fdt property found.\n");
+			continue;
+		}
+		kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
+						  kfdt_name);
+		if (kfdt_noffset < 0) {
+			debug("No image node named \"%s\" found.\n",
+			      kfdt_name);
+			continue;
+		}
+		/*
+		 * Get a pointer to this configuration's fdt.
+		 */
+		if (fit_image_get_data(fit, kfdt_noffset, &kfdt, &size)) {
+			debug("Failed to get fdt \"%s\".\n", kfdt_name);
+			continue;
+		}
+
+		len = fdt_compat_len;
+		cur_fdt_compat = fdt_compat;
+		/*
+		 * Look for a match for each U-Boot compatibility string in
+		 * turn in this configuration's fdt.
+		 */
+		for (i = 0; len > 0 &&
+		     (!best_match_offset || best_match_pos > i); i++) {
+			int cur_len = strlen(cur_fdt_compat) + 1;
+
+			if (!fdt_node_check_compatible(kfdt, 0,
+						       cur_fdt_compat)) {
+				best_match_offset = noffset;
+				best_match_pos = i;
+				break;
+			}
+			len -= cur_len;
+			cur_fdt_compat += cur_len;
+		}
+	}
+	if (!best_match_offset) {
+		debug("No match found.\n");
+		return -1;
+	}
+
+	return best_match_offset;
+}
+
 /**
  * fit_conf_get_node - get node offset for configuration of a given unit name
  * @fit: pointer to the FIT format image header
diff --git a/include/image.h b/include/image.h
index 4e5863f..d786559 100644
--- a/include/image.h
+++ b/include/image.h
@@ -614,6 +614,7 @@ int fit_image_check_type(const void *fit, int noffset, uint8_t type);
 int fit_image_check_comp(const void *fit, int noffset, uint8_t comp);
 int fit_check_format(const void *fit);
 
+int fit_conf_find_compat(const void *fit, const void *fdt);
 int fit_conf_get_node(const void *fit, const char *conf_uname);
 int fit_conf_get_kernel_node(const void *fit, int noffset);
 int fit_conf_get_ramdisk_node(const void *fit, int noffset);
-- 
1.7.7.3

[U-Boot] [PATCH 13/14] fdt: Add option to default to most compatible conf in a fit image

[Simon Glass]

From: Gabe Black <gabeblack@chromium.org>

When booting a fit image with multiple configurations, the user either has to
specify which configuration to use explicitly, or there has to be a default
defined which is chosen automatically. This change adds an option to change
that behavior so that a configuration can be selected explicitly, or the
configuration which has the device tree that claims to be compatible with the
earliest item in U-Boot's device tree.

In other words, if U-Boot claimed to be compatible with A, B, and then C, and
the configurations claimed to be compatible with A, D and B, D and D, E, the
first configuration, A, D, would be chosen. Both the first and second
configurations match, but the first one matches a more specific entry in
U-Boot's device tree. The order in the kernel's device tree is ignored.

Signed-off-by: Gabe Black <gabeblack@google.com>

Commit-Ready: Gabe Black <gabeblack@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---
 README             |   11 +++++
 common/cmd_bootm.c |   11 +++++
 common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 include/image.h    |    1 +
 4 files changed, 150 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 69da2b8..3912150 100644
--- a/README
+++ b/README
@@ -2582,6 +2582,17 @@ FIT uImage format:
  -150	common/cmd_nand.c	Incorrect FIT image format
   151	common/cmd_nand.c	FIT image format OK
 
+- FIT image support:
+		CONFIG_FIT
+		Enable support for the FIT uImage format.
+
+		CONFIG_FIT_BEST_MATCH
+		When no configuration is explicitly selected, default to the
+		one whose fdt's compatibility field best matches that of
+		U-Boot itself. A match is considered "best" if it matches the
+		most specific compatibility entry of U-Boot's fdt's root node.
+		The order of entries in the configuration's fdt is ignored.
+
 - Standalone program support:
 		CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c
index 83fa5d7..4e6042c 100644
--- a/common/cmd_bootm.c
+++ b/common/cmd_bootm.c
@@ -949,8 +949,19 @@ static void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
 			 * node
 			 */
 			bootstage_mark(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
+#ifdef CONFIG_FIT_BEST_MATCH
+			if (fit_uname_config)
+				cfg_noffset =
+					fit_conf_get_node(fit_hdr,
+							  fit_uname_config);
+			else
+				cfg_noffset =
+					fit_conf_find_compat(fit_hdr,
+							     gd->fdt_blob);
+#else
 			cfg_noffset = fit_conf_get_node(fit_hdr,
 							fit_uname_config);
+#endif
 			if (cfg_noffset < 0) {
 				bootstage_error(BOOTSTAGE_ID_FIT_NO_UNIT_NAME);
 				return NULL;
diff --git a/common/image.c b/common/image.c
index 750a98b..8877395 100644
--- a/common/image.c
+++ b/common/image.c
@@ -3049,6 +3049,133 @@ int fit_check_format(const void *fit)
 	return 1;
 }
 
+
+/**
+ * fit_conf_find_compat
+ * @fit: pointer to the FIT format image header
+ * @fdt: pointer to the device tree to compare against
+ *
+ * fit_conf_find_compat() attempts to find the configuration whose fdt is the
+ * most compatible with the passed in device tree.
+ *
+ * Example:
+ *
+ * / o image-tree
+ *   |-o images
+ *   | |-o fdt at 1
+ *   | |-o fdt at 2
+ *   |
+ *   |-o configurations
+ *     |-o config at 1
+ *     | |-fdt = fdt at 1
+ *     |
+ *     |-o config at 2
+ *       |-fdt = fdt@2
+ *
+ * / o U-Boot fdt
+ *   |-compatible = "foo,bar", "bim,bam"
+ *
+ * / o kernel fdt1
+ *   |-compatible = "foo,bar",
+ *
+ * / o kernel fdt2
+ *   |-compatible = "bim,bam", "baz,biz"
+ *
+ * Configuration 1 would be picked because the first string in U-Boot's
+ * compatible list, "foo,bar", matches a compatible string in the root of fdt1.
+ * "bim,bam" in fdt2 matches the second string which isn't as good as fdt1.
+ *
+ * returns:
+ *     offset to the configuration to use if one was found
+ *     -1 otherwise
+ */
+int fit_conf_find_compat(const void *fit, const void *fdt)
+{
+	int ndepth = 0;
+	int noffset, confs_noffset, images_noffset;
+	const void *fdt_compat;
+	int fdt_compat_len;
+	int best_match_offset = 0;
+	int best_match_pos = 0;
+
+	confs_noffset = fdt_path_offset(fit, FIT_CONFS_PATH);
+	images_noffset = fdt_path_offset(fit, FIT_IMAGES_PATH);
+	if (confs_noffset < 0 || images_noffset < 0) {
+		debug("Can't find configurations or images nodes.\n");
+		return -1;
+	}
+
+	fdt_compat = fdt_getprop(fdt, 0, "compatible", &fdt_compat_len);
+	if (!fdt_compat) {
+		debug("Fdt for comparison has no \"compatible\" property.\n");
+		return -1;
+	}
+
+	/*
+	 * Loop over the configurations in the FIT image.
+	 */
+	for (noffset = fdt_next_node(fit, confs_noffset, &ndepth);
+			(noffset >= 0) && (ndepth > 0);
+			noffset = fdt_next_node(fit, noffset, &ndepth)) {
+		const void *kfdt;
+		const char *kfdt_name;
+		int kfdt_noffset;
+		const char *cur_fdt_compat;
+		int len;
+		size_t size;
+		int i;
+
+		if (ndepth > 1)
+			continue;
+
+		kfdt_name = fdt_getprop(fit, noffset, "fdt", &len);
+		if (!kfdt_name) {
+			debug("No fdt property found.\n");
+			continue;
+		}
+		kfdt_noffset = fdt_subnode_offset(fit, images_noffset,
+						  kfdt_name);
+		if (kfdt_noffset < 0) {
+			debug("No image node named \"%s\" found.\n",
+			      kfdt_name);
+			continue;
+		}
+		/*
+		 * Get a pointer to this configuration's fdt.
+		 */
+		if (fit_image_get_data(fit, kfdt_noffset, &kfdt, &size)) {
+			debug("Failed to get fdt \"%s\".\n", kfdt_name);
+			continue;
+		}
+
+		len = fdt_compat_len;
+		cur_fdt_compat = fdt_compat;
+		/*
+		 * Look for a match for each U-Boot compatibility string in
+		 * turn in this configuration's fdt.
+		 */
+		for (i = 0; len > 0 &&
+		     (!best_match_offset || best_match_pos > i); i++) {
+			int cur_len = strlen(cur_fdt_compat) + 1;
+
+			if (!fdt_node_check_compatible(kfdt, 0,
+						       cur_fdt_compat)) {
+				best_match_offset = noffset;
+				best_match_pos = i;
+				break;
+			}
+			len -= cur_len;
+			cur_fdt_compat += cur_len;
+		}
+	}
+	if (!best_match_offset) {
+		debug("No match found.\n");
+		return -1;
+	}
+
+	return best_match_offset;
+}
+
 /**
  * fit_conf_get_node - get node offset for configuration of a given unit name
  * @fit: pointer to the FIT format image header
diff --git a/include/image.h b/include/image.h
index 4e5863f..d786559 100644
--- a/include/image.h
+++ b/include/image.h
@@ -614,6 +614,7 @@ int fit_image_check_type(const void *fit, int noffset, uint8_t type);
 int fit_image_check_comp(const void *fit, int noffset, uint8_t comp);
 int fit_check_format(const void *fit);
 
+int fit_conf_find_compat(const void *fit, const void *fdt);
 int fit_conf_get_node(const void *fit, const char *conf_uname);
 int fit_conf_get_kernel_node(const void *fit, int noffset);
 int fit_conf_get_ramdisk_node(const void *fit, int noffset);
-- 
1.7.7.3

[PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Simon Glass]

If kernel-offset is specified in the fdt, set an environment variable
so that scripts can access the attached kernel.

This can be used by a packaging program to tell U-Boot about a kernel
that has been downloaded alongside U-Boot. The value in the fdt is
the offset of the kernel from the start of the U-Boot image, so we can
find it just by adding CONFIG_SYS_TEXT_BASE.

It is then fairly easy to put something like this in the environment
variables in the board header file:

		"if test ${kernaddr} != \"\"; then "\
			"echo \"Using bundled kernel\"; "\
			"bootm ${kernaddr};" \
		"fi; "\
		/* rest of boot sequence follows here */

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 03c63b4..3137b75 100644
--- a/common/main.c
+++ b/common/main.c
@@ -333,6 +333,20 @@ err:
 	hang();
 }
 
+static void process_fdt_options(const void *blob)
+{
+	ulong addr;
+
+	/* Add an env variable to point to a kernel payload, if available */
+	addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
+	if (addr)
+		setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+
+	/* Add an env variable to point to a root disk, if available */
+	addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
+	if (addr)
+		setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+}
 #endif /* CONFIG_OF_CONTROL */
 
 
@@ -451,6 +465,8 @@ void main_loop (void)
 	if (env)
 		s = env;
 
+	process_fdt_options(gd->fdt_blob);
+
 	/*
 	 * If the bootsecure option was chosen, use secure_boot_cmd().
 	 * Always use 'env' in this case, since bootsecure requres that the
-- 
1.7.7.3

[U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Simon Glass]

If kernel-offset is specified in the fdt, set an environment variable
so that scripts can access the attached kernel.

This can be used by a packaging program to tell U-Boot about a kernel
that has been downloaded alongside U-Boot. The value in the fdt is
the offset of the kernel from the start of the U-Boot image, so we can
find it just by adding CONFIG_SYS_TEXT_BASE.

It is then fairly easy to put something like this in the environment
variables in the board header file:

		"if test ${kernaddr} != \"\"; then "\
			"echo \"Using bundled kernel\"; "\
			"bootm ${kernaddr};" \
		"fi; "\
		/* rest of boot sequence follows here */

Signed-off-by: Simon Glass <sjg@chromium.org>
---
 common/main.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/common/main.c b/common/main.c
index 03c63b4..3137b75 100644
--- a/common/main.c
+++ b/common/main.c
@@ -333,6 +333,20 @@ err:
 	hang();
 }
 
+static void process_fdt_options(const void *blob)
+{
+	ulong addr;
+
+	/* Add an env variable to point to a kernel payload, if available */
+	addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
+	if (addr)
+		setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+
+	/* Add an env variable to point to a root disk, if available */
+	addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
+	if (addr)
+		setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE + addr));
+}
 #endif /* CONFIG_OF_CONTROL */
 
 
@@ -451,6 +465,8 @@ void main_loop (void)
 	if (env)
 		s = env;
 
+	process_fdt_options(gd->fdt_blob);
+
 	/*
 	 * If the bootsecure option was chosen, use secure_boot_cmd().
 	 * Always use 'env' in this case, since bootsecure requres that the
-- 
1.7.7.3

Re: [U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Dennis Lan (dlan)]

[-- Attachment #1.1: Type: text/plain, Size: 3077 bytes --]

hi simon:
  found a small bug?(not sure) which introduced by this commit.

this line not inldue FDT option
#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) ||
defined(CONFIG_CMDLINE_EDITING)
DECLARE_GLOBAL_DATA_PTR;
#endif


main.c: In function 'process_fdt_options':
main.c:341:31: error: 'gd' undeclared (first use in this function)
main.c:341:31: note: each undeclared identifier is reported only once for
each function it appears in
main.c: In function 'main_loop':
main.c:464:33: error: 'gd' undeclared (first use in this function)
make[2]: *** [main.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [common/libcommon.o] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [lt703a] Error 2



On Fri, Oct 26, 2012 at 10:31 AM, Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:

> If kernel-offset is specified in the fdt, set an environment variable
> so that scripts can access the attached kernel.
>
> This can be used by a packaging program to tell U-Boot about a kernel
> that has been downloaded alongside U-Boot. The value in the fdt is
> the offset of the kernel from the start of the U-Boot image, so we can
> find it just by adding CONFIG_SYS_TEXT_BASE.
>
> It is then fairly easy to put something like this in the environment
> variables in the board header file:
>
>                 "if test ${kernaddr} != \"\"; then "\
>                         "echo \"Using bundled kernel\"; "\
>                         "bootm ${kernaddr};" \
>                 "fi; "\
>                 /* rest of boot sequence follows here */
>
> Signed-off-by: Simon Glass <sjg-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>  common/main.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/common/main.c b/common/main.c
> index 03c63b4..3137b75 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -333,6 +333,20 @@ err:
>         hang();
>  }
>
> +static void process_fdt_options(const void *blob)
> +{
> +       ulong addr;
> +
> +       /* Add an env variable to point to a kernel payload, if available
> */
> +       addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
> +       if (addr)
> +               setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE +
> addr));
> +
> +       /* Add an env variable to point to a root disk, if available */
> +       addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
> +       if (addr)
> +               setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE +
> addr));
> +}
>  #endif /* CONFIG_OF_CONTROL */
>
>
> @@ -451,6 +465,8 @@ void main_loop (void)
>         if (env)
>                 s = env;
>
> +       process_fdt_options(gd->fdt_blob);
> +
>         /*
>          * If the bootsecure option was chosen, use secure_boot_cmd().
>          * Always use 'env' in this case, since bootsecure requres that the
> --
> 1.7.7.3
>
> _______________________________________________
> U-Boot mailing list
> U-Boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org
> http://lists.denx.de/mailman/listinfo/u-boot
>

[-- Attachment #1.2: Type: text/html, Size: 4152 bytes --]

[-- Attachment #2: Type: text/plain, Size: 192 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
https://lists.ozlabs.org/listinfo/devicetree-discuss

[U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Dennis Lan]

hi simon:
  found a small bug?(not sure) which introduced by this commit.

this line not inldue FDT option
#if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) ||
defined(CONFIG_CMDLINE_EDITING)
DECLARE_GLOBAL_DATA_PTR;
#endif


main.c: In function 'process_fdt_options':
main.c:341:31: error: 'gd' undeclared (first use in this function)
main.c:341:31: note: each undeclared identifier is reported only once for
each function it appears in
main.c: In function 'main_loop':
main.c:464:33: error: 'gd' undeclared (first use in this function)
make[2]: *** [main.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [common/libcommon.o] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [lt703a] Error 2



On Fri, Oct 26, 2012 at 10:31 AM, Simon Glass <sjg@chromium.org> wrote:

> If kernel-offset is specified in the fdt, set an environment variable
> so that scripts can access the attached kernel.
>
> This can be used by a packaging program to tell U-Boot about a kernel
> that has been downloaded alongside U-Boot. The value in the fdt is
> the offset of the kernel from the start of the U-Boot image, so we can
> find it just by adding CONFIG_SYS_TEXT_BASE.
>
> It is then fairly easy to put something like this in the environment
> variables in the board header file:
>
>                 "if test ${kernaddr} != \"\"; then "\
>                         "echo \"Using bundled kernel\"; "\
>                         "bootm ${kernaddr};" \
>                 "fi; "\
>                 /* rest of boot sequence follows here */
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>  common/main.c |   16 ++++++++++++++++
>  1 files changed, 16 insertions(+), 0 deletions(-)
>
> diff --git a/common/main.c b/common/main.c
> index 03c63b4..3137b75 100644
> --- a/common/main.c
> +++ b/common/main.c
> @@ -333,6 +333,20 @@ err:
>         hang();
>  }
>
> +static void process_fdt_options(const void *blob)
> +{
> +       ulong addr;
> +
> +       /* Add an env variable to point to a kernel payload, if available
> */
> +       addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
> +       if (addr)
> +               setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE +
> addr));
> +
> +       /* Add an env variable to point to a root disk, if available */
> +       addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
> +       if (addr)
> +               setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE +
> addr));
> +}
>  #endif /* CONFIG_OF_CONTROL */
>
>
> @@ -451,6 +465,8 @@ void main_loop (void)
>         if (env)
>                 s = env;
>
> +       process_fdt_options(gd->fdt_blob);
> +
>         /*
>          * If the bootsecure option was chosen, use secure_boot_cmd().
>          * Always use 'env' in this case, since bootsecure requres that the
> --
> 1.7.7.3
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [PATCH 14/14] fdt: Set kernaddr if fdt indicates a kernel is present

[Simon Glass]

Hi Dennis,

On Wed, Nov 28, 2012 at 6:30 AM, Dennis Lan (dlan)
<dennis.yxun@gmail.com> wrote:
> hi simon:
>   found a small bug?(not sure) which introduced by this commit.
>
> this line not inldue FDT option
> #if defined(CONFIG_SILENT_CONSOLE) || defined(CONFIG_POST) ||
> defined(CONFIG_CMDLINE_EDITING)
> DECLARE_GLOBAL_DATA_PTR;
> #endif

Thanks for reporting it -I will send a patch. Were you building for a
particular board, or did you just notice it?

>
>
> main.c: In function 'process_fdt_options':
> main.c:341:31: error: 'gd' undeclared (first use in this function)
> main.c:341:31: note: each undeclared identifier is reported only once for
> each function it appears in
> main.c: In function 'main_loop':
> main.c:464:33: error: 'gd' undeclared (first use in this function)
> make[2]: *** [main.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [common/libcommon.o] Error 2
> make[1]: *** Waiting for unfinished jobs....
> make: *** [lt703a] Error 2
>
Regards,
Simon

>
>
> On Fri, Oct 26, 2012 at 10:31 AM, Simon Glass <sjg@chromium.org> wrote:
>>
>> If kernel-offset is specified in the fdt, set an environment variable
>> so that scripts can access the attached kernel.
>>
>> This can be used by a packaging program to tell U-Boot about a kernel
>> that has been downloaded alongside U-Boot. The value in the fdt is
>> the offset of the kernel from the start of the U-Boot image, so we can
>> find it just by adding CONFIG_SYS_TEXT_BASE.
>>
>> It is then fairly easy to put something like this in the environment
>> variables in the board header file:
>>
>>                 "if test ${kernaddr} != \"\"; then "\
>>                         "echo \"Using bundled kernel\"; "\
>>                         "bootm ${kernaddr};" \
>>                 "fi; "\
>>                 /* rest of boot sequence follows here */
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>  common/main.c |   16 ++++++++++++++++
>>  1 files changed, 16 insertions(+), 0 deletions(-)
>>
>> diff --git a/common/main.c b/common/main.c
>> index 03c63b4..3137b75 100644
>> --- a/common/main.c
>> +++ b/common/main.c
>> @@ -333,6 +333,20 @@ err:
>>         hang();
>>  }
>>
>> +static void process_fdt_options(const void *blob)
>> +{
>> +       ulong addr;
>> +
>> +       /* Add an env variable to point to a kernel payload, if available
>> */
>> +       addr = fdtdec_get_config_int(gd->fdt_blob, "kernel-offset", 0);
>> +       if (addr)
>> +               setenv_addr("kernaddr", (void *)(CONFIG_SYS_TEXT_BASE +
>> addr));
>> +
>> +       /* Add an env variable to point to a root disk, if available */
>> +       addr = fdtdec_get_config_int(gd->fdt_blob, "rootdisk-offset", 0);
>> +       if (addr)
>> +               setenv_addr("rootaddr", (void *)(CONFIG_SYS_TEXT_BASE +
>> addr));
>> +}
>>  #endif /* CONFIG_OF_CONTROL */
>>
>>
>> @@ -451,6 +465,8 @@ void main_loop (void)
>>         if (env)
>>                 s = env;
>>
>> +       process_fdt_options(gd->fdt_blob);
>> +
>>         /*
>>          * If the bootsecure option was chosen, use secure_boot_cmd().
>>          * Always use 'env' in this case, since bootsecure requres that
>> the
>> --
>> 1.7.7.3
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>
>

Re: [PATCH 0/14] fdt: Add various device tree utilities and features

[Jerry Van Baren]

Dear Simon,

Sorry for being so late on this (the patches were submitted before the
merge window closed).  I've applied the patches to the "next" branch in
the u-boot-fdt repo.
  <http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next>

I'm assuming these are still valid (Simon) and eligible to be applied to
the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

On 10/25/2012 10:30 PM, Simon Glass wrote:
> This series contains a number of features related to CONFIG_OF_CONTROL,
> such as:
> 
> - reading fdt values
> - reading configuration from the fdt
> - allowing the fdt to specify a boot command

[snip]

>  README             |   11 +++++
>  common/cmd_bootm.c |   11 +++++
>  common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
>  include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/image.h    |    1 +
>  lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
>  7 files changed, 472 insertions(+), 8 deletions(-)

Again, my apologies,
gvb

[U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features

[Jerry Van Baren]

Dear Simon,

Sorry for being so late on this (the patches were submitted before the
merge window closed).  I've applied the patches to the "next" branch in
the u-boot-fdt repo.
  <http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next>

I'm assuming these are still valid (Simon) and eligible to be applied to
the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

On 10/25/2012 10:30 PM, Simon Glass wrote:
> This series contains a number of features related to CONFIG_OF_CONTROL,
> such as:
> 
> - reading fdt values
> - reading configuration from the fdt
> - allowing the fdt to specify a boot command

[snip]

>  README             |   11 +++++
>  common/cmd_bootm.c |   11 +++++
>  common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
>  include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
>  include/image.h    |    1 +
>  lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
>  7 files changed, 472 insertions(+), 8 deletions(-)

Again, my apologies,
gvb

Re: [PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

Hi Jerry,

On Sat, Nov 17, 2012 at 5:35 PM, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> Dear Simon,
>
> Sorry for being so late on this (the patches were submitted before the
> merge window closed).  I've applied the patches to the "next" branch in
> the u-boot-fdt repo.
>   <http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next>
>
> I'm assuming these are still valid (Simon) and eligible to be applied to
> the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

Yes still valid thank you. The only question is around the GPIO patch
(http://patchwork.ozlabs.org/patch/194340/) since as Stephen pointed
out there is discussion on the kernel list of whether to keep the
polarity bit. I suppose we can always address that later if they
decide to replace it with something else.

>
> On 10/25/2012 10:30 PM, Simon Glass wrote:
>> This series contains a number of features related to CONFIG_OF_CONTROL,
>> such as:
>>
>> - reading fdt values
>> - reading configuration from the fdt
>> - allowing the fdt to specify a boot command
>
> [snip]
>
>>  README             |   11 +++++
>>  common/cmd_bootm.c |   11 +++++
>>  common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
>>  include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/image.h    |    1 +
>>  lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
>>  7 files changed, 472 insertions(+), 8 deletions(-)
>
> Again, my apologies,

No problem, we all have plenty to do!

> gvb
>

Regards,
Simon

[U-Boot] [PATCH 0/14] fdt: Add various device tree utilities and features

[Simon Glass]

Hi Jerry,

On Sat, Nov 17, 2012 at 5:35 PM, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> Dear Simon,
>
> Sorry for being so late on this (the patches were submitted before the
> merge window closed).  I've applied the patches to the "next" branch in
> the u-boot-fdt repo.
>   <http://git.denx.de/?p=u-boot/u-boot-fdt.git;a=shortlog;h=refs/heads/next>
>
> I'm assuming these are still valid (Simon) and eligible to be applied to
> the v2013.01 u-boot release (Tom).  If so, I'll submit a pull request.

Yes still valid thank you. The only question is around the GPIO patch
(http://patchwork.ozlabs.org/patch/194340/) since as Stephen pointed
out there is discussion on the kernel list of whether to keep the
polarity bit. I suppose we can always address that later if they
decide to replace it with something else.

>
> On 10/25/2012 10:30 PM, Simon Glass wrote:
>> This series contains a number of features related to CONFIG_OF_CONTROL,
>> such as:
>>
>> - reading fdt values
>> - reading configuration from the fdt
>> - allowing the fdt to specify a boot command
>
> [snip]
>
>>  README             |   11 +++++
>>  common/cmd_bootm.c |   11 +++++
>>  common/image.c     |  127 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>>  common/main.c      |  102 +++++++++++++++++++++++++++++++++++++++++-
>>  include/fdtdec.h   |  121 +++++++++++++++++++++++++++++++++++++++++++++++++
>>  include/image.h    |    1 +
>>  lib/fdtdec.c       |  107 +++++++++++++++++++++++++++++++++++++++++---
>>  7 files changed, 472 insertions(+), 8 deletions(-)
>
> Again, my apologies,

No problem, we all have plenty to do!

> gvb
>

Regards,
Simon