[U-Boot] [PATCH 3/8] dm: core: remove unnecessary return condition in driver lookup

[Masahiro Yamada]

The variable drv never becomes NULL because ll_entry_start()
always returns a valid pointer even if there are no entries.

The case n_ents == 0 is covered by the following for loop.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/core/lists.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 0aad56d..0c58ec4 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -25,9 +25,6 @@ struct driver *lists_driver_lookup_name(const char *name)
const int n_ents = ll_entry_count(struct driver, driver);
struct driver *entry;
 
-   if (!drv || !n_ents)
-   return NULL;
-
for (entry = drv; entry != drv + n_ents; entry++) {
if (!strcmp(name, entry-name))
return entry;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 6/8] dm: core: look up drivers more efficiently

[Masahiro Yamada]

The DM initialization function, dm_init_and_scan() is called twice,
before and after relocation.

In the first DM scan, only some of drivers are bound for the use in
pre-reloc code (mostly UART drivers).  In the second scan, all the
drivers are bound.

In the current implementation, all the drivers are collected into a
single array.  Every driver is searched through the array and then
the DM_FLAG_PRE_RELOC flag is checked.  In the pre-reloc DM scan,
drivers without DM_FLAG_PRE_RELOC are ignored.  This algorithm works
enough, but is not very efficient.

This commit aims to split drivers into two contiguous arrays,
pre-reloc drivers and post-reloc drivers.  The drivers in the former
group are declared with U_BOOT_DRIVER_F.  The others are declared with
U_BOOT_DRIVER.

pre  post
_  reloc reloc
  .u_boot_list_2_driver1_1  |   |||   ||
|   |||   ||
|   |||   ||
|  U_BOOT_DRIVER_F  |||   ||
| (driver1) |||   ||
|   |   _||_  ||
|   |   \  /  ||
  .u_boot_list_2_driver1_3  |___|\/   ||
  .u_boot_list_2_driver2_1  |   | ||
|   | ||
|   | ||
|   U_BOOT_DRIVER   | ||
| (driver2) | ||
|   |_||_
|   |\  /
  .u_boot_list_2_driver2_3  |___| \/

The pre-reloc DM scan searches drivers from .u_boot_list_2_driver1_1
to .u_boot_list_2_driver1_3.  The post-reloc scan searches ones from
.u_boot_list_2_driver1_1 and .u_boot_list_2_driver2_3.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 doc/driver-model/README.txt |  2 +-
 drivers/core/device.c   |  4 +---
 drivers/core/lists.c| 22 +-
 drivers/core/root.c |  3 ++-
 include/dm/device.h |  8 ++--
 include/dm/lists.h  | 16 
 include/dm/root.h   | 16 
 7 files changed, 43 insertions(+), 28 deletions(-)

diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 0278dda..e4114d5 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -739,7 +739,7 @@ Pre-Relocation Support
 --
 
 For pre-relocation we simply call the driver model init function. Only
-drivers marked with DM_FLAG_PRE_RELOC or the device tree
+drivers declared with U_BOOT_DRIVER_F or the device tree
 'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps
 to reduce the driver model overhead.
 
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 49faa29..6fd2f07 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -157,11 +157,9 @@ int device_bind_by_name(struct udevice *parent, bool 
pre_reloc_only,
 {
struct driver *drv;
 
-   drv = lists_driver_lookup_name(info-name);
+   drv = __lists_driver_lookup_name(info-name, pre_reloc_only);
if (!drv)
return -ENOENT;
-   if (pre_reloc_only  !(drv-flags  DM_FLAG_PRE_RELOC))
-   return -EPERM;
 
return device_bind(parent, drv, info-name, (void *)info-platdata,
   -1, devp);
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 1476715..5b61ab5 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -18,10 +18,13 @@
 #include fdtdec.h
 #include linux/compiler.h
 
-struct driver *lists_driver_lookup_name(const char *name)
+#define driver_entry_end(p) (p) ? ll_entry_end(struct driver, driver1) : \
+ ll_entry_end(struct driver, driver2);
+
+struct driver *__lists_driver_lookup_name(const char *name, bool 
pre_reloc_only)
 {
-   struct driver *entry = ll_entry_start(struct driver, driver);
-   struct driver *end = ll_entry_end(struct driver, driver);
+   struct driver *entry = ll_entry_start(struct driver, driver1);
+   struct driver *end = driver_entry_end(pre_reloc_only);
 
for (; entry  end; entry++) {
if (!strcmp(name, entry-name))
@@ -58,11 +61,12 @@ int lists_bind_drivers(struct udevice *parent, bool 
pre_reloc_only)
 
for (; entry  end; entry++) {
ret = device_bind_by_name(parent, pre_reloc_only, entry, dev);
-   if (ret  ret != -EPERM) {
+
+   if (!pre_reloc_only  ret == -ENOENT)
dm_warn(No match for driver '%s'\n, 

[U-Boot] [PATCH 0/8] dm: core: abolish u-boot, dm-pre-reloc property and various refactorings

[Masahiro Yamada]

I am implemting Device Tree support for Panasonic UniPhier platform,
but while I was working on that, I noticed some problems in DM core
implementation.

What I want to solve the most here is the inconsistency in terms of
how to pass the pre-reloc attribute.

The driver model provides two ways to pass the device information,
platform data and device tree.

In the platform data way, the pre-reloc DM scan checks if each driver
has DM_FLAG_PRE_RELOC flag, that is, each **driver** has the pre-reloc
attribute.

In the device tree control, the existence of u-boot,dm-pre-reloc is
checked for each device node.  The driver flag DM_FLAG_PRE_RELOC is
never checked.  That is, each **device** owns the pre-reloc attribute.

Drivers should generally work both with platform data and device tree,
but this inconsitency has made our life difficult.

This series aims to abolish u-boot,dm-pre-reloc property because:

 - Having a U-Boot specific property makes it difficult to share the
   device tree sources between Linux and U-Boot.

 - The number of devices is generally larger than that of drivers.
   Each driver often has multiple devices with different base
   addresses.  It seems more reasonable to add the pre-reloc attribute
   to drivers than devices.

8/8 commit abolishes u-boot,dm-pre-reloc property and replaces it
with some *driver* attribute.
When I am working on that, I came up with another idea.
I thought it is unefficient to scan all the drivers and then check
the DM_FLAG_PRE_RELOC.  Becuase the DM_FLAG_PRE_RELOC is a static
data, we know if each driver is a pre-reloc one or not.  So, 6/8
introduces more efficient driver scanning.

1/8 thru 5/8 are some cleanups before I do new things.


Masahiro Yamada (8):
  dm: core: a trivial clean up
  dm: core: remove meaningless if conditional
  dm: core: remove unnecessary return condition in driver lookup
  dm: core: remove unnecessary return condition in uclass lookup
  dm: core: refactor linker lists lookup code
  dm: core: look up drivers more efficiently
  dm: core: declare pre-reloc drivers with U_BOOT_DRIVER_F
  dm: core: abolish u-boot,dm-pre-reloc property

 arch/arm/dts/exynos5.dtsi|  1 -
 doc/driver-model/README.txt  |  5 ++--
 drivers/core/device.c|  4 +--
 drivers/core/lists.c | 57 ++--
 drivers/core/root.c  | 13 -
 drivers/core/simple-bus.c|  2 +-
 drivers/serial/sandbox.c |  3 +--
 drivers/serial/serial_mxc.c  |  3 +--
 drivers/serial/serial_omap.c |  3 +--
 drivers/serial/serial_pl01x.c|  3 +--
 drivers/serial/serial_s5p.c  |  3 +--
 drivers/serial/serial_uniphier.c |  3 +--
 include/dm/device.h  | 11 
 include/dm/lists.h   | 29 +++-
 include/dm/root.h| 20 +++---
 test/dm/test-driver.c|  3 +--
 test/dm/test-fdt.c   |  2 +-
 test/dm/test.dts |  2 --
 18 files changed, 80 insertions(+), 87 deletions(-)

-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/8] dm: core: refactor linker lists lookup code

[Masahiro Yamada]

It looks simpler to use ll_entry_end() than ll_entry_count().
We can save one variable.  (and it will be helpful for the upcoming
commit.)

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/core/lists.c | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index ddbac38..1476715 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -20,12 +20,10 @@
 
 struct driver *lists_driver_lookup_name(const char *name)
 {
-   struct driver *drv =
-   ll_entry_start(struct driver, driver);
-   const int n_ents = ll_entry_count(struct driver, driver);
-   struct driver *entry;
+   struct driver *entry = ll_entry_start(struct driver, driver);
+   struct driver *end = ll_entry_end(struct driver, driver);
 
-   for (entry = drv; entry != drv + n_ents; entry++) {
+   for (; entry  end; entry++) {
if (!strcmp(name, entry-name))
return entry;
}
@@ -36,12 +34,11 @@ struct driver *lists_driver_lookup_name(const char *name)
 
 struct uclass_driver *lists_uclass_lookup(enum uclass_id id)
 {
-   struct uclass_driver *uclass =
+   struct uclass_driver *entry =
ll_entry_start(struct uclass_driver, uclass);
-   const int n_ents = ll_entry_count(struct uclass_driver, uclass);
-   struct uclass_driver *entry;
+   struct uclass_driver *end = ll_entry_end(struct uclass_driver, uclass);
 
-   for (entry = uclass; entry != uclass + n_ents; entry++) {
+   for (; entry  end; entry++) {
if (entry-id == id)
return entry;
}
@@ -51,15 +48,15 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id)
 
 int lists_bind_drivers(struct udevice *parent, bool pre_reloc_only)
 {
-   struct driver_info *info =
+   struct driver_info *entry =
ll_entry_start(struct driver_info, driver_info);
-   const int n_ents = ll_entry_count(struct driver_info, driver_info);
-   struct driver_info *entry;
+   struct driver_info *end =
+   ll_entry_end(struct driver_info, driver_info);
struct udevice *dev;
int result = 0;
int ret;
 
-   for (entry = info; entry != info + n_ents; entry++) {
+   for (; entry  end; entry++) {
ret = device_bind_by_name(parent, pre_reloc_only, entry, dev);
if (ret  ret != -EPERM) {
dm_warn(No match for driver '%s'\n, entry-name);
@@ -108,9 +105,8 @@ static int driver_check_compatible(const void *blob, int 
offset,
 int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
   struct udevice **devp)
 {
-   struct driver *driver = ll_entry_start(struct driver, driver);
-   const int n_ents = ll_entry_count(struct driver, driver);
-   struct driver *entry;
+   struct driver *entry = ll_entry_start(struct driver, driver);
+   struct driver *end = ll_entry_end(struct driver, driver);
struct udevice *dev;
bool found = false;
const char *name;
@@ -120,7 +116,7 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
dm_dbg(bind node %s\n, fdt_get_name(blob, offset, NULL));
if (devp)
*devp = NULL;
-   for (entry = driver; entry != driver + n_ents; entry++) {
+   for (; entry  end; entry++) {
ret = driver_check_compatible(blob, offset, entry-of_match);
name = fdt_get_name(blob, offset, NULL);
if (ret == -ENOENT) {
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/8] dm: core: a trivial clean up

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/core/root.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/core/root.c b/drivers/core/root.c
index a328a48..47b3acf 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -73,10 +73,8 @@ int dm_scan_platdata(bool pre_reloc_only)
dm_warn(Some drivers were not found\n);
ret = 0;
}
-   if (ret)
-   return ret;
 
-   return 0;
+   return ret;
 }
 
 #ifdef CONFIG_OF_CONTROL
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property

[Masahiro Yamada]

The driver model provides two ways to pass the device information,
platform data and device tree.  Either way works to bind devices and
drivers, but there is inconsistency in terms of how to pass the
pre-reloc flag.

In the platform data way, the pre-reloc DM scan checks if each driver
has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F
just before).  That is, each **driver** has the pre-reloc attribute.

In the device tree control, the existence of u-boot,dm-pre-reloc is
checked for each device node.  The driver flag DM_FLAG_PRE_RELOC is
never checked.  That is, each **device** owns the pre-reloc attribute.

Drivers should generally work both with platform data and device tree,
but this inconsistency has made our life difficult.

This commit abolishes u-boot,dm-pre-reloc property because:

 - Having a U-Boot specific property makes it difficult to share the
   device tree sources between Linux and U-Boot.

 - The number of devices is generally larger than that of drivers.
   Each driver often has multiple devices with different base
   addresses.  It seems more reasonable to add the pre-reloc attribute
   to drivers than devices.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 arch/arm/dts/exynos5.dtsi   |  1 -
 doc/driver-model/README.txt |  5 ++---
 drivers/core/lists.c|  6 +++---
 drivers/core/root.c |  6 ++
 drivers/core/simple-bus.c   |  2 +-
 include/dm/lists.h  | 13 ++---
 include/dm/root.h   |  4 ++--
 test/dm/test-fdt.c  |  2 +-
 test/dm/test.dts|  2 --
 9 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi
index e539068..dc5405b 100644
--- a/arch/arm/dts/exynos5.dtsi
+++ b/arch/arm/dts/exynos5.dtsi
@@ -244,7 +244,6 @@
compatible = samsung,exynos4210-uart;
reg = 0x12C3 0x100;
interrupts = 0 54 0;
-   u-boot,dm-pre-reloc;
id = 3;
};
 
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index e4114d5..06f6515 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -739,9 +739,8 @@ Pre-Relocation Support
 --
 
 For pre-relocation we simply call the driver model init function. Only
-drivers declared with U_BOOT_DRIVER_F or the device tree
-'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps
-to reduce the driver model overhead.
+drivers declared with U_BOOT_DRIVER_F are initialised prior to relocation.
+This helps to reduce the driver model overhead.
 
 Then post relocation we throw that away and re-init driver model again.
 For drivers which require some sort of continuity between pre- and
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 5b61ab5..2109a9f 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -106,11 +106,11 @@ static int driver_check_compatible(const void *blob, int 
offset,
return -ENOENT;
 }
 
-int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
-  struct udevice **devp)
+int __lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
+struct udevice **devp, bool pre_reloc_only)
 {
struct driver *entry = ll_entry_start(struct driver, driver1);
-   struct driver *end = ll_entry_end(struct driver, driver2);
+   struct driver *end = driver_entry_end(pre_reloc_only);
struct udevice *dev;
bool found = false;
const char *name;
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 02970c8..2f0c409 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -87,10 +87,8 @@ int dm_scan_fdt_node(struct udevice *parent, const void 
*blob, int offset,
for (offset = fdt_first_subnode(blob, offset);
 offset  0;
 offset = fdt_next_subnode(blob, offset)) {
-   if (pre_reloc_only 
-   !fdt_getprop(blob, offset, u-boot,dm-pre-reloc, NULL))
-   continue;
-   err = lists_bind_fdt(parent, blob, offset, NULL);
+   err = __lists_bind_fdt(parent, blob, offset, NULL,
+  pre_reloc_only);
if (err  !ret)
ret = err;
}
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c
index 3ea4d82..483f8e2 100644
--- a/drivers/core/simple-bus.c
+++ b/drivers/core/simple-bus.c
@@ -26,7 +26,7 @@ static const struct udevice_id generic_simple_bus_ids[] = {
{ }
 };
 
-U_BOOT_DRIVER(simple_bus_drv) = {
+U_BOOT_DRIVER_F(simple_bus_drv) = {
.name   = generic_simple_bus,
.id = UCLASS_SIMPLE_BUS,
.of_match = generic_simple_bus_ids,
diff --git a/include/dm/lists.h b/include/dm/lists.h
index fbd428d..56bf6a7 100644
--- a/include/dm/lists.h
+++ b/include/dm/lists.h
@@ -53,7 +53,7 @@ struct uclass_driver *lists_uclass_lookup(enum 

[U-Boot] [PATCH 7/8] dm: core: declare pre-reloc drivers with U_BOOT_DRIVER_F

[Masahiro Yamada]

Replace U_BOOT_DRIVER with U_BOOT_DRIVER_F where the DM_FLAG_PRE_RELOC
flag is set.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/serial/sandbox.c | 3 +--
 drivers/serial/serial_mxc.c  | 3 +--
 drivers/serial/serial_omap.c | 3 +--
 drivers/serial/serial_pl01x.c| 3 +--
 drivers/serial/serial_s5p.c  | 3 +--
 drivers/serial/serial_uniphier.c | 3 +--
 include/dm/device.h  | 3 ---
 test/dm/test-driver.c| 3 +--
 8 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c
index cd2f91e..b7e9f4e 100644
--- a/drivers/serial/sandbox.c
+++ b/drivers/serial/sandbox.c
@@ -176,7 +176,7 @@ static const struct udevice_id sandbox_serial_ids[] = {
{ }
 };
 
-U_BOOT_DRIVER(serial_sandbox) = {
+U_BOOT_DRIVER_F(serial_sandbox) = {
.name   = serial_sandbox,
.id = UCLASS_SERIAL,
.of_match = sandbox_serial_ids,
@@ -186,7 +186,6 @@ U_BOOT_DRIVER(serial_sandbox) = {
.probe = sandbox_serial_probe,
.remove = sandbox_serial_remove,
.ops= sandbox_serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
 };
 
 static const struct sandbox_serial_platdata platdata_non_fdt = {
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index d6cf1d8..e93d3e2 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -334,11 +334,10 @@ static const struct dm_serial_ops mxc_serial_ops = {
.setbrg = mxc_serial_setbrg,
 };
 
-U_BOOT_DRIVER(serial_mxc) = {
+U_BOOT_DRIVER_F(serial_mxc) = {
.name   = serial_mxc,
.id = UCLASS_SERIAL,
.probe = mxc_serial_probe,
.ops= mxc_serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
 };
 #endif
diff --git a/drivers/serial/serial_omap.c b/drivers/serial/serial_omap.c
index 265fe00..0dffba3 100644
--- a/drivers/serial/serial_omap.c
+++ b/drivers/serial/serial_omap.c
@@ -34,7 +34,7 @@ static int omap_serial_ofdata_to_platdata(struct udevice *dev)
 }
 #endif
 
-U_BOOT_DRIVER(serial_omap_ns16550) = {
+U_BOOT_DRIVER_F(serial_omap_ns16550) = {
.name   = serial_omap,
.id = UCLASS_SERIAL,
.of_match = of_match_ptr(omap_serial_ids),
@@ -43,5 +43,4 @@ U_BOOT_DRIVER(serial_omap_ns16550) = {
.priv_auto_alloc_size = sizeof(struct NS16550),
.probe = ns16550_serial_probe,
.ops= ns16550_serial_ops,
-   .flags  = DM_FLAG_PRE_RELOC,
 };
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index 38dda91..53eab9a 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -338,12 +338,11 @@ static const struct dm_serial_ops pl01x_serial_ops = {
.setbrg = pl01x_serial_setbrg,
 };
 
-U_BOOT_DRIVER(serial_pl01x) = {
+U_BOOT_DRIVER_F(serial_pl01x) = {
.name   = serial_pl01x,
.id = UCLASS_SERIAL,
.probe = pl01x_serial_probe,
.ops= pl01x_serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
 };
 
 #endif
diff --git a/drivers/serial/serial_s5p.c b/drivers/serial/serial_s5p.c
index 8469afd..abab286 100644
--- a/drivers/serial/serial_s5p.c
+++ b/drivers/serial/serial_s5p.c
@@ -178,7 +178,7 @@ static const struct udevice_id s5p_serial_ids[] = {
{ }
 };
 
-U_BOOT_DRIVER(serial_s5p) = {
+U_BOOT_DRIVER_F(serial_s5p) = {
.name   = serial_s5p,
.id = UCLASS_SERIAL,
.of_match = s5p_serial_ids,
@@ -186,5 +186,4 @@ U_BOOT_DRIVER(serial_s5p) = {
.platdata_auto_alloc_size = sizeof(struct s5p_serial_platdata),
.probe = s5p_serial_probe,
.ops= s5p_serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
 };
diff --git a/drivers/serial/serial_uniphier.c b/drivers/serial/serial_uniphier.c
index 6046efb..6fe68c7 100644
--- a/drivers/serial/serial_uniphier.c
+++ b/drivers/serial/serial_uniphier.c
@@ -136,7 +136,7 @@ static const struct dm_serial_ops uniphier_serial_ops = {
.pending = uniphier_serial_pending,
 };
 
-U_BOOT_DRIVER(uniphier_serial) = {
+U_BOOT_DRIVER_F(uniphier_serial) = {
.name = DRIVER_NAME,
.id = UCLASS_SERIAL,
.of_match = of_match_ptr(uniphier_uart_of_match),
@@ -147,5 +147,4 @@ U_BOOT_DRIVER(uniphier_serial) = {
.platdata_auto_alloc_size =
sizeof(struct uniphier_serial_platform_data),
.ops = uniphier_serial_ops,
-   .flags = DM_FLAG_PRE_RELOC,
 };
diff --git a/include/dm/device.h b/include/dm/device.h
index a2fd7b6..ed14af9 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -23,9 +23,6 @@ struct driver_info;
 /* DM is responsible for allocating and freeing platdata */
 #define DM_FLAG_ALLOC_PDATA(1  1)
 
-/* DM should init this device prior to relocation */
-#define DM_FLAG_PRE_RELOC  (1  2)
-
 /**
  * struct udevice - An instance of a driver
  *
diff --git a/test/dm/test-driver.c b/test/dm/test-driver.c
index bc6a6e7..065bcbf 100644
--- a/test/dm/test-driver.c
+++ 

[U-Boot] [PATCH 2/8] dm: core: remove meaningless if conditional

[Masahiro Yamada]

If the variable ret is equal to -ENOENT, it is trapped at [1] and
never reaches [2].  At [3], the condition ret != -ENOENT is always
true.

  if (ret == -ENOENT) {   -- [1]
  continue;
  } else if (ret == -ENODEV) {
  dm_dbg(Device '%s' has no compatible string\n, name);
  break;
  } else if (ret) {   -- [2]
  dm_warn(Device tree error at offset %d\n, offset);
  if (!result || ret != -ENOENT)  -- [3]
  result = ret;
  break;
  }

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/core/lists.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 3a1ea85..0aad56d 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -136,8 +136,7 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
break;
} else if (ret) {
dm_warn(Device tree error at offset %d\n, offset);
-   if (!result || ret != -ENOENT)
-   result = ret;
+   result = ret;
break;
}
 
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 4/8] dm: core: remove unnecessary return condition in uclass lookup

[Masahiro Yamada]

These conditions never happen.
 - There is no real uclass with UCLASS_INVALID id.
 - uclass never becomes NULL because ll_entry_start() always returns
   a valid pointer.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/core/lists.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 0c58ec4..ddbac38 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -41,9 +41,6 @@ struct uclass_driver *lists_uclass_lookup(enum uclass_id id)
const int n_ents = ll_entry_count(struct uclass_driver, uclass);
struct uclass_driver *entry;
 
-   if ((id == UCLASS_INVALID) || !uclass)
-   return NULL;
-
for (entry = uclass; entry != uclass + n_ents; entry++) {
if (entry-id == id)
return entry;
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] usb: ehci: do not set the LSB of Current qTD pointer

[Masahiro Yamada]

According to EHCI specification, the LSB of DWORD 3 of Queue Head
(Current qTD Pointer) is not T-bit, but always zero.

Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---

 drivers/usb/host/ehci-hcd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index c671c72..54e948a 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -971,7 +971,6 @@ int usb_lowlevel_init(int index, enum usb_init_type init, 
void **controller)
qh_list-qh_link = cpu_to_hc32((uint32_t)qh_list | QH_LINK_TYPE_QH);
qh_list-qh_endpt1 = cpu_to_hc32(QH_ENDPT1_H(1) |
QH_ENDPT1_EPS(USB_SPEED_HIGH));
-   qh_list-qh_curtd = cpu_to_hc32(QT_NEXT_TERMINATE);
qh_list-qh_overlay.qt_next = cpu_to_hc32(QT_NEXT_TERMINATE);
qh_list-qh_overlay.qt_altnext = cpu_to_hc32(QT_NEXT_TERMINATE);
qh_list-qh_overlay.qt_token =
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/8] dm: core: a trivial clean up

[Simon Glass]

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] dm: core: remove meaningless if conditional

[Simon Glass]

Hi Masahiro,

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 If the variable ret is equal to -ENOENT, it is trapped at [1] and
 never reaches [2].  At [3], the condition ret != -ENOENT is always
 true.

   if (ret == -ENOENT) {   -- [1]
   continue;
   } else if (ret == -ENODEV) {
   dm_dbg(Device '%s' has no compatible string\n, name);
   break;
   } else if (ret) {   -- [2]
   dm_warn(Device tree error at offset %d\n, offset);
   if (!result || ret != -ENOENT)  -- [3]
   result = ret;
   break;
   }

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 ---

  drivers/core/lists.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/drivers/core/lists.c b/drivers/core/lists.c
 index 3a1ea85..0aad56d 100644
 --- a/drivers/core/lists.c
 +++ b/drivers/core/lists.c
 @@ -136,8 +136,7 @@ int lists_bind_fdt(struct udevice *parent, const void 
 *blob, int offset,
 break;
 } else if (ret) {
 dm_warn(Device tree error at offset %d\n, offset);
 -   if (!result || ret != -ENOENT)
 -   result = ret;
 +   result = ret;

Thanks for the clear explanation.

It looks good, except my intent was to return the first error, hence
the 'if (!result ...'.

Your code will return the last error. Can we preserve the current bahaviour?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/8] dm: core: remove unnecessary return condition in driver lookup

[Simon Glass]

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 The variable drv never becomes NULL because ll_entry_start()
 always returns a valid pointer even if there are no entries.

 The case n_ents == 0 is covered by the following for loop.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8] dm: core: remove unnecessary return condition in uclass lookup

[Simon Glass]

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 These conditions never happen.
  - There is no real uclass with UCLASS_INVALID id.
  - uclass never becomes NULL because ll_entry_start() always returns
a valid pointer.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Yes we now use proper error codes to detect an invalid uclass, so it
is good to clean this up.

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/8] dm: core: refactor linker lists lookup code

[Simon Glass]

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 It looks simpler to use ll_entry_end() than ll_entry_count().
 We can save one variable.  (and it will be helpful for the upcoming
 commit.)

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] dm: core: look up drivers more efficiently

[Simon Glass]

HI Masahiro,

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 The DM initialization function, dm_init_and_scan() is called twice,
 before and after relocation.

 In the first DM scan, only some of drivers are bound for the use in
 pre-reloc code (mostly UART drivers).  In the second scan, all the
 drivers are bound.

 In the current implementation, all the drivers are collected into a
 single array.  Every driver is searched through the array and then
 the DM_FLAG_PRE_RELOC flag is checked.  In the pre-reloc DM scan,
 drivers without DM_FLAG_PRE_RELOC are ignored.  This algorithm works
 enough, but is not very efficient.

 This commit aims to split drivers into two contiguous arrays,
 pre-reloc drivers and post-reloc drivers.  The drivers in the former
 group are declared with U_BOOT_DRIVER_F.  The others are declared with
 U_BOOT_DRIVER.

 pre  post
 _  reloc reloc
   .u_boot_list_2_driver1_1  |   |||   ||
 |   |||   ||
 |   |||   ||
 |  U_BOOT_DRIVER_F  |||   ||
 | (driver1) |||   ||
 |   |   _||_  ||
 |   |   \  /  ||
   .u_boot_list_2_driver1_3  |___|\/   ||
   .u_boot_list_2_driver2_1  |   | ||
 |   | ||
 |   | ||
 |   U_BOOT_DRIVER   | ||
 | (driver2) | ||
 |   |_||_
 |   |\  /
   .u_boot_list_2_driver2_3  |___| \/

 The pre-reloc DM scan searches drivers from .u_boot_list_2_driver1_1
 to .u_boot_list_2_driver1_3.  The post-reloc scan searches ones from
 .u_boot_list_2_driver1_1 and .u_boot_list_2_driver2_3.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
 ---

  doc/driver-model/README.txt |  2 +-
  drivers/core/device.c   |  4 +---
  drivers/core/lists.c| 22 +-
  drivers/core/root.c |  3 ++-
  include/dm/device.h |  8 ++--
  include/dm/lists.h  | 16 
  include/dm/root.h   | 16 
  7 files changed, 43 insertions(+), 28 deletions(-)

 diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
 index 0278dda..e4114d5 100644
 --- a/doc/driver-model/README.txt
 +++ b/doc/driver-model/README.txt
 @@ -739,7 +739,7 @@ Pre-Relocation Support
  --

  For pre-relocation we simply call the driver model init function. Only
 -drivers marked with DM_FLAG_PRE_RELOC or the device tree
 +drivers declared with U_BOOT_DRIVER_F or the device tree
  'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps
  to reduce the driver model overhead.

 diff --git a/drivers/core/device.c b/drivers/core/device.c
 index 49faa29..6fd2f07 100644
 --- a/drivers/core/device.c
 +++ b/drivers/core/device.c
 @@ -157,11 +157,9 @@ int device_bind_by_name(struct udevice *parent, bool 
 pre_reloc_only,
  {
 struct driver *drv;

 -   drv = lists_driver_lookup_name(info-name);
 +   drv = __lists_driver_lookup_name(info-name, pre_reloc_only);

This patch looks good, except that I would prefer
lists_driver_lookup_name_prereloc() to __lists_driver_lookup_name().
The __ seems like an internal compiler name to me. So can you rename
it?

 if (!drv)
 return -ENOENT;
 -   if (pre_reloc_only  !(drv-flags  DM_FLAG_PRE_RELOC))
 -   return -EPERM;

 return device_bind(parent, drv, info-name, (void *)info-platdata,
-1, devp);
 diff --git a/drivers/core/lists.c b/drivers/core/lists.c
 index 1476715..5b61ab5 100644
 --- a/drivers/core/lists.c
 +++ b/drivers/core/lists.c
 @@ -18,10 +18,13 @@
  #include fdtdec.h
  #include linux/compiler.h

 -struct driver *lists_driver_lookup_name(const char *name)
 +#define driver_entry_end(p) (p) ? ll_entry_end(struct driver, driver1) : \
 + ll_entry_end(struct driver, driver2);
 +
 +struct driver *__lists_driver_lookup_name(const char *name, bool 
 pre_reloc_only)
  {
 -   struct driver *entry = ll_entry_start(struct driver, driver);
 -   struct driver *end = ll_entry_end(struct driver, driver);
 +   struct driver *entry = ll_entry_start(struct driver, driver1);
 +   struct driver *end = driver_entry_end(pre_reloc_only);

 for (; entry  end; entry++) {
 if (!strcmp(name, entry-name))
 

Re: [U-Boot] [PATCH 7/8] dm: core: declare pre-reloc drivers with U_BOOT_DRIVER_F

[Simon Glass]

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Replace U_BOOT_DRIVER with U_BOOT_DRIVER_F where the DM_FLAG_PRE_RELOC
 flag is set.

 Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com

Acked-by: Simon Glass s...@chromium.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: video: Add simplefb support

[Grant Likely]

On Sun, Nov 16, 2014 at 7:39 PM, Hans de Goede hdego...@redhat.com wrote:
 From: Luc Verhaegen l...@skynet.be

 Add simplefb support, note this depends on the kernel having support for
 the clocks property which has recently been added to the simplefb devicetree
 binding.

 Signed-off-by: Luc Verhaegen l...@skynet.be
 [hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
  disussed on the devicetree list]
 Signed-off-by: Hans de Goede hdego...@redhat.com

I'm not a U-Boot maintainer, so take my comments with a grain of salt...

This patch seems quite short sighted. The code that calculates and
updates the simple framebuffer node addresses is pretty much going to
be identical for all platforms. Why is sunxi open coding it?
Particularly when there could be fiddly bits around dealing with
#address-cells/#size-cells.

I would think the code to update a simplefb node would be a common
library function.

g.


 ---
  arch/arm/include/asm/arch-sunxi/display.h |  4 ++
  board/sunxi/board.c   | 11 +
  drivers/video/sunxi_display.c | 73 
 +++
  include/configs/sunxi-common.h|  8 
  4 files changed, 96 insertions(+)

 diff --git a/arch/arm/include/asm/arch-sunxi/display.h 
 b/arch/arm/include/asm/arch-sunxi/display.h
 index 8d80ceb..4c694f8 100644
 --- a/arch/arm/include/asm/arch-sunxi/display.h
 +++ b/arch/arm/include/asm/arch-sunxi/display.h
 @@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
  #define SUNXI_HDMI_PLL_DBG0_PLL3   (0  21)
  #define SUNXI_HDMI_PLL_DBG0_PLL7   (1  21)

 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +void sunxi_simplefb_setup(void *blob);
 +#endif
 +
  #endif /* _SUNXI_DISPLAY_H */
 diff --git a/board/sunxi/board.c b/board/sunxi/board.c
 index e6ec5b8..d4530e8 100644
 --- a/board/sunxi/board.c
 +++ b/board/sunxi/board.c
 @@ -24,6 +24,7 @@
  #endif
  #include asm/arch/clock.h
  #include asm/arch/cpu.h
 +#include asm/arch/display.h
  #include asm/arch/dram.h
  #include asm/arch/gpio.h
  #include asm/arch/mmc.h
 @@ -237,3 +238,13 @@ int misc_init_r(void)
 return 0;
  }
  #endif
 +
 +#ifdef CONFIG_OF_BOARD_SETUP
 +void
 +ft_board_setup(void *blob, bd_t *bd)
 +{
 +#ifdef CONFIG_VIDEO_DT_SIMPLEFB
 +   sunxi_simplefb_setup(blob);
 +#endif
 +}
 +#endif /* CONFIG_OF_BOARD_SETUP */
 diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
 index 3f46c31..0bd273e 100644
 --- a/drivers/video/sunxi_display.c
 +++ b/drivers/video/sunxi_display.c
 @@ -13,6 +13,8 @@
  #include asm/arch/display.h
  #include asm/global_data.h
  #include asm/io.h
 +#include fdtdec.h
 +#include fdt_support.h
  #include linux/fb.h
  #include video_fb.h

 @@ -416,3 +418,74 @@ video_hw_init(void)

 return graphic_device;
  }
 +
 +/*
 + * Simplefb support.
 + */
 +#if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_VIDEO_DT_SIMPLEFB)
 +void
 +sunxi_simplefb_setup(void *blob)
 +{
 +   static GraphicDevice *graphic_device = sunxi_display.graphic_device;
 +   const char *node = /chosen/framebuffer0-hdmi;
 +   char name[32];
 +   fdt32_t cells[4];
 +   int i, offset, addrc, sizec, ret, stride;
 +
 +   if (!sunxi_display.enabled)
 +   return;
 +
 +   offset = fdt_path_offset(blob, node);
 +   if (offset  0) {
 +   eprintf(Cannot setup simplefb: %s node not found\n, node);
 +   return;
 +   }
 +
 +   snprintf(name, sizeof(name), framebuffer@%08lx, gd-fb_base);
 +   ret = fdt_set_name(blob, offset, name);
 +   if (ret  0)
 +   goto error;
 +
 +   of_bus_default_count_cells(blob, fdt_parent_offset(blob, offset),
 +  addrc, sizec);
 +   i = 0;
 +   if (addrc == 2)
 +   cells[i++] = 0;
 +   cells[i++] = cpu_to_fdt32(gd-fb_base);
 +   if (sizec == 2)
 +   cells[i++] = 0;
 +   cells[i++] = cpu_to_fdt32(CONFIG_SUNXI_FB_SIZE);
 +
 +   ret = fdt_setprop(blob, offset, reg, cells, sizeof(cells[0]) * i);
 +   if (ret  0)
 +   goto error;
 +
 +   cells[0] = cpu_to_fdt32(graphic_device-winSizeX);
 +   ret = fdt_setprop(blob, offset, width, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   cells[0] = cpu_to_fdt32(graphic_device-winSizeY);
 +   ret = fdt_setprop(blob, offset, height, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   stride = graphic_device-winSizeX * graphic_device-gdfBytesPP;
 +   cells[0] = cpu_to_fdt32(stride);
 +   ret = fdt_setprop(blob, offset, stride, cells, sizeof(cells[0]));
 +   if (ret  0)
 +   goto error;
 +
 +   ret = fdt_setprop_string(blob, offset, format, x8r8g8b8);
 +   if (ret  0)
 +   goto error;
 +
 +   ret = fdt_setprop_string(blob, offset, status, okay);
 +   if (ret  0)
 +   goto error;
 +
 +   return;
 +error:
 +   

Re: [U-Boot] [PATCH v8 1/3] exynos5: fix GPIO information of exynos5420

[Przemyslaw Marczak]

Hello,

Hyungwon, please check my last changes added to those files:
- arch/arm/include/asm/arch-exynos/gpio.h
(Exynos4x12 gpio enum and exynos4x12_gpio_data.)
- arch/arm/include/asm/arch-exynos/cpu.h
(Exynos4x12 gpio base sub parts)

There was an issue with gaps between some of gpio banks, so I added sub 
parts definition and it was adequate to *pinctrl.dts and 
*pinctrl-uboot.dts description.


First problem is, that device-tree description has some specified order 
- and this is the init order (and next real gpio numbering order).


So if we have dts nodes like this:
- pinctrl@1340 { }
- pinctrl@1341 { }
- pinctrl@1400 { }
-  ...
then it means, that gpio init should start from base 1340 - which is 
gpy70 tor the E5422... But there is one thing, which should be taken 
into account - #include exynos54xx-pinctrl-uboot.dtsi,
and actually the included file [...]uboot.dts, will define the gpio init 
order as:

- pinctrl@1401 - gpa00, gpa10, ..., gph00
- pinctrl@1340 - gpy70, gpx00, ..., gpx30 (gpx0-reg=0xc00)
- pinctrl@1341 - gpc00, ..., gpy60
- pinctrl@1400 - gpe00, ..., gpj40
- pinctrl@0386 - gpz00

So, the above gpioXX bind order, should be equal to the enum 
exynos5420_gpio_pin { }. This is important, because if you type:


ODROID-XU3 # gpio toggle gpy00

then you will get the a result:

gpio: pin gpy00 (gpio 160) value is 0

Take a notice that gpy00 == gpio 160, but you defined it as 0 in your enum!
So any call to the gpio inside the code, like this one:

gpio_set_value(EXYNOS5420_GPIO_Y70, 0);

like the pinmux do - will pass wrong gpio number to the function.
And if you are lucky - some gpio numbers could work fine:)

On 11/17/2014 08:45 AM, Simon Glass wrote:

Hi Hyungwon,

On 14 November 2014 06:25, Hyungwon Hwang human.hw...@samsung.com wrote:

This patch fixes wrong GPIO information such as GPIO bank, table which
is used to convert GPIO name to index, bank base address, and etc.

Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
Changes for v4:
- None

Changes for v5:
- None

Changes for v6:
- None

Changes for v7:
- None

Changes for v8:
- None

  arch/arm/include/asm/arch-exynos/cpu.h  |  11 +-
  arch/arm/include/asm/arch-exynos/gpio.h | 232 +++-
  2 files changed, 117 insertions(+), 126 deletions(-)

diff --git a/arch/arm/include/asm/arch-exynos/cpu.h 
b/arch/arm/include/asm/arch-exynos/cpu.h
index 29674ad..48936de 100644
--- a/arch/arm/include/asm/arch-exynos/cpu.h
+++ b/arch/arm/include/asm/arch-exynos/cpu.h
@@ -148,7 +148,7 @@

  /* EXYNOS5420 */
  #define EXYNOS5420_AUDIOSS_BASE0x0381
-#define EXYNOS5420_GPIO_PART6_BASE 0x0386
+#define EXYNOS5420_GPIO_PART5_BASE 0x0386
  #define EXYNOS5420_PRO_ID  0x1000
  #define EXYNOS5420_CLOCK_BASE  0x1001
  #define EXYNOS5420_POWER_BASE  0x1004
@@ -170,11 +170,10 @@
  #define EXYNOS5420_I2S_BASE0x12D6
  #define EXYNOS5420_PWMTIMER_BASE   0x12DD
  #define EXYNOS5420_SPI_ISP_BASE0x131A
-#define EXYNOS5420_GPIO_PART2_BASE 0x1340
-#define EXYNOS5420_GPIO_PART3_BASE 0x13400C00
-#define EXYNOS5420_GPIO_PART4_BASE 0x1341
-#define EXYNOS5420_GPIO_PART5_BASE 0x1400
-#define EXYNOS5420_GPIO_PART1_BASE 0x1401
+#define EXYNOS5420_GPIO_PART1_BASE 0x1340
+#define EXYNOS5420_GPIO_PART2_BASE 0x1341
+#define EXYNOS5420_GPIO_PART3_BASE 0x1400
+#define EXYNOS5420_GPIO_PART4_BASE 0x1401
  #define EXYNOS5420_MIPI_DSIM_BASE  0x1450
  #define EXYNOS5420_DP_BASE 0x145B

diff --git a/arch/arm/include/asm/arch-exynos/gpio.h 
b/arch/arm/include/asm/arch-exynos/gpio.h
index 9699954..aef897d 100644
--- a/arch/arm/include/asm/arch-exynos/gpio.h
+++ b/arch/arm/include/asm/arch-exynos/gpio.h
@@ -1042,83 +1042,7 @@ enum exynos5_gpio_pin {
  };

  enum exynos5420_gpio_pin {
-   /* GPIO_PART1_STARTS */
-   EXYNOS5420_GPIO_A00,/* 0 */


Why does this order need to change? I think you might be trying to
remove the device tree work-around that we currently have. See
arch/arm/dts/exynos54xx-pinctrl-uboot.dtsi:

 /*
  * Replicate the ordering of arch/arm/include/asm/arch-exynos/gpio.h
  * TODO(s...@chromium.org): This ordering ceases to matter once GPIO
  * numbers are not needed in U-Boot for exynos.
  */
 pinctrl@1401 {
 #address-cells = 1;
 #size-cells = 0;
 };
 pinctrl@1340 {
 #address-cells = 1;
 #size-cells = 0;
 gpy7 {
 };

 gpx0 {
 reg = 0xc00;
 };
 };

Since you are changing things 

Re: [U-Boot] [PATCH v8 3/3] Odroid-XU3: Add documentation for Odroid-XU3

[Przemyslaw Marczak]

Hello Hyungwon,

Now we will have some ambiguous naming:
doc/README.odroid and doc/README.odroid-xu3

Please update the first name to Odroid U3 or make it as a common for 
both Odroids, since the documentation you add is at most word by word 
the same - maybe better is to add U3 and  XU3 sections.


On 11/14/2014 07:25 AM, Hyungwon Hwang wrote:

This patch adds documentation for Odroid-XU3. This documentation is
based on that of Odroid (doc/README-odroid) made by Przemyslaw Marczak.
The documentation includes basic information about boot media layout,
environment, partition layout, and the instruction to burn the u-boot
image to boot media.

Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
Changes for v6:
- Newly added

Changes for v7:
- Fix several errata in the documentation

Changes for v8:
- None

  doc/README.odroid-xu3 | 134 ++
  1 file changed, 134 insertions(+)
  create mode 100644 doc/README.odroid-xu3

diff --git a/doc/README.odroid-xu3 b/doc/README.odroid-xu3
new file mode 100644
index 000..7171435
--- /dev/null
+++ b/doc/README.odroid-xu3
@@ -0,0 +1,134 @@
+ U-boot for Odroid XU3
+
+
+1. Summary
+==
+This is a quick instruction for setup Odroid boards based on Exynos5422.
+Exynos5422 is almost the same with Exynos5800 which is a variant of Exynos5422
+for Chromebook.
+
+Board config: odroid-xu3_config
+
+2. Supported devices
+
+This U-BOOT config can be used on the board:
+- Odroid XU3
+with CPU Exynos 5422 and 2GB of RAM
+
+3. Boot sequence
+
+iROM-BL1-(BL2 + TrustZone)-U-BOOT
+
+To boot up, this version of U-BOOT needs BL1, BL2, and TrustZone binary.
+It can be downloaded from:
+https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel
+
+4. Boot media layout
+
+The table below shows SD/eMMC cards layout for U-boot.
+The block offset is starting from 0 and the block size is 512B.
+ -
+|  Binary   | Block offset| part type |
+|   name| SD   | eMMC |(eMMC only)|
+ -
+| Bl1   | 1| 0|  1 (boot) |
+| Bl2   | 31   | 30   |  1 (boot) |
+| U-boot| 63   | 62   |  1 (boot) |


I think, that the tzsw offset is wrong here. Please check it.


+| Tzsw  | 2111 | 2110 |  1 (boot) |
+| Uboot Env | 2560 | 2560 |  0 (user) |
+ -
+
+5. Prepare the SD boot card - with SD card reader
+=
+To prepare bootable media you need boot binaries provided by hardkernel.
+The files from the link in point 3.
+- bl1.bin.hardkernel
+- bl2.bin.hardkernel
+- tzsw.bin.hardkernel
+- u-boot.bin.hardkernel
+
+This is all you need to boot this board. You can write the binaries to SD card
+just by executing sd_fusing.sh. You cannot use this script to write binaries to
+eMMC card.It is valid only for SD card.
+
+*note
+You cannot access the eMMC protected part (the first 8MB roughly) using an
+ordinary eMMC reader.
+
+*note:
+If you build u-boot by yourself, you will find u-boot.bin and u-boot-dtb.bin
+as the build result. You have to use u-boot-dtb.bin instead of u-boot.bin.
+
+quick steps for Linux:
+- Download all files from the link at point 3.
+- put any SD card into the SD reader
+- check the device with dmesg
+- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
+Check if Hardkernel U-boot is booting, and next do the same with your U-boot.
+
+6. Prepare the eMMC boot card
+   with a eMMC card reader (boot from eMMC card slot)
+=
+To boot the device from the eMMC slot you should use a special card reader
+which supports eMMC partition switch. All of the boot binaries are stored
+on the eMMC boot partition which is normally hidden.
+
+The sd_fusing.sh script can be used after updating offsets of binaries
+according to the table from point 4. Be sure that you are working on the right
+eMMC partition - its size is usually very small, about 1-4 MiB.
+
+7. Prepare the eMMC boot card
+   with a SD card reader (boot from SD card slot)
+=
+If you have an eMMC-microSD adapter you can prepare the card as in point 5.
+But then the device can boot only from the SD card slot.
+
+8. Prepare the boot media using Hardkernel U-boot
+=
+You can update the U-boot to the custom one if you have a working bootloader
+delivered with the board on the eMMC/SD card. Then follow the steps:
+- install the android fastboot tool
+- connect a micro usb cable to the board
+- on the U-boot prompt, run command: fastboot (as a root)
+- on the host, run command: 

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

Some progress...

If I turn down the baud rate to 9600, as well as set a line delay of 100 ms,
the loadb transfer works, and I get 0x240 bytes of Hello World at the
address of my choice.

So, it seems to be some kind of baud rate missmatch between my board and the
PC. The console works fine in 115200 baud, so I'm a bit lost here. Does
kermit require slow transfers?

Feel free to chip in.

Thanks,

/Bo



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196499.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/30] power: Add AMS AS3722 PMIC support

[Thierry Reding]

On Wed, Nov 12, 2014 at 06:26:51PM -0700, Simon Glass wrote:
[...]
 diff --git a/drivers/power/as3722.c b/drivers/power/as3722.c
[...]
 +int as3722_init(struct udevice **devp)
 +{
 + struct udevice *pmic;
 + u8 id, revision;
 + int bus = 0;
 + int address = 0x40;

Is there a reason for bus and address to not be unsigned? I also take it
that the plan is to eventually query these from the udevice/DT once I2C
has been converted to DM?

Thierry


pgpPvHqnv6Mb9.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

[Hans de Goede]

Hi,

On 11/17/2014 10:58 AM, Grant Likely wrote:
 On Sun, Nov 16, 2014 at 4:11 PM, Ian Campbell i...@hellion.org.uk wrote:
 On Sun, 2014-11-16 at 16:11 +0100, Hans de Goede wrote:

snip

 Right, I forgot to add one important bit to my explanation, sorry, if
 you look at the binding then it says that the name should be suffixed
 with the output type, so currently the sunxi u-boot code will look for
 /chosen/framebuffer0-hdmi. Which will e.g. also happen on any A10
 based tablets which typically have both hdmi out and an lcd screen,
 in the future I hope we will also get lcd support in u-boot, and then
 logically on tablets the lcd screen would take precedence, so then
 unless overriden through some config mechanism u-boot will chose
 to use the lcd, and will look for /chosen/framebuffer0-lcd which has
 a different set of clocks then /chosen/framebuffer0-hdmi.

 This sounds like a use for:
 compatible = simple-framebuffer,hdmi, simple-framebuffer
 or some such, that's almost exactly what multiople compatible strings
 are for. Relying on specific naming and/or path is rather
 unconventional.
 
 Indeed, for a long time now finding nodes by path has been strongly
 discouraged. It makes it hard to move nodes around when needed. I'm
 not going to make a big deal about it because it doesn't affect the OS
 interface, but Ian's suggestion is sane. simple-framebuffer is enough
 to identify the binding, but you can use additional strings to
 identify the specific hardware interface that U-Boot can use to locate
 the node. ie. sunxi,framebuffer-hdml or some such. You can never be
 sure when someone will produce a board that messes with your naming
 assumptions. What if is suddenly needs to be named framebuffer1-hdmi
 because they added and FPGA that they want as framebuffer0? (Yes, I'm
 making stuff up, but I have to think about the corner cases)

I like the suggestion of using a compatible of : sunxi,framebuffer-hdmi
although it will need to be : sunxi,framebuffer0-hdmi as u-boot
needs to know which simplefb node to use for which display pipeline
(so that the node has the right clocks and whats not).

And I think it makes sense to put simple in there as it is a pre-populated
simplefb node , so then we get:

sunxi,simple-framebuffer0-hdmi

And we can drop the unconventional lookup by path.

I'll go on irc now, and join #devicetree, Ian, maybe you can join us
there to and we can hash out something we can all agree on ?

And then I'll do yet another set of patches (to apply on top on the
kernel side, and a new version of the u-boot patch), and we'll hopefully
end up with something which makes us all happy

snip

 In fact it's a bit odd to have a reg property under /chosen at all,
 since it doesn't really fit in with the bus structure. I've done
 something similar in some bindings I've authored[0], but AIUI I got that
 wrong and really should have used a set of non-reg properties with a
 single value so there was no need to parse using #*-cells  (cf the
 initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI,
 so for my bindings I'm kind of stuck with it for the foreseeable future.

 [0]
 http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD
 
 Ironic isn't it that I though of that as precedence when I suggested
 /chosen! :-)
 
 I actually don't have a problem with it. We do need a way to specify
 runtime memory usage, and /chosen is as good a place as any,
 particularly when it represents things that won't necessarily be
 relevant on kexec or dom0 boot.
 
 The other options are under either the /memory or the /reserved-memory
 tree. Rob and I talked about /reserved-memory quite a lot. We could
 put all the framebuffer details into the memory node that reserves the
 framebuffer. However, I don't like that idea because it kind of makes
 assumptions about how the framebuffer will be located inside the
 memory region and doesn't allow for multiple framebuffers within a
 single region.

I'm not a devicetree expert, but /chosen already came to my mind even
before Grant suggested it, /chosen seems the right place for this to me.

Note that once we drop the path based lookup the location can always be
changed later (to some degree, it still needs to be in a place where
the kernel will bind to it).

Regards,

Hans


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

[Ian Campbell]

On Mon, 2014-11-17 at 09:58 +, Grant Likely wrote:
 I /DO/ want comments though. Putting the node in /chosen is
 unconventional. I want to hear if anyone has a good reason why the
 framebuffers shouldn't be placed into /chosen.

I don't think putting it under /chosen is a problem at all. THe
semantics of some of hte convention properties are a bit odd under
there, but that's not insurmountable.

  AFAIK Grant agrees with v5
 
  AFAIK Grant hasn't actually said that. If he does ack it (or if someone
  points me to the correct mail) then I have no further objections.
 
 My word also isn't gospel.

I suppose I should have said something like I trust Grant's judgement
more than my own on things relating to DT ;-).

  On controversial stuff I want to have
 consensus. For the clock patches and had a long conversation with Rob
 to make sure we were both in agreement before giving my final ack.
 
  In fact it's a bit odd to have a reg property under /chosen at all,
  since it doesn't really fit in with the bus structure. I've done
  something similar in some bindings I've authored[0], but AIUI I got that
  wrong and really should have used a set of non-reg properties with a
  single value so there was no need to parse using #*-cells  (cf the
  initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI,
  so for my bindings I'm kind of stuck with it for the foreseeable future.
 
  [0]
  http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD
 
 Ironic isn't it that I though of that as precedence when I suggested
 /chosen! :-)

:-)

 I actually don't have a problem with it. We do need a way to specify
 runtime memory usage, and /chosen is as good a place as any,
 particularly when it represents things that won't necessarily be
 relevant on kexec or dom0 boot.

The main issue which was explained to me with my Xen bindings was that
reg =  isn't all that meaningful under /chosen because it doesn't fit
into the bus structure, so the #address-/size-cells stuff gets a bit
strange. It's probably tolerable for things which are strictly physical
RAM addresses (as opposed to mmio) since RAM isn't typically behind a
visible bus.

The scheme used for initrds sidesteps all those issues by using separate
(multicellular) properties for the start and end regions and not using
reg= and therefore naturally breaking the expected semantic link with
bus topology which reg implies etc.

 The other options are under either the /memory or the /reserved-memory
 tree. Rob and I talked about /reserved-memory quite a lot. We could
 put all the framebuffer details into the memory node that reserves the
 framebuffer. However, I don't like that idea because it kind of makes
 assumptions about how the framebuffer will be located inside the
 memory region and doesn't allow for multiple framebuffers within a
 single region.

Yes, that sounds strictly worse than the current solution to me.

Ian.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 30/30] net: rtl8169: Add support for RTL-8168/8111g

[Thierry Reding]

On Wed, Nov 12, 2014 at 06:27:16PM -0700, Simon Glass wrote:
 From: Thierry Reding tred...@nvidia.com
 
 This network interface card in found on the NVIDIA Jetson TK1.

Self-correct: s/in found/is found/

Thierry


pgpjpdj35sX6r.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 29/30] net: rtl8169: Use non-cached memory if available

[Thierry Reding]

On Wed, Nov 12, 2014 at 06:27:15PM -0700, Simon Glass wrote:
[...]
 diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
 index fc8c31e..cd26c36 100644
 --- a/drivers/net/rtl8169.c
 +++ b/drivers/net/rtl8169.c
 @@ -41,6 +41,7 @@
   * Modified to use le32_to_cpu and cpu_to_le32 properly
   */
  #include common.h
 +#include errno.h
  #include malloc.h
  #include net.h
  #include netdev.h
 @@ -290,16 +291,15 @@ struct RxDesc {
   * cases the driver will likely fail because the CPU needs to flush the cache
   * when requeuing RX buffers, therefore descriptors written by the hardware
   * may be discarded.
 + *
 + * This can be fixed by defining CONFIG_SYS_NONCACHED_MEMORY which will cause
 + * the driver allocate descriptors from a pool of non-cached memory.

Self-correct: s/driver allocate/driver to allocate/

Thierry


pgpHq5vRyON1s.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 01/30] vsprintf: Add modifier for phys_addr_t

[Thierry Reding]

Hi Simon,

Thanks for taking this over. Besides the three small nitpicks (which
aren't really blockers, so feel free to ignore) this looks like what I
would've done had I respun the series.

Thierry


pgp5d5C1G4rUn.pgp
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 2/3] Odroid-XU3: Add support for Odroid-XU3

[Przemyslaw Marczak]

Hello,

On 11/14/2014 07:25 AM, Hyungwon Hwang wrote:

This patch adds support for Odroid-XU3.

Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Tested-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Lukasz Majewski l.majew...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
---
Changes for v3:
- Remove unnecessary node from DT file
- Remove unnecessary features from config file
- Remove unnecessary macros from board-specific header file
- Fix some trivial typos in comments

Changes for v4:
- Add MMC FIFO buffer's configuration to DT file
- Make CONFIG_OF_CONTROL be set by the target information
- Add basic document to doc/README.odroid-xu3
- Add CONFIG_CMD_EXT4 to config file
- Add environment size and offset to config file
- Add extra default environment to make bootable without modification
- Remove unnecessary features from config file

Changes for v5:
- Convert /include/ to #include in DT file

Changes for v6:
- Separate out the documentation to new commit
- Remove unnecessary header file inclusions from the board-specific setup file
- Make the function board_clock_init be declared, only when
   CONFIG_BOARD_EARLY_INIT_F is defined

Changes for v7:
- Remove OF_CONTROL dependency from !SPL_BUILD

Changes for v8:
- Remove unnecessary properties in DT mmc node

  arch/arm/cpu/armv7/exynos/Kconfig |   5 ++
  arch/arm/dts/Makefile |   3 +-
  arch/arm/dts/exynos5422-odroidxu3.dts |  57 ++
  board/samsung/odroid-xu3/Kconfig  |  12 +++
  board/samsung/odroid-xu3/MAINTAINERS  |   6 ++
  board/samsung/odroid-xu3/Makefile |   7 ++
  board/samsung/odroid-xu3/odroid-xu3.c | 122 
  board/samsung/odroid-xu3/setup.h  |  95 ++
  configs/odroid-xu3_defconfig  |   4 +
  include/configs/odroid_xu3.h  | 144 ++
  10 files changed, 454 insertions(+), 1 deletion(-)
  create mode 100644 arch/arm/dts/exynos5422-odroidxu3.dts
  create mode 100644 board/samsung/odroid-xu3/Kconfig
  create mode 100644 board/samsung/odroid-xu3/MAINTAINERS
  create mode 100644 board/samsung/odroid-xu3/Makefile
  create mode 100644 board/samsung/odroid-xu3/odroid-xu3.c
  create mode 100644 board/samsung/odroid-xu3/setup.h
  create mode 100644 configs/odroid-xu3_defconfig
  create mode 100644 include/configs/odroid_xu3.h

diff --git a/arch/arm/cpu/armv7/exynos/Kconfig 
b/arch/arm/cpu/armv7/exynos/Kconfig
index 13dbd95..16c9a0e 100644
--- a/arch/arm/cpu/armv7/exynos/Kconfig
+++ b/arch/arm/cpu/armv7/exynos/Kconfig
@@ -24,6 +24,10 @@ config TARGET_TRATS2
  config TARGET_ODROID
bool Exynos4412 Odroid board

+config TARGET_ODROID_XU3
+   bool Exynos5422 Odroid board
+   select OF_CONTROL
+
  config TARGET_ARNDALE
bool Exynos5250 Arndale board
select SUPPORT_SPL
@@ -65,6 +69,7 @@ source board/samsung/universal_c210/Kconfig
  source board/samsung/origen/Kconfig
  source board/samsung/trats2/Kconfig
  source board/samsung/odroid/Kconfig
+source board/samsung/odroid-xu3/Kconfig
  source board/samsung/arndale/Kconfig
  source board/samsung/smdk5250/Kconfig
  source board/samsung/smdk5420/Kconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2b9bd93..d984f34 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -12,7 +12,8 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5420-smdk5420.dtb \
exynos5420-peach-pit.dtb \
-   exynos5800-peach-pi.dtb
+   exynos5800-peach-pi.dtb \
+   exynos5422-odroidxu3.dtb
  dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..533d88e
--- /dev/null
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,57 @@
+/*
+ * Odroid XU3 device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include exynos54xx.dtsi
+
+/ {
+   model = Odroid XU3 based on EXYNOS5422;
+   compatible = samsung,odroidxu3, samsung,exynos5;
+
+   aliases {
+   serial0 = /serial@12C0;
+   console = /serial@12C2;
+   };
+
+   memory {
+   device_type = memory;
+   reg =  0x4000 0x1000
+   0x5000 0x1000
+   0x6000 0x1000
+   0x7000 0x1000
+   0x8000 0x1000
+   0x9000 0x1000
+   0xa000 0x1000
+   0xb000 0xea0;
+   };
+
+   serial@12C2 {
+   status=okay;
+   };
+
+   mmc@1220 {
+   samsung,bus-width = 8;
+   

[U-Boot] exynos: please check compiler warning

[Minkyu Kang]

Dear Padmavathi Venna,

Please check below compiler warning.
It can be made a serious problem.

arch/arm/cpu/armv7/exynos/clock.c: In function 'clock_get_periph_rate':
arch/arm/cpu/armv7/exynos/clock.c:264:47: warning: array subscript is above 
array bounds [-Warray-bounds]
  struct clk_bit_info *bit_info = clk_bit_info[peripheral];
   ^
arch/arm/cpu/armv7/exynos/clock.c:264:47: warning: array subscript is above 
array bounds [-Warray-bounds]

-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC] How to get #address-cells in U-Boot?

[Masahiro Yamada]

Hi.


I want to decode the base address of device nodes of my device trees.

For example, drivers/serial/ns16550.c uses fdtdec_get_addr() function
to decode the reg property, but it is not very nice because
it does not check #address-cells.

Precisely, we need to check the parent node to get #address-cells.
(If the parent does not have it, we need to search for it towards the root 
node.)


I am looking for something like of_n_addr_cells() and of_n_size_cells() 
functions
of Linux Kernel.


I don't think it is feasible in U-Boot because
U-Boot handles device tree blobs as they are (as flattened binaries).

If we want to get properties of the parenet node, we must parse the DTB from the
beginning.  Yes, U-Boot actually parses the same DTB over and over again.

Any advice?   Import drivers/of/* from Linux??



Simon, do you have any good idea to solve this problem by DM?
For example, add address_cells and size_cells members to struct udevice
and then  modify drivers/core/simple-bus.c to parse #address-cells and 
#size-cells
and pass them to children.



Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] How to get #address-cells in U-Boot?

[Masahiro Yamada]

Another question.

Can U-boot handle the address transformation?

If the upper bus node has ranges property,
it must also be checked to get the correct base address, I think.



On Mon, 17 Nov 2014 19:38:41 +0900
Masahiro Yamada yamad...@jp.panasonic.com wrote:

 Hi.
 
 
 I want to decode the base address of device nodes of my device trees.
 
 For example, drivers/serial/ns16550.c uses fdtdec_get_addr() function
 to decode the reg property, but it is not very nice because
 it does not check #address-cells.
 
 Precisely, we need to check the parent node to get #address-cells.
 (If the parent does not have it, we need to search for it towards the root 
 node.)
 
 
 I am looking for something like of_n_addr_cells() and of_n_size_cells() 
 functions
 of Linux Kernel.
 
 
 I don't think it is feasible in U-Boot because
 U-Boot handles device tree blobs as they are (as flattened binaries).
 
 If we want to get properties of the parenet node, we must parse the DTB from 
 the
 beginning.  Yes, U-Boot actually parses the same DTB over and over again.
 
 Any advice?   Import drivers/of/* from Linux??
 
 
 
 Simon, do you have any good idea to solve this problem by DM?
 For example, add address_cells and size_cells members to struct udevice
 and then  modify drivers/core/simple-bus.c to parse #address-cells and 
 #size-cells
 and pass them to children.
 
 

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] How to get #address-cells in U-Boot?

[Masahiro Yamada]

On Mon, 17 Nov 2014 19:38:41 +0900
Masahiro Yamada yamad...@jp.panasonic.com wrote:

 Hi.
 
 
 I want to decode the base address of device nodes of my device trees.
 
 For example, drivers/serial/ns16550.c uses fdtdec_get_addr() function
 to decode the reg property, but it is not very nice because
 it does not check #address-cells.
 
 Precisely, we need to check the parent node to get #address-cells.
 (If the parent does not have it, we need to search for it towards the root 
 node.)
 
 
 I am looking for something like of_n_addr_cells() and of_n_size_cells() 
 functions
 of Linux Kernel.
 
 
 I don't think it is feasible in U-Boot because
 U-Boot handles device tree blobs as they are (as flattened binaries).
 
 If we want to get properties of the parenet node, we must parse the DTB from 
 the
 beginning.  Yes, U-Boot actually parses the same DTB over and over again.
 
 Any advice?   Import drivers/of/* from Linux??
 
 
 
 Simon, do you have any good idea to solve this problem by DM?
 For example, add address_cells and size_cells members to struct udevice
 and then  modify drivers/core/simple-bus.c to parse #address-cells and 
 #size-cells
 and pass them to children.
 


I almost solved this problem by myself.

We can get the properties of the parent node with

((struct udevice *)dev)-parent-of_offset



Sorry for noise.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] How to get #address-cells in U-Boot?

[Masahiro Yamada]

Hi.

 
 Another question.
 
 Can U-boot handle the address transformation?
 
 If the upper bus node has ranges property,
 it must also be checked to get the correct base address, I think.


I take this question back too.
Sorry for noise.



 
 On Mon, 17 Nov 2014 19:38:41 +0900
 Masahiro Yamada yamad...@jp.panasonic.com wrote:
 
  Hi.
  
  
  I want to decode the base address of device nodes of my device trees.
  
  For example, drivers/serial/ns16550.c uses fdtdec_get_addr() function
  to decode the reg property, but it is not very nice because
  it does not check #address-cells.
  
  Precisely, we need to check the parent node to get #address-cells.
  (If the parent does not have it, we need to search for it towards the root 
  node.)
  
  
  I am looking for something like of_n_addr_cells() and of_n_size_cells() 
  functions
  of Linux Kernel.
  
  
  I don't think it is feasible in U-Boot because
  U-Boot handles device tree blobs as they are (as flattened binaries).
  
  If we want to get properties of the parenet node, we must parse the DTB 
  from the
  beginning.  Yes, U-Boot actually parses the same DTB over and over again.
  
  Any advice?   Import drivers/of/* from Linux??
  
  
  
  Simon, do you have any good idea to solve this problem by DM?
  For example, add address_cells and size_cells members to struct udevice
  and then  modify drivers/core/simple-bus.c to parse #address-cells and 
  #size-cells
  and pass them to children.
  
  
 
 ___
 U-Boot mailing list
 U-Boot@lists.denx.de
 http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] dm: core: remove meaningless if conditional

[Masahiro Yamada]

Hi Simon,



On Mon, 17 Nov 2014 09:14:15 +
Simon Glass s...@chromium.org wrote:

 Hi Masahiro,
 
 On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
  If the variable ret is equal to -ENOENT, it is trapped at [1] and
  never reaches [2].  At [3], the condition ret != -ENOENT is always
  true.
 
if (ret == -ENOENT) {   -- [1]
continue;
} else if (ret == -ENODEV) {
dm_dbg(Device '%s' has no compatible string\n, name);
break;
} else if (ret) {   -- [2]
dm_warn(Device tree error at offset %d\n, offset);
if (!result || ret != -ENOENT)  -- [3]
result = ret;
break;
}
 
  Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
  ---
 
   drivers/core/lists.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/core/lists.c b/drivers/core/lists.c
  index 3a1ea85..0aad56d 100644
  --- a/drivers/core/lists.c
  +++ b/drivers/core/lists.c
  @@ -136,8 +136,7 @@ int lists_bind_fdt(struct udevice *parent, const void 
  *blob, int offset,
  break;
  } else if (ret) {
  dm_warn(Device tree error at offset %d\n, offset);
  -   if (!result || ret != -ENOENT)
  -   result = ret;
  +   result = ret;
 
 Thanks for the clear explanation.
 It looks good, except my intent was to return the first error, hence
 the 'if (!result ...'.
 
 Your code will return the last error. Can we preserve the current bahaviour?


Do you mean, like this?

   dm_warn(Device tree error at offset %d\n, offset);
   if (!result)
   result = ret;
   break;


I think there is no difference in the behaviour, because
this for loop is escaped out at the first encounter with an error
except -ENOENT.

Here is the only line to set result and it is followed by break statement,
so the last error is also the first error, I think.



Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416218063825-196499.p...@n7.nabble.com you wrote:
 
 If I turn down the baud rate to 9600, as well as set a line delay of 100 ms,
 the loadb transfer works, and I get 0x240 bytes of Hello World at the
 address of my choice.
 
 So, it seems to be some kind of baud rate missmatch between my board and the

You may want to attach a scope and measure the timing, then.

 PC. The console works fine in 115200 baud, so I'm a bit lost here. Does
 kermit require slow transfers?

No, not at all.  On contrary, the whole design is set up to provide
fastest binary download as permitted by the baud rate.

Did you include these options in your port settings?

set carrier-watch off
set handshake none
set flow-control none
set file type bin
set file name lit
set rec pack 1000
set send pack 1000
set window 5
robust

?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
   - Antoine de Saint-Exupery
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] dm: core: look up drivers more efficiently

[Masahiro Yamada]

Hi Simon,


On Mon, 17 Nov 2014 09:22:19 +
Simon Glass s...@chromium.org wrote:
  --- a/drivers/core/device.c
  +++ b/drivers/core/device.c
  @@ -157,11 +157,9 @@ int device_bind_by_name(struct udevice *parent, bool 
  pre_reloc_only,
   {
  struct driver *drv;
 
  -   drv = lists_driver_lookup_name(info-name);
  +   drv = __lists_driver_lookup_name(info-name, pre_reloc_only);
 
 This patch looks good, except that I would prefer
 lists_driver_lookup_name_prereloc() to __lists_driver_lookup_name().
 The __ seems like an internal compiler name to me. So can you rename
 it?

Indeed. I think __ should be used carefully especially when it comes to
host programs, but I think we can play it by ear in standalone binaries
such as the kernel and U-boot code.

I often see __ prefixes in Linux and in my understanding,
__foo() is a use it carefully version or locally used interface of foo()
(for example, when the resources are not protected by spinlocks, etc.).
So, I often use it when I cannot invent a good func name.

Hmm, lists_driver_lookup_name_prereloc() is already too long
and __prereloc is a bit misleading because it is used both before and after 
relocation,
isn't it?


Best Regards
Masahiro Yamada

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

Wolfgang,

Yes, those settings are all in my .kermrc setup.

I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x
1e-6) = 115061.56 baud. Not really 115200 but is it too far from working in
your opinion? The tolerance in RS232 signalling is about 50% of the minimum
pulse width for a byte which would be about 113000 - 117000 baud.

/Bo



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196515.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM: at91 series: convert to generic board

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
Signed-off-by: Bo Shen voice.s...@atmel.com
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
---

 include/configs/at91rm9200ek.h  | 2 ++
 include/configs/at91sam9260ek.h | 2 ++
 include/configs/at91sam9261ek.h | 2 ++
 3 files changed, 6 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] net: macb: write mac address when initialization

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
When boot up without mac address setting, it will give the warning
message like: Warning: failed to set MAC address, however when
execute network related command, it still execute them without any
warning information.

With this patch, it will exit directly with following information:
gmac0: mac address is not valid

It also solve the problem after bootup then set mac address and the
mac address won't set to net device issue.

Signed-off-by: Bo Shen voice.s...@atmel.com
Tested-by: Boris Brezillon boris.brezil...@free-electrons.com
---

 drivers/net/macb.c | 9 +
 1 file changed, 9 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,2/2] ARM: atmel: spl: make css field configurable

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
The clock source for master clock can be slow clock, main clock,
plla clock or upll clock. So, make the clock source selection
field in mckr can be configured.

Signed-off-by: Bo Shen voice.s...@atmel.com
---

 arch/arm/cpu/at91-common/spl.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,1/2] ARM: atmel: spl: make initialization more stable

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
We need to make sure the main clock ready field in MCFR is set
after switch to main crystal oscillator.

Signed-off-by: Bo Shen voice.s...@atmel.com
---

 arch/arm/cpu/at91-common/spl.c | 4 
 1 file changed, 4 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] arm, at91: generate boot.bin file for all atmel SoC

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
generate the boot.bin file for all atmel SoC (arm920, arm926, armv7)

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
Reviewed-by: Masahiro Yamada yamad...@jp.panasonic.com
[fix subject]
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---

 arch/arm/cpu/armv7/at91/config.mk | 4 +---
 scripts/Makefile.spl  | 4 
 2 files changed, 5 insertions(+), 3 deletions(-)

applied to u-boot-atmel/master with fixed subject, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,03/12] arm, at91, mpddrc: fix typo in ddr2_init()

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
use the configure value for computing the ba_off value
not the value from the cr register. This leaded in a
wrong ram configuration on the upcoming corvus spl board
support.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
ignore 80 characters length as Bo Shen and Adreas Biessmann suggested

Changes in v2:
add Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com

 arch/arm/cpu/at91-common/mpddrc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 04/12] arm, at91: compile mpddrc ram init code also for AT91SAM9M10G45

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
- compile mpddrc ram init code also for AT91SAM9M10G45
  based boards.
- in CONFIG_SAMA5D3 case, look for the ATMEL_MPDDRC_CR_DECOD_INTERLEAVED
  in the cr configuration

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
Reviewed-by: Bo Shen voice.s...@atmel.com
---

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
add Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com

 arch/arm/cpu/at91-common/Makefile |  6 +-
 arch/arm/cpu/at91-common/mpddrc.c | 11 ++-
 2 files changed, 15 insertions(+), 2 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 02/12] arm, at91: add spi dataflash support for the taurus board

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Bo Shen voice.s...@atmel.com
Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
---

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
- add comment from Jagan Teki:
  - remove spi_init_f() from board file
  - remove CONFIG_SYS_SPI_WRITE_TOUT from board config file
instead define a default in the spi driver - new patch for v2

 board/siemens/taurus/taurus.c | 18 ++
 include/configs/taurus.h  | 10 ++
 2 files changed, 28 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 01/12] spi, atmel: move CONFIG_SYS_SPI_WRITE_TOUT into common header

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
move CONFIG_SYS_SPI_WRITE_TOUT into drivers/spi/atmel_spi.h
and define a default value. Delete this define in the board
config files, where it is possible (all boards use currently
the same value).

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
rebased against 571bdf16a78e9e116a93d46f4809c4f8a3f2adb6

Changes in v2:
rebased against d58a9451e7339ed4cf2b2627e534611f427fb791
new in v2

 drivers/spi/atmel_spi.h | 4 
 include/configs/afeb9260.h  | 1 -
 include/configs/at91sam9260ek.h | 1 -
 include/configs/at91sam9261ek.h | 1 -
 include/configs/at91sam9263ek.h | 1 -
 include/configs/at91sam9rlek.h  | 1 -
 include/configs/ethernut5.h | 1 -
 include/configs/meesc.h | 1 -
 include/configs/otc570.h| 1 -
 include/configs/pm9261.h| 1 -
 include/configs/pm9263.h| 1 -
 include/configs/sbc35_a9g20.h   | 1 -
 include/configs/tny_a9260.h | 1 -
 include/configs/usb_a9263.h | 1 -
 14 files changed, 4 insertions(+), 13 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 05/12] arm, at91: add missing ddr2 cr register MPDDRC_CR_EBISHARE define

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Bo Shen voice.s...@atmel.com
---

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
add comment from Andreas Biessmann:
  - rename MPDDRC_CR_EBISHARE to MPDDRC_CR_DQMS_SHARED

 arch/arm/include/asm/arch-at91/atmel_mpddrc.h | 1 +
 1 file changed, 1 insertion(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 11/12] arm, at91, spl: add spl support for the taurus board

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
replaces the at91bootstrap code with SPL code.

make the spl image with:
./tools/mkimage -T atmelimage -d spl/u-boot-spl.bin spl/boot.bin

this writes the length of the spl image into the 6th
execption vector. This is needed from the ROM bootloader.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Bo Shen voice.s...@atmel.com
---

Changes in v3:
add comment from Bo Shen:
- make matrix_init weak, and add it in taurs board code
- add Reviewed-by from Bo Shen

Changes in v2:
- rename function nand_erase_one to spl_nand_erase_one as
  Scott Wood suggested

 arch/arm/Kconfig  |  1 +
 board/siemens/taurus/taurus.c | 82 +--
 configs/taurus_defconfig  |  5 +--
 include/configs/taurus.h  | 52 ++-
 4 files changed, 127 insertions(+), 13 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 08/12] spl, nand, atmel_nand: add erase one block function

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
erase one nand block in spl code. keep it simple, as size matters
This is used on the upcoming taurus spl support.

Signed-off-by: Heiko Schocher h...@denx.de
Acked-by: Scott Wood scottw...@freescale.com
Reviewed-by: Bo Shen voice.s...@atmel.com
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
add Acked-by from Scott Wood
add Reviewed-by from Bo Shen

Changes in v2:
add comment from scott wood:
- move nand_erase_one into include/nand.h and rename it
  to spl_nand_erase_one

 drivers/mtd/nand/atmel_nand.c | 33 +
 include/nand.h|  1 +
 2 files changed, 34 insertions(+)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v3,07/12] mtd: atmel_nand: add missing include

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
using this driver in SPL code with CONFIG_SPL_NAND_ECC
configured leads in an compileerror. Fix this.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
Reviewed-by: Bo Shen voice.s...@atmel.com
[fix subject]
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
add Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com

 drivers/mtd/nand/atmel_nand.c | 1 +
 1 file changed, 1 insertion(+)

applied to u-boot-atmel/master, with changed subject thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 10/12] arm, spl, at91: add at91sam9260 and at91sam9g45 spl support

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
add support for using spl code on at91sam9260 and at91sam9g45
based boards.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Bo Shen voice.s...@atmel.com
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
[adopt Bo's change in spl.c]
Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
add comment from Bo shen
- fix AT91_PMC_MCKR_CSS_MASK and AT91_PMC_MCKR_PRES_MASK
- make matrix_init weak, and add it in the taurus board code
- do not introduce ifdef mess for the differences between the SoCs,
  instead use a seperate file for each SoC:
  - for armv5 (arm926ejs, now at91 series), named it spl_at91.c,
  - for armv7 (cortex-a5, now, sama5d3), named it spl_atmel.c
  - move common code to arch/arm/cpu/at91-common/spl.c

Changes in v2: None

 arch/arm/cpu/arm926ejs/at91/at91sam9260_devices.c  |  22 
 arch/arm/cpu/arm926ejs/at91/clock.c|  60 ++
 arch/arm/cpu/armv7/at91/clock.c|  27 +
 arch/arm/cpu/at91-common/Makefile  |   5 +-
 arch/arm/cpu/at91-common/sdram.c   |  77 +
 arch/arm/cpu/at91-common/spl.c |  89 +--
 arch/arm/cpu/at91-common/spl_at91.c| 124 +
 arch/arm/cpu/at91-common/spl_atmel.c   |  76 +
 arch/arm/include/asm/arch-at91/at91_common.h   |   6 +
 arch/arm/include/asm/arch-at91/at91_pmc.h  |   1 +
 arch/arm/include/asm/arch-at91/at91sam9260.h   |   1 +
 .../arm/include/asm/arch-at91/at91sam9260_matrix.h |   5 +
 arch/arm/include/asm/arch-at91/at91sam9_sdramc.h   |  22 +++-
 13 files changed, 424 insertions(+), 91 deletions(-)
 create mode 100644 arch/arm/cpu/at91-common/sdram.c
 create mode 100644 arch/arm/cpu/at91-common/spl_at91.c
 create mode 100644 arch/arm/cpu/at91-common/spl_atmel.c

applied with little changes to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 06/12] spl, nand: add option to boot raw u-boot.bin image only

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
enable to boot only a raw u-boot.bin image from nand with the
CONFIG_SPL_NAND_RAW_ONLY define. This option saves space on
boards where spl space is low.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
Reviewed-by: Bo Shen voice.s...@atmel.com
---
on the siemens taurus board, this option saved 0x14d bytes

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
add Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com

 README|  4 
 common/spl/spl.c  | 15 ++-
 common/spl/spl_nand.c | 13 +
 include/spl.h |  1 +
 4 files changed, 28 insertions(+), 5 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 09/12] spl, mtd, nand, atmel_nand: invert device ready pin logic

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
device ready pin is signalling that the device is ready on state 1
not on 0. Simmiliar as it is in drivers/mtd/nand/nand_spl_simple.c

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
Reviewed-by: Bo Shen voice.s...@atmel.com
Acked-by: Scott Wood scottw...@freescale.com
---

Changes in v3:
add Acked-by from Scott Wood
add Reviewed-by from Bo Shen

Changes in v2:
add Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com

 drivers/mtd/nand/atmel_nand.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v4,3/3] ARM: atmel: add sama5d4ek board support

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
The code for this board supports following features:
  - Boot media support: NAND flash/SD card/SPI flash
  - Support LCD display
  - Support ethernet
  - Support USB mass storage

Signed-off-by: Bo Shen voice.s...@atmel.com
---

Changes in v4:
  - rebase to the mainline master (11ada92)
  - Select CPU_V7 in Kconfig.
  - Drop CONFIG_ARMV7 in board head file.
Series-changes: 3
  - Rewrite the h32mxdiv related code according to Andreas's suggestion.
Series-changes: 2
  - Add sama5d4_devices.c to hold soc related code (e.g: get_cpu_name)
  - rewrite the clock with H32MXDIV

Changes in v2: None

 arch/arm/Kconfig  |   5 +
 arch/arm/cpu/armv7/at91/Makefile  |   1 +
 arch/arm/cpu/armv7/at91/sama5d4_devices.c |  30 +++
 arch/arm/cpu/armv7/at91/timer.c   |   3 +-
 arch/arm/include/asm/arch-at91/at91_pmc.h |   8 +-
 arch/arm/include/asm/arch-at91/clk.h  |  48 -
 arch/arm/include/asm/arch-at91/hardware.h |   2 +
 arch/arm/include/asm/arch-at91/sama5d4.h  | 206 +++
 board/atmel/sama5d4ek/Kconfig |  18 ++
 board/atmel/sama5d4ek/MAINTAINERS |   8 +
 board/atmel/sama5d4ek/Makefile|   8 +
 board/atmel/sama5d4ek/sama5d4ek.c | 317 ++
 configs/sama5d4ek_mmc_defconfig   |   3 +
 configs/sama5d4ek_nandflash_defconfig |   3 +
 configs/sama5d4ek_spiflash_defconfig  |   3 +
 include/configs/sama5d4ek.h   | 214 
 16 files changed, 868 insertions(+), 9 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/at91/sama5d4_devices.c
 create mode 100644 arch/arm/include/asm/arch-at91/sama5d4.h
 create mode 100644 board/atmel/sama5d4ek/Kconfig
 create mode 100644 board/atmel/sama5d4ek/MAINTAINERS
 create mode 100644 board/atmel/sama5d4ek/Makefile
 create mode 100644 board/atmel/sama5d4ek/sama5d4ek.c
 create mode 100644 configs/sama5d4ek_mmc_defconfig
 create mode 100644 configs/sama5d4ek_nandflash_defconfig
 create mode 100644 configs/sama5d4ek_spiflash_defconfig
 create mode 100644 include/configs/sama5d4ek.h

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v3, 12/12] arm, spl, at91: add spl support for the corvus board

[Andreas Bießmann]

Dear Heiko Schocher,

Heiko Schocher h...@denx.de writes:
replaces the at91bootstrap code with SPL code.
make the spl image with:
./tools/mkimage -T atmelimage -d spl/u-boot-spl.bin spl/boot.bin

this writes the length of the spl image into the 6th
execption vector. This is needed from the ROM bootloader.

Signed-off-by: Heiko Schocher h...@denx.de
Reviewed-by: Bo Shen voice.s...@atmel.com
Reviewed-by: Andreas Bießmann andreas.de...@googlemail.com
---

Changes in v3:
add Reviewed-by from Bo Shen

Changes in v2:
- rename function nand_erase_one to spl_nand_erase_one as
  Scott Wood suggested
- add comment from Andreas Biessmann:
  rename MPDDRC_CR_EBISHARE to MPDDRC_CR_DQMS_SHARED

 arch/arm/Kconfig |   1 +
 board/siemens/corvus/board.c | 109 ++-
 configs/corvus_defconfig |   5 +-
 include/configs/corvus.h |  54 +++--
 4 files changed, 151 insertions(+), 18 deletions(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v4,1/3] mtd: atmel_nand: runtime to build gf table for pmecc

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
From: Josh Wu josh...@atmel.com

As in SAMA5D4 SoC, the gf table in ROM code can not be seen.
So, when we try to use PMECC, we need to build it when do
initialization.
Add a macro NO_GALOIS_TABLE_IN_ROM in soc header file. If it
is defined we will build gf table runtime.

The PMECC use the BCH algorithm, so based on the build_gf_tables()
function in lib/bch.c, we can build the Galois Field lookup table.

Signed-off-by: Josh Wu josh...@atmel.com
Signed-off-by: Bo Shen voice.s...@atmel.com
---

Changes in v4: None
Changes in v2:
  - rewrite the gf table build function by Josh.

 drivers/mtd/nand/atmel_nand.c | 75 ++-
 drivers/mtd/nand/atmel_nand_ecc.h |  4 +++
 2 files changed, 78 insertions(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v2] ARM: atmel: add sama5d4 xplained ultra board support

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
The code for this board supports following features:
  - Boot media support: NAND flash/SD card/SPI flash
  - Support LCD display (optional, disabled by default)
  - Support ethernet
  - Support USB mass storage

Signed-off-by: Bo Shen voice.s...@atmel.com
---
This patch based on the patch to add sama5d4ek board support.

Changes in v2:
  - Select CPU_V7 in Kconfig

 arch/arm/Kconfig|   5 +
 board/atmel/sama5d4_xplained/Kconfig|  18 ++
 board/atmel/sama5d4_xplained/MAINTAINERS|   8 +
 board/atmel/sama5d4_xplained/Makefile   |   8 +
 board/atmel/sama5d4_xplained/sama5d4_xplained.c | 319 
 configs/sama5d4_xplained_mmc_defconfig  |   3 +
 configs/sama5d4_xplained_nandflash_defconfig|   3 +
 configs/sama5d4_xplained_spiflash_defconfig |   3 +
 include/configs/sama5d4_xplained.h  | 216 
 9 files changed, 583 insertions(+)
 create mode 100644 board/atmel/sama5d4_xplained/Kconfig
 create mode 100644 board/atmel/sama5d4_xplained/MAINTAINERS
 create mode 100644 board/atmel/sama5d4_xplained/Makefile
 create mode 100644 board/atmel/sama5d4_xplained/sama5d4_xplained.c
 create mode 100644 configs/sama5d4_xplained_mmc_defconfig
 create mode 100644 configs/sama5d4_xplained_nandflash_defconfig
 create mode 100644 configs/sama5d4_xplained_spiflash_defconfig
 create mode 100644 include/configs/sama5d4_xplained.h

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot,v4,2/3] net: macb: enable GMAC IP without GE feature support

[Andreas Bießmann]

Dear Bo Shen,

Bo Shen voice.s...@atmel.com writes:
The User Register in GMAC IP is used to select interface type.
When with GE feature, it is used to select interface between
RGMII and GMII. If without GE feature, it is used to select
interface between MII and RMII.

Signed-off-by: Bo Shen voice.s...@atmel.com
---

Changes in v4: None
Changes in v2: None

 drivers/net/macb.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

applied to u-boot-atmel/master, thanks!

Best regards,
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx:mx6sxsabresd fix pfuz probe failed

[Stefano Babic]

Hi Peng,

On 16/11/2014 12:42, Peng Fan wrote:

 Also PFUZ is connected to I2C bus 0, so change 1 - 0.

 Using this patch PFUZ can be correctly probed:
 PMIC:  PFUZE100 ID=0x11

 Signed-off-by: Peng Fan peng@freescale.com

 Acked-by: Fabio Estevam fabio.este...@freescale.com

Patch is ok for me, too.

Acked-by: Stefano Babic sba...@denx.de

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PULL] u-boot-atmel/master - u-boot/master

[Andreas Bießmann]

Hi Tom,

please pull u-boot-atmel/master into u-boot/master.

Sorry for the huge patch-list. I accidentally pulled in u-boot-arm/master
someday and pushed it. Unfortunately the pushed tree couldn't be deleted for
good reasons. I'm so sorry for the mess.

The following changes since commit 2086e388d56cbb0e3737a6276f04f00f74bf6723:

  Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-11-14 
16:39:32 -0500)

are available in the git repository at:


  git://git.denx.de/u-boot-atmel.git master

for you to fetch changes up to 6531b11f41b6bfebc0b44e4e375a2daa4de92326:

  ARM: atmel: add sama5d4 xplained ultra board support (2014-11-17 13:13:19 
+0100)


Anatolij Gustschin (1):
  arm: imx6: fix typos in CCM_ANALOG_PLL_VIDEO_DENOM register name

Andreas Bießmann (4):
  Merge branch 'master' of git://git.denx.de/u-boot
  tools/kwbimage.c: fix build on darwin
  Merge branch 'master' of git://git.denx.de/u-boot
  Merge branch 'master' of git://git.denx.de/u-boot

Bo Shen (7):
  net: macb: write mac address when initialization
  ARM: at91 series: convert to generic board
  ARM: atmel: spl: make initialization more stable
  ARM: atmel: spl: make css field configurable
  net: macb: enable GMAC IP without GE feature support
  ARM: atmel: add sama5d4ek board support
  ARM: atmel: add sama5d4 xplained ultra board support

Chen-Yu Tsai (1):
  ARM: sunxi: Fix Ippo-q8h-v5 defconfig filename

Christian Gmeiner (3):
  ot1200: add feature pads
  ot1200: add support for usdhc4
  ot1200: rework card detect for eMMC

Dirk Eibach (1):
  ppc: Fix ppc4xx CONFIG_SYS_GENERIC_BOARD

Fabio Estevam (2):
  mx6sabresd: Add Seiko WVGA panel support
  novena: Add MAINTAINERS file

Gerald Kerma (1):
  ARM: kwimage: fix v0 format

Hans de Goede (13):
  usb: Remove unnecessary portnr lookup from usb_new_device
  usb: Do not power-cycle usb devices on init
  usb: ehci: Do not disable an already disabled periodic schedule
  usb: ehci: Move interrupt packet length check to create_int_queue
  usb: ehci: Move cache invalidation to poll_int_queue
  usb: Make pollable int support available outside of ehci-hcd.c
  usb: kbd: Remove unused usb_kbd_generic_poll function
  usb: kbd: Fix memleak on usb_kbd_deregister()
  stdio: Fix memleak on stdio_deregister
  usb: kbd: Cache pipe, interval and packetsize
  usb: kbd: Add (optional) support for using an interrupt queue for polling
  dm: sunxi: Request card detect gpio
  dm: sunxi: Request USB vbus gpio

Heiko Schocher (14):
  arm, imx, spi: detect spi flash again on aristainetos board
  arm, at91: generate boot.bin file for all atmel SoC
  spi, atmel: move CONFIG_SYS_SPI_WRITE_TOUT into common header
  arm, at91: add spi dataflash support for the taurus board
  arm, at91, mpddrc: fix typo in ddr2_init()
  arm, at91: compile mpddrc ram init code also for AT91SAM9M10G45
  arm, at91: add missing ddr2 cr register MPDDRC_CR_EBISHARE define
  spl, nand: add option to boot raw u-boot.bin image only
  mtd: atmel_nand: add missing include
  spl, nand, atmel_nand: add erase one block function
  spl, mtd, nand, atmel_nand: invert device ready pin logic
  arm, spl, at91: add at91sam9260 and at91sam9g45 spl support
  arm, at91, spl: add spl support for the taurus board
  arm, spl, at91: add spl support for the corvus board

Ian Campbell (7):
  sunxi: kconfig: Add top-level ARCH_SUNXI
  sunxi: kconfig: Rename TARGET_SUN[45678]I to MACH_SUN[45678]I.
  sunxi: Kconfig: Make SPL_FEL a toplevel Kconfig option
  sunxi: Use CONFIG_MACH_SUN?I from Kconfig instead of CONFIG_SUN?I
  sunxi: Drop FEL variants of defconfigs.
  sunxi: kconfig: Introduce CONFIG_TARGET_BOARD
  sunxi: kconfig: Add %_felconfig rule to enable FEL build of sunxi 
platforms.

Igor Grinberg (1):
  MAINTAINERS: fix Pantelis Antoniou email address

Jeroen Hofstee (4):
  board: wandboard: add usb storage
  i2c: use __weak
  arm926ejs: cache: use __weak
  serial: add prototypes for init functions

Josh Wu (1):
  mtd: atmel_nand: runtime to build gf table for pmecc

Marek Vasut (3):
  ARM: mx6: Add support for Kosagi Novena
  mtd: nand: mxs: Add ECC geometry for 2048b/112b NAND
  arm: mxs: Define bootscript env variable on m28evk

Markus Niebel (2):
  tqma6: fix sf detection
  tqma6: fix typo in header guard define

Masahiro Yamada (13):
  arm: debug: import debug files from Linux 3.16
  arm: debug: replace license blocks with SPDX
  arm: debug: add Kconfig entries for lowlevel debug
  arm: debug: adjust for U-Boot
  Remove unused files
  ppc/arm: remove remainders of dead boards in Kconfig
  Remove the CREDITS file
  sparc: Use nicer prompt for board select menu
  sparc: move CONFIG_{LEON, LEON2, 

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416225420788-196515.p...@n7.nabble.com you wrote:
 
 Yes, those settings are all in my .kermrc setup.

OK.  Just checking to make sure we don;t miss anything.

 I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x
 1e-6) = 115061.56 baud. Not really 115200 but is it too far from working in
 your opinion? The tolerance in RS232 signalling is about 50% of the minimum
 pulse width for a byte which would be about 113000 - 117000 baud.

That's just 0.12% off, this should not be the problem.

Did you measure both directions (Tx on PC, and Tx on target) ?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The human mind treats a new idea the way the body  treats  a  strange
protein - it rejects it. - P. Medawar
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416225420788-196515.p...@n7.nabble.com you wrote:
 
 I measured the fastest pulse on my scope to 8.691 µs, which gives 1/(8.691 x
...

Re-reading this I stumble over the fastest pulse.  Did you also
verify that the bit widths are all the same?

What about the stop bit settings?  Are both sides set to 8N1?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Now here's something you're really going to like!
- Rocket J. Squirrel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

Well, I measured TX and RX at the target. They both have the same minimum
pulse width of about 8.7 µs.

I'm reading up on delays in c-kermit. Is there a way to set char- and line
delays somehow?

In Tera Term for Windows you can set them but they seem to have no effect on
Kermit transfers, only on the console.

Thank you,

/Bo



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196541.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v6 2/4] mx6: thermal: Add i.MX6 CPU thermal sensor support

[Stefano Babic]

Hi Nitin,


On 14/11/2014 21:13, nitin.g...@freescale.com wrote:
 From: Nitin Garg nitin.g...@freescale.com
 
 i.MX6 SoC has onchip temperature sensor. Add driver
 for this sensor.
 
 Signed-off-by: Nitin Garg nitin.g...@freescale.com
 ---
  drivers/Makefile  |1 +
  drivers/thermal/Makefile  |8 +++
  drivers/thermal/imx_thermal.c |  144 
 +
  include/imx_thermal.h |   15 +
  4 files changed, 168 insertions(+)
  create mode 100644 drivers/thermal/Makefile
  create mode 100644 drivers/thermal/imx_thermal.c
  create mode 100644 include/imx_thermal.h
 

I have some conceptional question here. This introduces a new set or,
better, class of drivers, as we are used to see in kernel as
thermal. As we discussed in last u-boot mini summit, the preferred way
to introduce new drivers into current u-boot is to use DM (Driver
Model), because this is the way u-boot will follow in the future. It
will take some time porting the current drivers, but it is easier for
drivers introducing new features.

This is exactly this case: there is at the moment no thermal drivers,
and it would be nice to introduce it using DM, else we will have the
problem in the near future to port this drivers, too, and maybe some
further drivers adding thermal monitoring.

This means you have to add a thermal class (you can take a look at the
spi driver, it was already ported to dm) and define the functions your
class exports. I think at the moment you define only a monitor, but
feel free to add further functions, preferably in the same way as the
linux kernel does (see include/linux/thermal.h in kernel tree).

 diff --git a/drivers/Makefile b/drivers/Makefile
 index 33227c8..7683c61 100644
 --- a/drivers/Makefile
 +++ b/drivers/Makefile
 @@ -21,3 +21,4 @@ obj-y += pwm/
  obj-y += input/
  # SOC specific infrastructure drivers.
  obj-y += soc/
 +obj-y += thermal/
 diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
 new file mode 100644
 index 000..04ae395
 --- /dev/null
 +++ b/drivers/thermal/Makefile
 @@ -0,0 +1,8 @@
 +#
 +# (C) Copyright 2014 Freescale Semiconductor, Inc.
 +# Author: Nitin Garg nitin.g...@freescale.com
 +#
 +# SPDX-License-Identifier:   GPL-2.0+
 +#
 +
 +obj-$(CONFIG_IMX6_THERMAL) += imx_thermal.o
 diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c
 new file mode 100644
 index 000..fe9dd85
 --- /dev/null
 +++ b/drivers/thermal/imx_thermal.c
 @@ -0,0 +1,144 @@
 +/*
 + * (C) Copyright 2014 Freescale Semiconductor, Inc.
 + * Author: Nitin Garg nitin.g...@freescale.com
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +#include config.h
 +#include common.h
 +#include div64.h
 +#include fuse.h
 +#include asm/io.h
 +#include asm/arch/clock.h
 +
 +#define TEMPERATURE_MIN  -40
 +#define TEMPERATURE_HOT  80
 +#define TEMPERATURE_MAX  125
 +#define FACTOR0  1000
 +#define FACTOR1  15976
 +#define FACTOR2  4297157
 +#define MEASURE_FREQ 327
 +
 +#define TEMPSENSE0_TEMP_CNT_SHIFT8
 +#define TEMPSENSE0_TEMP_CNT_MASK (0xfff  TEMPSENSE0_TEMP_CNT_SHIFT)
 +#define TEMPSENSE0_FINISHED  (1  2)
 +#define TEMPSENSE0_MEASURE_TEMP  (1  1)
 +#define TEMPSENSE0_POWER_DOWN(1  0)
 +#define MISC0_REFTOP_SELBIASOFF  (1  3)
 +#define TEMPSENSE1_MEASURE_FREQ  0x
 +
 +static int read_cpu_temperature(u32 fuse)
 +{
 + int temperature;
 + unsigned int reg, n_meas;
 + struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
 + int t1, n1;
 + u32 c1, c2;
 + u64 temp64;
 +
 + /* make sure pll3 is enabled for thermal sensor */
 + enable_pll3();
 +
 + /*
 +  * Sensor data layout:
 +  *   [31:20] - sensor value @ 25C
 +  * We use universal formula now and only need sensor value @ 25C
 +  * slope = 0.4297157 - (0.0015976 * 25C fuse)
 +  */
 + n1 = fuse  20;
 + t1 = 25; /* t1 always 25C */
 +
 + /*
 +  * Derived from linear interpolation:
 +  * slope = 0.4297157 - (0.0015976 * 25C fuse)
 +  * slope = (FACTOR2 - FACTOR1 * n1) / FACTOR0
 +  * (Nmeas - n1) / (Tmeas - t1) = slope
 +  * We want to reduce this down to the minimum computation necessary
 +  * for each temperature read.  Also, we want Tmeas in millicelsius
 +  * and we don't want to lose precision from integer division. So...
 +  * Tmeas = (Nmeas - n1) / slope + t1
 +  * milli_Tmeas = 1000 * (Nmeas - n1) / slope + 1000 * t1
 +  * milli_Tmeas = -1000 * (n1 - Nmeas) / slope + 1000 * t1
 +  * Let constant c1 = (-1000 / slope)
 +  * milli_Tmeas = (n1 - Nmeas) * c1 + 1000 * t1
 +  * Let constant c2 = n1 *c1 + 1000 * t1
 +  * milli_Tmeas = c2 - Nmeas * c1
 +  */
 + temp64 = FACTOR0;
 + temp64 *= 1000;
 + do_div(temp64, FACTOR1 * n1 - FACTOR2);
 + c1 = temp64;
 + 

Re: [U-Boot] [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards

[Albert ARIBAUD]

Hello li.xi...@freescale.com,

On Mon, 17 Nov 2014 02:16:11 +, li.xi...@freescale.com
li.xi...@freescale.com wrote:
 Hi Albert,
 
 
  -Original Message-
  From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
  Sent: Friday, November 14, 2014 7:45 PM
  To: Xiubo Li-B47053
  Cc: Sun York-R58495; Jin Zhengxiong-R64188; u-boot@lists.denx.de
  Subject: Re: [PATCH v3 3/5] ls102xa: HYP/non-sec: support for ls102xa boards
  
  Hello li.xi...@freescale.com,
  
  On Fri, 14 Nov 2014 09:06:13 +, li.xi...@freescale.com
  li.xi...@freescale.com wrote:
   Hi Albert,
  
 +#if defined(CONFIG_ARMV7_NONSEC) || defined(CONFIG_ARMV7_VIRT)
 +/* Setting the address at which secondary cores start from.*/
 +void smp_set_core_boot_addr(unsigned long addr, int corenr)
 +{
 + struct ccsr_gur __iomem *gur = (void 
 *)(CONFIG_SYS_FSL_GUTS_ADDR);
 +
 + /*
 +  * After setting the secondary cores start address,
 +  * just release them to boot.
 +  */
 + out_be32(gur-scratchrw[0], addr);
 + out_be32(gur-brrl, 0x2);
 +}
   
This function does not exactly [set] the address at which secondary
cores start from; it sets *a* secondary core's boot address, and then
it *boots* it.
   
  
   Okay, I will fix it later.
  
Why does this version of smp_set_core_boot_addr() need to boot the core
in addition to setting the address, whereas the existing ones in
virt_v7, vexpress_common and arndale don't boot the cores?
   
  
   Yes, they don't doing the release operation.
  
   For Low Power Management requirement, maybe only one core will be used, 
   and
  then
   We also make sure that the secondary core must be in low power and deep
  sleep
   mode(using wfi). So I just release it here, to make sure that the wfi
  instruction
   will be executed as early as possible.
  
  Right after smp_set_core_boot_addr() is called, kick_all_cpus() isgoing
  to be called. Wouldn't that boot your CPUs just as well?
  
 
 Yes, it will.
 
 But before that we must do the holdoff bit set operation as the SoC's 
 requirement.
 
 The BRR contains control bits for enabling boot for each core. On exiting 
 HRESET or
 PORESET, the RCW BOOT_HO field optionally allows for logical core 0 to be 
 released
 for booting or to remain in boot holdoff. All other cores remain in boot 
 holdoff until their
 corresponding bit is set.
 
 Maybe the comment is not very clear and a bit confusing.

Before I'm lost entirely, do you mean that the comment:

 + /*
 +  * After setting the secondary cores start address,
 +  * just release them to boot.
 +  */

Is actually wrong, and the instructions that follow it do not actually
boot the secondary core(s)?

 Thanks,
 
 BRs
 Xiubo

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 4/4] mx6: Use a common SPL configuration file

[Stefano Babic]

Hi Fabio,

On 14/11/2014 12:37, Fabio Estevam wrote:
 From: Fabio Estevam fabio.este...@freescale.com
 
 Many boards use a minimal .cfg file in the SPL case.
 
 Introduce spl_sd.cfg so that we can reuse it.
 
 Signed-off-by: Fabio Estevam fabio.este...@freescale.com
 ---
 Changes since v1:
 - Newly introduced on this series
 
  arch/arm/imx-common/spl_sd.cfg|  8 
  board/compulab/cm_fx6/imximage.cfg|  8 
  board/freescale/mx6sabresd/mx6sabresd_spl.cfg | 20 
  board/kosagi/novena/setup.cfg | 16 
  configs/cm_fx6_defconfig  |  2 +-
  configs/mx6sabresd_spl_defconfig  |  2 +-
  configs/novena_defconfig  |  2 +-
  7 files changed, 11 insertions(+), 47 deletions(-)
  create mode 100644 arch/arm/imx-common/spl_sd.cfg
  delete mode 100644 board/compulab/cm_fx6/imximage.cfg
  delete mode 100644 board/freescale/mx6sabresd/mx6sabresd_spl.cfg
  delete mode 100644 board/kosagi/novena/setup.cfg
 
 diff --git a/arch/arm/imx-common/spl_sd.cfg b/arch/arm/imx-common/spl_sd.cfg
 new file mode 100644
 index 000..5fc3e8a
 --- /dev/null
 +++ b/arch/arm/imx-common/spl_sd.cfg
 @@ -0,0 +1,8 @@
 +/*
 + * Copyright (C) 2014, Compulab Ltd - http://compulab.co.il/
 + *
 + * SPDX-License-Identifier:  GPL-2.0+
 + */
 +
 +IMAGE_VERSION2
 +BOOT_FROMsd
 diff --git a/board/compulab/cm_fx6/imximage.cfg 
 b/board/compulab/cm_fx6/imximage.cfg
 deleted file mode 100644
 index 420947e..000
 --- a/board/compulab/cm_fx6/imximage.cfg
 +++ /dev/null
 @@ -1,8 +0,0 @@
 -/*
 - * Copyright (C) 2014, Compulab Ltd - http://compulab.co.il/
 - *
 - * SPDX-License-Identifier:  GPL-2.0+
 - */
 -
 -IMAGE_VERSION 2
 -BOOT_FROMsd
 diff --git a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg 
 b/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
 deleted file mode 100644
 index 1d031ba..000
 --- a/board/freescale/mx6sabresd/mx6sabresd_spl.cfg
 +++ /dev/null
 @@ -1,20 +0,0 @@
 -/*
 - * Copyright (C) 2011 Freescale Semiconductor, Inc.
 - * Jason Liu r64...@freescale.com
 - *
 - * SPDX-License-Identifier:  GPL-2.0+
 - *
 - * Refer doc/README.imximage for more details about how-to configure
 - * and create imximage boot image
 - *
 - * The syntax is taken as close as possible with the kwbimage
 - */
 -
 -/* image version */
 -IMAGE_VERSION 2
 -
 -/*
 - * Boot Device : one of
 - * spi, sd (the board has no nand neither onenand)
 - */
 -BOOT_FROM  sd
 diff --git a/board/kosagi/novena/setup.cfg b/board/kosagi/novena/setup.cfg
 deleted file mode 100644
 index a79d1f7..000
 --- a/board/kosagi/novena/setup.cfg
 +++ /dev/null
 @@ -1,16 +0,0 @@
 -/*
 - * Copyright (C) 2014 Marek Vasut ma...@denx.de
 - *
 - * SPDX-License-Identifier:  GPL-2.0+
 - *
 - * Refer docs/README.imxmage for more details about how-to configure
 - * and create imximage boot image
 - *
 - * The syntax is taken as close as possible with the kwbimage
 - */
 -
 -/* image version */
 -IMAGE_VERSION 2
 -
 -/* Boot Device : sd */
 -BOOT_FROM sd
 diff --git a/configs/cm_fx6_defconfig b/configs/cm_fx6_defconfig
 index 50c06f7..3c0d64f 100644
 --- a/configs/cm_fx6_defconfig
 +++ b/configs/cm_fx6_defconfig
 @@ -1,4 +1,4 @@
  CONFIG_SPL=y
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/compulab/cm_fx6/imximage.cfg,MX6QDL,SPL
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6QDL,SPL
  +S:CONFIG_ARM=y
  +S:CONFIG_TARGET_CM_FX6=y
 diff --git a/configs/mx6sabresd_spl_defconfig 
 b/configs/mx6sabresd_spl_defconfig
 index b7b26df..12e7844 100644
 --- a/configs/mx6sabresd_spl_defconfig
 +++ b/configs/mx6sabresd_spl_defconfig
 @@ -1,5 +1,5 @@
  CONFIG_SPL=y
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/freescale/mx6sabresd/mx6sabresd_spl.cfg,SPL,MX6Q
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,SPL,MX6Q
  +S:CONFIG_ARM=y
  +S:CONFIG_TARGET_MX6SABRESD=y
  
 diff --git a/configs/novena_defconfig b/configs/novena_defconfig
 index a560afb..d28dbd7 100644
 --- a/configs/novena_defconfig
 +++ b/configs/novena_defconfig
 @@ -1,4 +1,4 @@
  CONFIG_SPL=y
 -CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=board/kosagi/novena/setup.cfg,MX6Q,SPL
 +CONFIG_SYS_EXTRA_OPTIONS=IMX_CONFIG=arch/arm/imx-common/spl_sd.cfg,MX6Q,SPL
  +S:CONFIG_ARM=y
  +S:CONFIG_TARGET_KOSAGI_NOVENA=y
 

Acked-by: Stefano Babic sba...@denx.de

Best regards,
Stefano Babic

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

The fastest pulse = the time that one bit encompasses.

The following picture shows sending the character 'U' (0x01010101):

http://u-boot.10912.n7.nabble.com/file/n196545/tek4.png 

Channel 1 shows the 'U' sent from the PC. Channel 2 shows the 'U' sent as
reply from the board, which is also displayed on the console. To me it seems
fine, with a trailing stop bit as well.

I have not altered the 8N1 configuration in the config files for the board.
The only change is the use of USART3 instead of USART0. The PC is set to
8N1-115200.



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196545.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416227882897-196541.p...@n7.nabble.com you wrote:
 Well, I measured TX and RX at the target. They both have the same minimum
 pulse width of about 8.7 µs.
 
 I'm reading up on delays in c-kermit. Is there a way to set char- and line
 delays somehow?

You should not need any such delays.  The protocol is simple enough.
Even a slow processor should have ample resources to handle this - I
think I had this working on some ancient MPC860 PowerPC system running
at just 33 MHz CPU clock.

What is your CPU clock?

You do have caches enabled, don't you?

Best regards,

Wolfgang Denk

--
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
  Bugs are by far the largest and  most successful class of
  entity, with nearly a million known species. In this res-
  pect they outnumber all the other  known  creatures about
  four to one.  -- Professor Snope's Encyclopedia of Animal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416230584402-196545.p...@n7.nabble.com you wrote:
 
 The following picture shows sending the character 'U' (0x01010101):
 
 http://u-boot.10912.n7.nabble.com/file/n196545/tek4.png 
 
 Channel 1 shows the 'U' sent from the PC. Channel 2 shows the 'U' sent as
 reply from the board, which is also displayed on the console. To me it seems
 fine, with a trailing stop bit as well.

Indeed, this looks fine to me as well.  Strange.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
...when fits of creativity run strong, more than  one  programmer  or
writer  has  been  known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM

[Tom Rini]

On Fri, Nov 14, 2014 at 03:20:44PM +0200, Lubomir Popov wrote:

 On the J6Eco EVM we have two on-board devices on the I2C5 bus; this
 bus is also routed to the camera and expansion connectors. I2C4 is
 routed to one of the expansion connectors. This patch enables usage
 of these two buses.
 
 For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation'
 patch is required as a prerequisite.
 
 Tested on a J6 ECO EVM rev.B with a DRA726 ES1.0.
 
 Signed-off-by: Lubomir Popov l-po...@ti.com

OK, but what's the usecase for enabling these in U-Boot?  Are we using
things on these buses?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[bomellberg]

Dear Wolfgang!

Thank you for your efforts to help me out.

I keep coming back to the fact that loads works fine in 115200 baud, but
loadb does not.

If there is indeed a timing issue, it must be some handshaking in the Kermit
protocol, right? The loads command just absorbs data as it is transferred,
but the loadb command, using Kermit, tries to speed up the transfer by
adjusting packet size according to crc-errors.

I am a bit baffled as you can imagine.

/Bo



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196549.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/3] arm: odroid: usb: add support for usb host including ethernet

[Minkyu Kang]

On 30/10/14 01:22, Suriyan Ramasami wrote:
 This change adds support for enabling the USB host features of the board.
 This includes the USB3503A hub and the SMC LAN9730 ethernet controller
 as well.
 
 Signed-off-by: Suriyan Ramasami suriya...@gmail.com
 
 ---
 
 Changes in v3:
 * removed set_usb_ethaddr() and related code as the GUID registers do not
   seem to be documented anywhere. This is sad, as this mechanism allows
   for each Odroid to boot up with the same MAC address every time, but no
   two odroids shall have the same MAC address on boot. This ensures multiple
   odroids in the same LAN to come up without conflicting MAC addresses.
 * Minkyu - Do not mix cpu_is... and proid_is...
 
 Changes in v2:
 * Jaehoon - Split power.[ch] as a separate patch
 * Removed an unneeded header file from ehci-exynos.c
 * Jaehoon - Fix indentation in the dts file
 
 Changes in v1:
 * First try
 
  arch/arm/dts/exynos4412-odroid.dts  | 11 +++
  arch/arm/include/asm/arch-exynos/ehci.h | 13 
  board/samsung/odroid/odroid.c   | 32 +++
  drivers/usb/host/ehci-exynos.c  | 55 
 -
  include/configs/odroid.h| 13 
  5 files changed, 116 insertions(+), 8 deletions(-)
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 2/3] arm: odroid: enable/disable usb host phy for exynos4412

[Minkyu Kang]

On 30/10/14 01:22, Suriyan Ramasami wrote:
 Enable/disable the usb host phy on the odroid U/X2 boards which are based
 on the Exynos4412 SOC.
 
 Signed-off-by: Suriyan Ramasami suriya...@gmail.com
 
 ---
 
 Changes in v3:
 * Minkyu - do not mix cpu_is... and proid_is...
 
 Changes in v2:
 * Jaehoon - separate this patch out
 
 Changes in v1:
 * First try
 
  arch/arm/cpu/armv7/exynos/power.c| 27 +++
  arch/arm/include/asm/arch-exynos/power.h |  7 +++
  2 files changed, 34 insertions(+)
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/3] arm: odroid: pmic77686: allow buck voltage settings

[Minkyu Kang]

On 30/10/14 01:22, Suriyan Ramasami wrote:
 Allow to set the buck voltage for the max77686.
 This will be used to reset the SMC LAN9730 ethernet on the odroids.
 
 Signed-off-by: Suriyan Ramasami suriya...@gmail.com
 
 ---
 
 Changes in v3:
 * Correct ldo and buck validation logic
 * Jaehoon/Przemyslaw - Use negative errno values for error condistions
 * Albert - its buck not bucket
 
 Changes in v2:
 * Jaehoon - separate out this patch
 
 Changes in v1:
 - First try
 
  drivers/power/pmic/pmic_max77686.c | 52 
 +++---
  include/power/max77686_pmic.h  |  3 +++
  2 files changed, 52 insertions(+), 3 deletions(-)
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] SMDK2410: convert to generic board

[Minkyu Kang]

On 30/10/14 17:15, David Müller wrote:
 Compile-time tested only, as I currently don't have access to
 the eval board.
 
 Signed-off-by: David Müller d.muel...@elsoft.ch
 ---
  include/configs/smdk2410.h | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/include/configs/smdk2410.h b/include/configs/smdk2410.h
 index d4ae19f..5df0e28 100644
 --- a/include/configs/smdk2410.h
 +++ b/include/configs/smdk2410.h
 @@ -24,6 +24,8 @@
  
  #define CONFIG_SYS_TEXT_BASE 0x0
  
 +#define CONFIG_SYS_GENERIC_BOARD
 +
  #define CONFIG_SYS_ARM_CACHE_WRITETHROUGH
  
  /* input clock of PLL (the SMDK2410 has 12MHz input clock) */
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] exynos: dts: Correct USB vbus-gpio numbering for Snow

[Minkyu Kang]

On 06/11/14 19:44, Sjoerd Simons wrote:
 The current vbus GPIOs on snow make very little sense, their number is
 far above the maximum. As a result, USB doesn't work on snow.
 
 Correct the GPIO numbering so they match the current scheme for exynos5.
 Tested both EHCI and XHCI to correctly work after this change.
 
 Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
 ---
  arch/arm/dts/exynos5250-snow.dts | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/arch/arm/dts/exynos5250-snow.dts 
 b/arch/arm/dts/exynos5250-snow.dts
 index 6fd9275..95af025 100644
 --- a/arch/arm/dts/exynos5250-snow.dts
 +++ b/arch/arm/dts/exynos5250-snow.dts
 @@ -131,11 +131,11 @@
   };
  
   ehci@1211 {
 - samsung,vbus-gpio = gpio 0x309 0; /* X11 */
 + samsung,vbus-gpio = gpio 0xb1 0; /* X11 */
   };
  
   xhci@1200 {
 - samsung,vbus-gpio = gpio 0x317 0; /* X27 */
 + samsung,vbus-gpio = gpio 0xbf 0; /* X27 */
   };
  
   tmu@1006 {
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/3] exynos config updates

[Minkyu Kang]

On 09/11/14 19:44, Ian Campbell wrote:
 This series rebases my exynos config_distro_*.h patches as requested.
 Baseline is u-boot.git#master 11ada9225a16 (ahead of current
 u-boot-samsung).
 
 I also included Increase command line buffer size (CONFIG_SYS_CBSIZE)
 which was previously posted separately.
 
 Ian.
 
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/7] Addition of new board Peach-Pi

[Minkyu Kang]

On 14/11/14 02:08, Akshay Saraswat wrote:
 Now we are adding a new Peach-Pi board which is a variant of Peach-Pit
 and is based on Exynos5800. Exynos5800 itself is a variant of Exynos5420,
 hence, most of the hardware config and settings are reused for this board.
 
 Changes since v1:
   - Rebased all the patches
 
 Changes since v2:
   - Rebased all the patches
   - Added new patch Enable update mode for DREX controller
 
 Changes since v3:
   - Rebased all the patches
   - Added Tested-by and Acked-by
   - In patch 3/7 fixed warning line over 80 characters
 
 Akshay Saraswat (5):
   Exynos5800: Introduce new proid for Exynos5800
   Exynos5800: Add DTS for new board Peach-Pi
   Config: Exynos5800: Enable build for Peach-Pi
   Config: Exynos5420: Refactor SDRAM Bank and Size
   Exynos5: ddr3: Choose between single or double channel config
 
 Alim Akhtar (1):
   DMC: Exynos5: Enable update mode for DREX controller
 
 Vadim Bendebury (1):
   Peach-Pi: Use the enhanced usb_copy() prototype
 
  arch/arm/cpu/armv7/exynos/Kconfig  |   7 +-
  arch/arm/cpu/armv7/exynos/clock.c  |  19 +--
  arch/arm/cpu/armv7/exynos/clock_init_exynos5.c |   2 +-
  arch/arm/cpu/armv7/exynos/dmc_init_ddr3.c  |  29 +
  arch/arm/cpu/armv7/exynos/pinmux.c |   2 +-
  arch/arm/cpu/armv7/exynos/spl_boot.c   |  10 +-
  arch/arm/dts/Makefile  |   3 +-
  arch/arm/dts/exynos5800-peach-pi.dts   | 157 
 +
  arch/arm/include/asm/arch-exynos/cpu.h |  10 +-
  arch/arm/include/asm/arch-exynos/dmc.h |   1 +
  arch/arm/include/asm/arch-exynos/gpio.h|   4 +-
  board/samsung/smdk5420/Kconfig |  16 +++
  board/samsung/smdk5420/MAINTAINERS |   2 +
  configs/peach-pi_defconfig |   5 +
  include/configs/exynos5420-common.h|   9 +-
  include/configs/peach-pi.h |  50 
  include/configs/peach-pit.h|   8 +-
  include/configs/smdk5420.h |   4 +
  18 files changed, 313 insertions(+), 25 deletions(-)
  create mode 100644 arch/arm/dts/exynos5800-peach-pi.dts
  create mode 100644 configs/peach-pi_defconfig
  create mode 100644 include/configs/peach-pi.h
 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: OMAP5: DRA7xx: Enable I2C4 and I2C5 usage on the J6Eco EVM

[Lubomir Popov]

Hi Tom,

 On Fri, Nov 14, 2014 at 03:20:44PM +0200, Lubomir Popov wrote:

 On the J6Eco EVM we have two on-board devices on the I2C5 bus; this
 bus is also routed to the camera and expansion connectors. I2C4 is
 routed to one of the expansion connectors. This patch enables usage
 of these two buses.

 For I2C5 to work, the 'ARM: OMAP5: DRA7xx: Enable I2C5 operation'
 patch is required as a prerequisite.

 Tested on a J6 ECO EVM rev.B with a DRA726 ES1.0.

 Signed-off-by: Lubomir Popov l-po...@ti.com

 OK, but what's the usecase for enabling these in U-Boot?  Are we using
 things on these buses?

Both I2C4 and I2C5 are routed to expansion connectors on the J6Eco board.
If a customer has some add-on hardware with I2C devices attached through
these connectors, it seems useful to have the buses functional for bring-
up/debug. Moreover, the board itself has two devices on I2C5, one of them
being a GPIO expander driving some system configuration signals (e.g. for
override of the boot settings), and being able to control it could be
useful as well.

Best regards,
Lubo

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] sunxi: video: Add simplefb support

[Hans de Goede]

Hi,

On 11/17/2014 10:35 AM, Grant Likely wrote:
 On Sun, Nov 16, 2014 at 7:39 PM, Hans de Goede hdego...@redhat.com wrote:
 From: Luc Verhaegen l...@skynet.be

 Add simplefb support, note this depends on the kernel having support for
 the clocks property which has recently been added to the simplefb devicetree
 binding.

 Signed-off-by: Luc Verhaegen l...@skynet.be
 [hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
  disussed on the devicetree list]
 Signed-off-by: Hans de Goede hdego...@redhat.com
 
 I'm not a U-Boot maintainer, so take my comments with a grain of salt...
 
 This patch seems quite short sighted. The code that calculates and
 updates the simple framebuffer node addresses is pretty much going to
 be identical for all platforms. Why is sunxi open coding it?
 Particularly when there could be fiddly bits around dealing with
 #address-cells/#size-cells.
 
 I would think the code to update a simplefb node would be a common
 library function.

You're right I've spun it out into a generic helper function for the
next version of this patch-set.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PULL] u-boot-atmel/master - u-boot/master

[Tom Rini]

On Mon, Nov 17, 2014 at 01:35:20PM +0100, Andreas Bießmann wrote:

 Hi Tom,
 
 please pull u-boot-atmel/master into u-boot/master.
 
 Sorry for the huge patch-list. I accidentally pulled in u-boot-arm/master
 someday and pushed it. Unfortunately the pushed tree couldn't be deleted for
 good reasons. I'm so sorry for the mess.
 
 The following changes since commit 2086e388d56cbb0e3737a6276f04f00f74bf6723:
 
   Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-11-14 
 16:39:32 -0500)
 
 are available in the git repository at:
 
 
   git://git.denx.de/u-boot-atmel.git master

OK, this is a mess and just git pulling made things messier still.  I
took your branch into a new branch locally, rebased and now have:

f196044 ARM: atmel: add sama5d4 xplained ultra board support
927b901 ARM: atmel: add sama5d4ek board support
cabf61c net: macb: enable GMAC IP without GE feature support
7df4486 mtd: atmel_nand: runtime to build gf table for pmecc
5b15fd9 arm, spl, at91: add spl support for the corvus board
237e3793 arm, at91, spl: add spl support for the taurus board
5abc00d arm, spl, at91: add at91sam9260 and at91sam9g45 spl support
667af36 spl, mtd, nand, atmel_nand: invert device ready pin logic
4dfd360 spl, nand, atmel_nand: add erase one block function
c1ec406 mtd: atmel_nand: add missing include
0c3117b spl, nand: add option to boot raw u-boot.bin image only
bd1bb3c arm, at91: add missing ddr2 cr register MPDDRC_CR_EBISHARE define
7dd5891 arm, at91: compile mpddrc ram init code also for AT91SAM9M10G45
341f548 arm, at91, mpddrc: fix typo in ddr2_init()
50921cd arm, at91: add spi dataflash support for the taurus board
f11dea4 spi, atmel: move CONFIG_SYS_SPI_WRITE_TOUT into common header
c001486 arm, at91: generate boot.bin file for all atmel SoC
da79fa4 ARM: atmel: spl: make css field configurable
a5f35d6 ARM: atmel: spl: make initialization more stable
59158ba ARM: at91 series: convert to generic board
b2eff08 net: macb: write mac address when initialization

As what I've taken into master and build tested and pushed.  I think
you'll just need to git reset --hard and git push -f your tree to get it
back to a happy state.  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-sh/rmobile

[Tom Rini]

On Mon, Nov 17, 2014 at 01:28:02PM +0900, Nobuhiro Iwamatsu wrote:

 Dear Tom Rini.
 
 Please pull u-boot-sh rmobile branch.
 
 The following changes since commit 11ada9225a16ed2d8ddbf0715a2416245a777cbc:
 
   Merge branch 'rmobile' of git://www.denx.de/git/u-boot-sh
 (2014-11-05 13:11:18 -0500)
 
 are available in the git repository at:
 
git://git.denx.de/u-boot-sh.git rmobile
 
 for you to fetch changes up to 5ca6dfe6e7ede94fbdd711fa43aa58edace99b2b:
 
   arm: rmobile: replacement of common parts of config by
 rcar-gen2-common.h (2014-11-17 13:22:46 +0900)
 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-sh/master

[Tom Rini]

On Mon, Nov 17, 2014 at 01:32:59PM +0900, Nobuhiro Iwamatsu wrote:

 Dear Tom Rini.
 
 Please pull u-boot-sh master branch.
 
 The following changes since commit 11ada9225a16ed2d8ddbf0715a2416245a777cbc:
 
   Merge branch 'rmobile' of git://www.denx.de/git/u-boot-sh
 (2014-11-05 13:11:18 -0500)
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-sh.git master
 
 for you to fetch changes up to 570dd7f441c2d2d2e83a9345608801c92e7d2c6f:
 
   sh: Move SH_32BIT to Kconfig (2014-11-17 13:16:20 +0900)
 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

[Grant Likely]

On Sun, Nov 16, 2014 at 4:11 PM, Ian Campbell i...@hellion.org.uk wrote:
 On Sun, 2014-11-16 at 16:11 +0100, Hans de Goede wrote:
 On 11/16/2014 03:38 PM, Ian Campbell wrote:
  On Sun, 2014-11-16 at 14:52 +0100, Hans de Goede wrote:
  Hardcoding a path is deliberate. I don't know if you've read the
  previous u-boot code for this, but it did a lot of dt parsing to
  find clocks and add phandles to them, the way we eventually settled
  on when discussing this is for the dts to contain pre-populated simplefb
  nodes which u-boot just needs to fill with the mode info and enable, this
  way as we add support for more clocks (like the module clocks for the
  various display pipeline blocks), we don't need to update u-boot in 
  lock-step,
  we just add the clocks to the simplefb node in the dts file when they get
  added to the dts file in the first place. See the updated bindings.
 
  AFAICT this in no way invalidates what I suggested. There's no reason
  why the need to populate/tweak a pre-existing node should have anything
  to do with where the node is in the device-tree.

 Right, I forgot to add one important bit to my explanation, sorry, if
 you look at the binding then it says that the name should be suffixed
 with the output type, so currently the sunxi u-boot code will look for
 /chosen/framebuffer0-hdmi. Which will e.g. also happen on any A10
 based tablets which typically have both hdmi out and an lcd screen,
 in the future I hope we will also get lcd support in u-boot, and then
 logically on tablets the lcd screen would take precedence, so then
 unless overriden through some config mechanism u-boot will chose
 to use the lcd, and will look for /chosen/framebuffer0-lcd which has
 a different set of clocks then /chosen/framebuffer0-hdmi.

 This sounds like a use for:
 compatible = simple-framebuffer,hdmi, simple-framebuffer
 or some such, that's almost exactly what multiople compatible strings
 are for. Relying on specific naming and/or path is rather
 unconventional.

Indeed, for a long time now finding nodes by path has been strongly
discouraged. It makes it hard to move nodes around when needed. I'm
not going to make a big deal about it because it doesn't affect the OS
interface, but Ian's suggestion is sane. simple-framebuffer is enough
to identify the binding, but you can use additional strings to
identify the specific hardware interface that U-Boot can use to locate
the node. ie. sunxi,framebuffer-hdml or some such. You can never be
sure when someone will produce a board that messes with your naming
assumptions. What if is suddenly needs to be named framebuffer1-hdmi
because they added and FPGA that they want as framebuffer0? (Yes, I'm
making stuff up, but I have to think about the corner cases)

 The devicetree bindings have been going on for so long, that this
 would be the 2nd merge window this feature misses, Luc's original
 version was posted before the v2014.10 merge window.

 I'm afraid I don't agree that just because it has taken a long time to
 get something right we should commit to it before it is ready,
 especially when it is an ABI, which is what a DT binding is.

 If this scheme was acked by a DT maintainer then I'd be fine with it,
 but so far it hasn't been, at least not publicly in the threads I've
 looked at.

I /DO/ want comments though. Putting the node in /chosen is
unconventional. I want to hear if anyone has a good reason why the
framebuffers shouldn't be placed into /chosen.

 AFAIK Grant agrees with v5

 AFAIK Grant hasn't actually said that. If he does ack it (or if someone
 points me to the correct mail) then I have no further objections.

My word also isn't gospel. On controversial stuff I want to have
consensus. For the clock patches and had a long conversation with Rob
to make sure we were both in agreement before giving my final ack.

 In fact it's a bit odd to have a reg property under /chosen at all,
 since it doesn't really fit in with the bus structure. I've done
 something similar in some bindings I've authored[0], but AIUI I got that
 wrong and really should have used a set of non-reg properties with a
 single value so there was no need to parse using #*-cells  (cf the
 initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI,
 so for my bindings I'm kind of stuck with it for the foreseeable future.

 [0]
 http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD

Ironic isn't it that I though of that as precedence when I suggested
/chosen! :-)

I actually don't have a problem with it. We do need a way to specify
runtime memory usage, and /chosen is as good a place as any,
particularly when it represents things that won't necessarily be
relevant on kexec or dom0 boot.

The other options are under either the /memory or the /reserved-memory
tree. Rob and I talked about /reserved-memory quite a lot. We could
put all the framebuffer details into the memory 

Re: [U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ?

[Tom Rini]

On Thu, Nov 13, 2014 at 07:38:50PM +0100, Hans de Goede wrote:
 Hi,
 
 On 11/13/2014 07:34 PM, Tom Rini wrote:
  On Thu, Nov 13, 2014 at 07:08:59PM +0100, Hans de Goede wrote:
  Hi all,
 
  So as you know I've been working on getting mainline u-boot to boot the
  older android derived linux-sunxi kernels, as some people need features
  not yet in mainline, and I would like there to be only one u-boot for both.
 
  I had this working a while ago, but recently it broke, this is caused by
  config_distro_defaults.h setting CONFIG_OF_LIBFDT, if I undef that
  after including config_distro_defaults.h things work again.
 
  I do not know if CONFIG_OF_LIBFDT is a recent addition to 
  config_distro_defaults.h,
  or if something else broke things. But if I do not undef it, boot fails 
  with:
 
  sun7i# bootm start 0x4800
  ## Booting kernel from Legacy Image at 4800 ...
 Image Name:   Linux-3.4.75.sun7i+
 Image Type:   ARM Linux Kernel Image (uncompressed)
 Data Size:3966672 Bytes = 3.8 MiB
 Load Address: 40008000
 Entry Point:  40008000
 Verifying Checksum ... OK
  Could not find a valid device tree
  
  My hunch is that we've got more fall-out from Simon's re-org of the
  bootm code ages ago.  It should be valid to try and boot a kernel
  without a device tree and other parts of the code base (for example
  arch/arm/lib/bootm.c) still do a FDT-or-ATAGS dance for example.
 
 That is good news, because ideally upstream u-boot build with
 OLD_SUNXI_KERNEL_COMPAT should be able to boot old disk images without
 needing them to modify their boot.scr, which requiring bootm 0xfoo - -
 would do.
 
 So maybe check if there is a third argument to bootm, and if there
 is not still try the dance for finding one appended in various ways,
 and if that fails continue normally (where as with the third
 argument present this of course needs to stay an error) ?

So first, I have to take it back.  This isn't a behavior change
introduced by Simon's re-org (Sorry Simon!).  This is a real long
standing feature.   I am agreeable to doing whatever the lowest impact
change would be to allow a non-DT tree to boot with CONFIG_OF_LIBFDT
set.   I'm thinking we turn the error into a warning (so that it's still
clear to the user that they booted without a DT, for when they didn't
mean to do that) and instead of a hang we just don't do the follow-up
steps.  That should let all the existing scripts work, yes?

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Booting non devicetree enabled kernels using u-boot build with CONFIG_OF_LIBFDT ?

[Hans de Goede]

Hi,

On 11/17/2014 03:52 PM, Tom Rini wrote:
 On Thu, Nov 13, 2014 at 07:38:50PM +0100, Hans de Goede wrote:
 Hi,

 On 11/13/2014 07:34 PM, Tom Rini wrote:
 On Thu, Nov 13, 2014 at 07:08:59PM +0100, Hans de Goede wrote:
 Hi all,

 So as you know I've been working on getting mainline u-boot to boot the
 older android derived linux-sunxi kernels, as some people need features
 not yet in mainline, and I would like there to be only one u-boot for both.

 I had this working a while ago, but recently it broke, this is caused by
 config_distro_defaults.h setting CONFIG_OF_LIBFDT, if I undef that
 after including config_distro_defaults.h things work again.

 I do not know if CONFIG_OF_LIBFDT is a recent addition to 
 config_distro_defaults.h,
 or if something else broke things. But if I do not undef it, boot fails 
 with:

 sun7i# bootm start 0x4800
 ## Booting kernel from Legacy Image at 4800 ...
Image Name:   Linux-3.4.75.sun7i+
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:3966672 Bytes = 3.8 MiB
Load Address: 40008000
Entry Point:  40008000
Verifying Checksum ... OK
 Could not find a valid device tree

 My hunch is that we've got more fall-out from Simon's re-org of the
 bootm code ages ago.  It should be valid to try and boot a kernel
 without a device tree and other parts of the code base (for example
 arch/arm/lib/bootm.c) still do a FDT-or-ATAGS dance for example.

 That is good news, because ideally upstream u-boot build with
 OLD_SUNXI_KERNEL_COMPAT should be able to boot old disk images without
 needing them to modify their boot.scr, which requiring bootm 0xfoo - -
 would do.

 So maybe check if there is a third argument to bootm, and if there
 is not still try the dance for finding one appended in various ways,
 and if that fails continue normally (where as with the third
 argument present this of course needs to stay an error) ?
 
 So first, I have to take it back.  This isn't a behavior change
 introduced by Simon's re-org (Sorry Simon!).  This is a real long
 standing feature.   I am agreeable to doing whatever the lowest impact
 change would be to allow a non-DT tree to boot with CONFIG_OF_LIBFDT
 set.   I'm thinking we turn the error into a warning (so that it's still
 clear to the user that they booted without a DT, for when they didn't
 mean to do that)

I was thinking along the same lines, except that when a third argument
is explicitly given to u-boot, and then we do not find a dt, that should
be treated as an error IMHO. I've put whipping up a patch for this on my
todo list.

 and instead of a hang we just don't do the follow-up
 steps. 

Actually not doing the follow-up steps (as in bootm execution steps) is what
we currently do. What we want to do is skip further dt processing / prepping,
but otherwise still continue with trying to boot the kernel.

 That should let all the existing scripts work, yes?

With the amendments done above, I think so, yes. But the proof is in the
pudding, iow I'll find out when I go work on that patch.

Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/6] sunxi: video: Add simplefb support

[Grant Likely]

On Mon, Nov 17, 2014 at 10:14 AM, Ian Campbell i...@hellion.org.uk wrote:
 On Mon, 2014-11-17 at 09:58 +, Grant Likely wrote:
 I /DO/ want comments though. Putting the node in /chosen is
 unconventional. I want to hear if anyone has a good reason why the
 framebuffers shouldn't be placed into /chosen.

 I don't think putting it under /chosen is a problem at all. THe
 semantics of some of hte convention properties are a bit odd under
 there, but that's not insurmountable.

  AFAIK Grant agrees with v5
 
  AFAIK Grant hasn't actually said that. If he does ack it (or if someone
  points me to the correct mail) then I have no further objections.

 My word also isn't gospel.

 I suppose I should have said something like I trust Grant's judgement
 more than my own on things relating to DT ;-).

  On controversial stuff I want to have
 consensus. For the clock patches and had a long conversation with Rob
 to make sure we were both in agreement before giving my final ack.

  In fact it's a bit odd to have a reg property under /chosen at all,
  since it doesn't really fit in with the bus structure. I've done
  something similar in some bindings I've authored[0], but AIUI I got that
  wrong and really should have used a set of non-reg properties with a
  single value so there was no need to parse using #*-cells  (cf the
  initrd-start + initrd-end properties under /chosen). Sadly DT is an ABI,
  so for my bindings I'm kind of stuck with it for the foreseeable future.
 
  [0]
  http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt;h=08ed7751859dbe2d2c32d86d7df371057d7b45a4;hb=HEAD

 Ironic isn't it that I though of that as precedence when I suggested
 /chosen! :-)

 :-)

 I actually don't have a problem with it. We do need a way to specify
 runtime memory usage, and /chosen is as good a place as any,
 particularly when it represents things that won't necessarily be
 relevant on kexec or dom0 boot.

 The main issue which was explained to me with my Xen bindings was that
 reg =  isn't all that meaningful under /chosen because it doesn't fit
 into the bus structure, so the #address-/size-cells stuff gets a bit
 strange. It's probably tolerable for things which are strictly physical
 RAM addresses (as opposed to mmio) since RAM isn't typically behind a
 visible bus.

 The scheme used for initrds sidesteps all those issues by using separate
 (multicellular) properties for the start and end regions and not using
 reg= and therefore naturally breaking the expected semantic link with
 bus topology which reg implies etc.

I quite dislike the initrd multi-property approach. It has to be
parsed in a completely separate way.

 The other options are under either the /memory or the /reserved-memory
 tree. Rob and I talked about /reserved-memory quite a lot. We could
 put all the framebuffer details into the memory node that reserves the
 framebuffer. However, I don't like that idea because it kind of makes
 assumptions about how the framebuffer will be located inside the
 memory region and doesn't allow for multiple framebuffers within a
 single region.

 Yes, that sounds strictly worse than the current solution to me.

Besides, the simple-framebuffer binding could easily be extended to
allow a reserved-memory reference instead of a reg property if/when
that becomes a better option for a specific platform.

g.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] SPI: Add S25FL164K flash identifier info

[Ben Dooks]

Add the necessary flash entry for the Spansion S25FL164K
flash. Tested on Marvell 88F6218 based design.

Signed-off-by: Ben Dooks ben.do...@codethink.co.uk
---
 drivers/mtd/spi/sf_params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 462e5c2..c1f243b 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -53,6 +53,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{S25FL064A,  0x010216, 0x0,   64 * 1024,   128,   0,  
  0},
{S25FL064A,  0x010216, 0x0,   64 * 1024,   128,   0,  
  0},
{S25FL116k,  0x014015, 0x0,   64 * 1024,   128,   0,  
  0},
+   {S25FL164K,  0x014017, 0x0140,64 * 1024,   128,   0,  
  0},
{S25FL128P_256K, 0x012018, 0x0300,   256 * 1024,64, RD_FULL,  
 WR_QPP},
{S25FL128P_64K,  0x012018, 0x0301,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{S25FL032P,  0x010215, 0x4d00,64 * 1024,64, RD_FULL,  
 WR_QPP},
-- 
2.1.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] SPI flash ID patches

[Ben Dooks]

These are a pair of patches adding some SPI flashes that were evaluated
on a Marvell Kirkwood system.

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] SPI: Add S25FL064A and S25FL116K flash information

[Ben Dooks]

From: Adnan Ali adnan@codethink.co.uk

Add S25FL064A and S25FL116K flash indentifiers.

Signed-off-by: Adnan Ali adnan@codethink.co.uk
---
 drivers/mtd/spi/sf_params.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 61545ca..462e5c2 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -51,6 +51,8 @@ const struct spi_flash_params spi_flash_params_table[] = {
{S25FL016A,  0x010214, 0x0,   64 * 1024,32,   0,  
  0},
{S25FL032A,  0x010215, 0x0,   64 * 1024,64,   0,  
  0},
{S25FL064A,  0x010216, 0x0,   64 * 1024,   128,   0,  
  0},
+   {S25FL064A,  0x010216, 0x0,   64 * 1024,   128,   0,  
  0},
+   {S25FL116k,  0x014015, 0x0,   64 * 1024,   128,   0,  
  0},
{S25FL128P_256K, 0x012018, 0x0300,   256 * 1024,64, RD_FULL,  
 WR_QPP},
{S25FL128P_64K,  0x012018, 0x0301,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{S25FL032P,  0x010215, 0x4d00,64 * 1024,64, RD_FULL,  
 WR_QPP},
-- 
2.1.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 0/2] sunxi: video: Add simplefb support

[Hans de Goede]

Hi All,

Here is v4 of my sunxi simplefb support set.

Changes since v3:
-Added a fdt_setup_simplefb_node() helper function (new patch)
-Changed how u-boot finds the pre-populated simplefb node to use a
 compatible string

Changes since v2:
-Detect and handle address and size #cells

Changes since v1:
-Use fdt_setprop_string for strings

Simon, can you review and ack the fdt_setup_simplefb_node() helper function
patch please ? Since it is a dep. for sunxi patches I would like to take it
upstream through the sunxi tree, but for obvious reasons I would also like
your ack on this.

Ian, I hope the sunxi specific patch is now more to your liking, please
re-review. Also can you please review v2 of:

-sunxi: video: Add cfb console driver for sunxi
 You've already reviewed and acked v1, v2 only has some Kconfig changes

-sunxi: Add usb keyboard Kconfig option
 Kconfig changes / fixes as discussed

You should have these in your mailbox, if not see patchwork.

Thanks  Regards,

Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 2/2] sunxi: video: Add simplefb support

[Hans de Goede]

From: Luc Verhaegen l...@skynet.be

Add simplefb support, note this depends on the kernel having support for
the clocks property which has recently been added to the simplefb devicetree
binding.

Signed-off-by: Luc Verhaegen l...@skynet.be
[hdego...@redhat.com: Use pre-populated simplefb node under /chosen as
 disussed on the devicetree list]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/include/asm/arch-sunxi/display.h |  4 
 board/sunxi/board.c   | 11 +
 drivers/video/sunxi_display.c | 39 +++
 include/configs/sunxi-common.h|  8 +++
 4 files changed, 62 insertions(+)

diff --git a/arch/arm/include/asm/arch-sunxi/display.h 
b/arch/arm/include/asm/arch-sunxi/display.h
index 8d80ceb..4c694f8 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -195,4 +195,8 @@ struct sunxi_hdmi_reg {
 #define SUNXI_HDMI_PLL_DBG0_PLL3   (0  21)
 #define SUNXI_HDMI_PLL_DBG0_PLL7   (1  21)
 
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+void sunxi_simplefb_setup(void *blob);
+#endif
+
 #endif /* _SUNXI_DISPLAY_H */
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index e6ec5b8..d4530e8 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -24,6 +24,7 @@
 #endif
 #include asm/arch/clock.h
 #include asm/arch/cpu.h
+#include asm/arch/display.h
 #include asm/arch/dram.h
 #include asm/arch/gpio.h
 #include asm/arch/mmc.h
@@ -237,3 +238,13 @@ int misc_init_r(void)
return 0;
 }
 #endif
+
+#ifdef CONFIG_OF_BOARD_SETUP
+void
+ft_board_setup(void *blob, bd_t *bd)
+{
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+   sunxi_simplefb_setup(blob);
+#endif
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
diff --git a/drivers/video/sunxi_display.c b/drivers/video/sunxi_display.c
index 3f46c31..74c4bd3 100644
--- a/drivers/video/sunxi_display.c
+++ b/drivers/video/sunxi_display.c
@@ -13,6 +13,8 @@
 #include asm/arch/display.h
 #include asm/global_data.h
 #include asm/io.h
+#include fdtdec.h
+#include fdt_support.h
 #include linux/fb.h
 #include video_fb.h
 
@@ -416,3 +418,40 @@ video_hw_init(void)
 
return graphic_device;
 }
+
+/*
+ * Simplefb support.
+ */
+#if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_VIDEO_DT_SIMPLEFB)
+void
+sunxi_simplefb_setup(void *blob)
+{
+   static GraphicDevice *graphic_device = sunxi_display.graphic_device;
+   int offset, ret;
+
+   if (!sunxi_display.enabled)
+   return;
+
+   /* Find a framebuffer node, with pipeline == de_be0-lcd0-hdmi */
+   offset = fdt_node_offset_by_compatible(blob, -1, sunxi,framebuffer);
+   while (offset = 0) {
+   ret = fdt_find_string(blob, offset, sunxi,pipeline,
+ de_be0-lcd0-hdmi);
+   if (ret == 0)
+   break;
+   offset = fdt_node_offset_by_compatible(blob, offset,
+  sunxi,framebuffer);
+   }
+   if (offset  0) {
+   eprintf(Cannot setup simplefb: node not found\n);
+   return;
+   }
+
+   ret = fdt_setup_simplefb_node(blob, offset, gd-fb_base,
+   graphic_device-winSizeX, graphic_device-winSizeY,
+   graphic_device-winSizeX * graphic_device-gdfBytesPP,
+   x8r8g8b8);
+   if (ret  0)
+   eprintf(Cannot setup simplefb: Error setting properties\n);
+}
+#endif /* CONFIG_OF_BOARD_SETUP  CONFIG_VIDEO_DT_SIMPLEFB */
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 900ef52..d5d907b 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -204,6 +204,9 @@
  */
 #define CONFIG_SUNXI_FB_SIZE (8  20)
 
+/* Do we want to initialize a simple FB? */
+#define CONFIG_VIDEO_DT_SIMPLEFB
+
 #define CONFIG_VIDEO_SUNXI
 
 #define CONFIG_CFB_CONSOLE
@@ -217,6 +220,11 @@
 
 #define CONFIG_SYS_MEM_TOP_HIDE ((CONFIG_SUNXI_FB_SIZE + 0xFFF)  ~0xFFF)
 
+/* To be able to hook simplefb into dt */
+#ifdef CONFIG_VIDEO_DT_SIMPLEFB
+#define CONFIG_OF_BOARD_SETUP
+#endif
+
 #endif /* CONFIG_VIDEO */
 
 /* Ethernet support */
-- 
2.1.0

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. Hangs on START_CHAR

[Wolfgang Denk]

Dear Bo,

In message 1416231868926-196549.p...@n7.nabble.com you wrote:
 
 I keep coming back to the fact that loads works fine in 115200 baud, but
 loadb does not.

This is the funny part of it.

 If there is indeed a timing issue, it must be some handshaking in the Kermit
 protocol, right? The loads command just absorbs data as it is transferred,
 but the loadb command, using Kermit, tries to speed up the transfer by
 adjusting packet size according to crc-errors.

But you don't even get there. You write you get stuck at the
START_CHAR - eventually there is a bug in the serial driver or even
in the hardware, such that it is not really 8 bit clean, or enables
parity or such.  loads s just an ASCII text transfer, i. e. it works
fine when you get only 7 data bits through.  loadb will really need
an 8 bit clean link.

 I am a bit baffled as you can imagine.

Me too.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Use the Force, Luke.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] 85xx/b4860: Add alternate serdes protocols for B4860/B4420

[York Sun]

On 11/12/2014 02:32 AM, Shaveta Leekha wrote:
 Addded Alternate options with LC VCO for following protocols:
 0x02 -- 0x01
 0x08 -- 0x07
 0x18 -- 0x17
 0x1E -- 0x1D
 0x49 -- 0x48
 0x6F -- 0x6E
 0x9A -- 0x99
 0x9E -- 0x9D
 
 Signed-off-by: Shaveta Leekha shav...@freescale.com
 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
 Change-Id: Iefe14012ee897095f0198453d50f31096ca020e2
 Reviewed-on: http://git.am.freescale.net:8181/23352
 Tested-by: Review Code-CDREVIEW cdrev...@freescale.com
 Reviewed-by: Yusong Sun york...@freescale.com
 ---

First, you should remove internal review information when you send patches to
this mailing list. Please do so from for your next patch.

Second, when you resend or update the patches, please add a change log and
update the version number.

York

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] loadb problem. (was: Hangs on START_CHAR)

[bomellberg]

Sorry for the confusion. Using an rs232 sniffer I found that the Start_char
IS sent to the PC, see some posts ago.

Fyi, loady also works. It types 'C' every 4 seconds until I start the
ymodem transfer, and then it uploads the code ok.

When using loadb, I can see on the scope that data is being sent, and that
the board answers. The PC does not seem happy with the answer though,
because it sends the first packet over and over.



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/loadb-problem-Hangs-on-START-CHAR-tp195144p196574.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property

[Simon Glass]

Hi Masahiro,

On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 The driver model provides two ways to pass the device information,
 platform data and device tree.  Either way works to bind devices and
 drivers, but there is inconsistency in terms of how to pass the
 pre-reloc flag.

 In the platform data way, the pre-reloc DM scan checks if each driver
 has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F
 just before).  That is, each **driver** has the pre-reloc attribute.

 In the device tree control, the existence of u-boot,dm-pre-reloc is
 checked for each device node.  The driver flag DM_FLAG_PRE_RELOC is
 never checked.  That is, each **device** owns the pre-reloc attribute.

 Drivers should generally work both with platform data and device tree,
 but this inconsistency has made our life difficult.

I feel we should use device tree where available, and only fall back
to platform data when necessary (no device tree available for
platform, for example).


 This commit abolishes u-boot,dm-pre-reloc property because:

  - Having a U-Boot specific property makes it difficult to share the
device tree sources between Linux and U-Boot.

  - The number of devices is generally larger than that of drivers.
Each driver often has multiple devices with different base
addresses.  It seems more reasonable to add the pre-reloc attribute
to drivers than devices.

The inability for platform data to specify which devices need to be
pre-relocation is certainly a limitation. But I'm not sure that the
solution is to remove that feature from the device tree. Prior to
relocation memory may be severely limited. Things like GPIO and serial
can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for
serial), but only a subset may be needed before relocation (on Tegra
only 2!).

I'm actually pretty comfortable with platform data having a limited
subset of functionality, since I believe most platforms will use
device tree for one reason or another.

Thoughts?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] How to get #address-cells in U-Boot?

[Simon Glass]

Hi Masahiro,

On 17 November 2014 11:02, Masahiro Yamada yamad...@jp.panasonic.com wrote:

 Hi.

 
  Another question.
 
  Can U-boot handle the address transformation?
 
  If the upper bus node has ranges property,
  it must also be checked to get the correct base address, I think.


 I take this question back too.
 Sorry for noise.

OK no problem! Also see fdt_address_cells() and fdt_size_cells() which
are in libfdt now.

- Simon




 
  On Mon, 17 Nov 2014 19:38:41 +0900
  Masahiro Yamada yamad...@jp.panasonic.com wrote:
 
   Hi.
  
  
   I want to decode the base address of device nodes of my device trees.
  
   For example, drivers/serial/ns16550.c uses fdtdec_get_addr() function
   to decode the reg property, but it is not very nice because
   it does not check #address-cells.
  
   Precisely, we need to check the parent node to get #address-cells.
   (If the parent does not have it, we need to search for it towards the 
   root node.)
  
  
   I am looking for something like of_n_addr_cells() and of_n_size_cells() 
   functions
   of Linux Kernel.
  
  
   I don't think it is feasible in U-Boot because
   U-Boot handles device tree blobs as they are (as flattened binaries).
  
   If we want to get properties of the parenet node, we must parse the DTB 
   from the
   beginning.  Yes, U-Boot actually parses the same DTB over and over again.
  
   Any advice?   Import drivers/of/* from Linux??
  
  
  
   Simon, do you have any good idea to solve this problem by DM?
   For example, add address_cells and size_cells members to struct 
   udevice
   and then  modify drivers/core/simple-bus.c to parse #address-cells and 
   #size-cells
   and pass them to children.
  
  
 
  ___
  U-Boot mailing list
  U-Boot@lists.denx.de
  http://lists.denx.de/mailman/listinfo/u-boot


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8] dm: core: remove meaningless if conditional

[Simon Glass]

Hi Masahiro,

On 17 November 2014 11:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Hi Simon,



 On Mon, 17 Nov 2014 09:14:15 +
 Simon Glass s...@chromium.org wrote:

 Hi Masahiro,

 On 17 November 2014 08:19, Masahiro Yamada yamad...@jp.panasonic.com wrote:
  If the variable ret is equal to -ENOENT, it is trapped at [1] and
  never reaches [2].  At [3], the condition ret != -ENOENT is always
  true.
 
if (ret == -ENOENT) {   -- [1]
continue;
} else if (ret == -ENODEV) {
dm_dbg(Device '%s' has no compatible string\n, name);
break;
} else if (ret) {   -- [2]
dm_warn(Device tree error at offset %d\n, offset);
if (!result || ret != -ENOENT)  -- [3]
result = ret;
break;
}
 
  Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
  ---
 
   drivers/core/lists.c | 3 +--
   1 file changed, 1 insertion(+), 2 deletions(-)
 
  diff --git a/drivers/core/lists.c b/drivers/core/lists.c
  index 3a1ea85..0aad56d 100644
  --- a/drivers/core/lists.c
  +++ b/drivers/core/lists.c
  @@ -136,8 +136,7 @@ int lists_bind_fdt(struct udevice *parent, const void 
  *blob, int offset,
  break;
  } else if (ret) {
  dm_warn(Device tree error at offset %d\n, 
  offset);
  -   if (!result || ret != -ENOENT)
  -   result = ret;
  +   result = ret;

 Thanks for the clear explanation.
 It looks good, except my intent was to return the first error, hence
 the 'if (!result ...'.

 Your code will return the last error. Can we preserve the current bahaviour?


 Do you mean, like this?

dm_warn(Device tree error at offset %d\n, offset);
if (!result)
result = ret;
break;


 I think there is no difference in the behaviour, because
 this for loop is escaped out at the first encounter with an error
 except -ENOENT.

 Here is the only line to set result and it is followed by break statement,
 so the last error is also the first error, I think.

Ah yes, OK. The intent here is to provide a useful error message
without adding a lot of noise. It's a bit of a pain but we should keep
it I think. Your patch looks good.

Acked-by: Simon Glass s...@chromium.org

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/8] dm: core: look up drivers more efficiently

[Simon Glass]

Hi Masahiro,

On 17 November 2014 11:49, Masahiro Yamada yamad...@jp.panasonic.com wrote:
 Hi Simon,


 On Mon, 17 Nov 2014 09:22:19 +
 Simon Glass s...@chromium.org wrote:
  --- a/drivers/core/device.c
  +++ b/drivers/core/device.c
  @@ -157,11 +157,9 @@ int device_bind_by_name(struct udevice *parent, bool 
  pre_reloc_only,
   {
  struct driver *drv;
 
  -   drv = lists_driver_lookup_name(info-name);
  +   drv = __lists_driver_lookup_name(info-name, pre_reloc_only);

 This patch looks good, except that I would prefer
 lists_driver_lookup_name_prereloc() to __lists_driver_lookup_name().
 The __ seems like an internal compiler name to me. So can you rename
 it?

 Indeed. I think __ should be used carefully especially when it comes to
 host programs, but I think we can play it by ear in standalone binaries
 such as the kernel and U-boot code.

 I often see __ prefixes in Linux and in my understanding,
 __foo() is a use it carefully version or locally used interface of foo()
 (for example, when the resources are not protected by spinlocks, etc.).
 So, I often use it when I cannot invent a good func name.

 Hmm, lists_driver_lookup_name_prereloc() is already too long
 and __prereloc is a bit misleading because it is used both before and after 
 relocation,
 isn't it?

OK that seems fair enough if used sparingly. I can't think of a great
name either and we don't really want to pollute the code with the
pre_reloc_only parameter since it will be used in many places.

Acked-by: Simon Glass s...@chromium.org

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/30] power: Add AMS AS3722 PMIC support

[Simon Glass]

Hi Thierry,

On 17 November 2014 10:04, Thierry Reding tred...@nvidia.com wrote:
 On Wed, Nov 12, 2014 at 06:26:51PM -0700, Simon Glass wrote:
 [...]
 diff --git a/drivers/power/as3722.c b/drivers/power/as3722.c
 [...]
 +int as3722_init(struct udevice **devp)
 +{
 + struct udevice *pmic;
 + u8 id, revision;
 + int bus = 0;
 + int address = 0x40;

 Is there a reason for bus and address to not be unsigned? I also take it
 that the plan is to eventually query these from the udevice/DT once I2C
 has been converted to DM?

They can be unsigned but I didn't think it was important. They should
probably be const too...

This does in fact use DM for I2C - I place this series on top of the
I2C series. I'm going to give it a few more days for people like
you/Tom/Stephen to take a look at the Tegra DM conversion for I2C,
then I'll bring it through the DM tree, and likely this series too,
after fixing the nits.

The near-term plan is to use the PMIC support when it moves to DM. But
for now this is pretty clean.

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot