[U-Boot] [PATCH] ARM: dts: uniphier: rework System Bus nodes

2016-02-16 Thread Masahiro Yamada
Follow the changes of DTS in Linux.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-common32.dtsi | 19 ++-
 arch/arm/dts/uniphier-ph1-sld3.dtsi | 20 ++--
 2 files changed, 20 insertions(+), 19 deletions(-)

diff --git a/arch/arm/dts/uniphier-common32.dtsi 
b/arch/arm/dts/uniphier-common32.dtsi
index 59511bd..7d59112 100644
--- a/arch/arm/dts/uniphier-common32.dtsi
+++ b/arch/arm/dts/uniphier-common32.dtsi
@@ -23,12 +23,6 @@
ranges;
interrupt-parent = <&intc>;
 
-   extbus: extbus {
-   compatible = "simple-bus";
-   #address-cells = <2>;
-   #size-cells = <1>;
-   };
-
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
@@ -69,9 +63,16 @@
clocks = <&uart_clk>;
};
 
-   system-bus-controller@58c0 {
-   compatible = "socionext,uniphier-system-bus-controller";
-   reg = <0x58c0 0x400>, <0x5980 0x2000>;
+   system_bus: system-bus@58c0 {
+   compatible = "socionext,uniphier-system-bus";
+   reg = <0x58c0 0x400>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
+
+   smpctrl@5980 {
+   compatible = "socionext,uniphier-smpctrl";
+   reg = <0x59801000 0x400>;
};
 
mio: mioctrl@5981 {
diff --git a/arch/arm/dts/uniphier-ph1-sld3.dtsi 
b/arch/arm/dts/uniphier-ph1-sld3.dtsi
index 85dde66..e01bd30 100644
--- a/arch/arm/dts/uniphier-ph1-sld3.dtsi
+++ b/arch/arm/dts/uniphier-ph1-sld3.dtsi
@@ -62,12 +62,6 @@
ranges;
interrupt-parent = <&intc>;
 
-   extbus: extbus {
-   compatible = "simple-bus";
-   #address-cells = <2>;
-   #size-cells = <1>;
-   };
-
timer@2200 {
compatible = "arm,cortex-a9-global-timer";
reg = <0x2200 0x20>;
@@ -172,10 +166,16 @@
clock-frequency = <40>;
};
 
-   system-bus-controller-misc@5980 {
-   compatible = 
"socionext,uniphier-system-bus-controller-misc",
-"syscon";
-   reg = <0x5980 0x2000>;
+   system_bus: system-bus@58c0 {
+   compatible = "socionext,uniphier-system-bus";
+   reg = <0x58c0 0x400>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   };
+
+   smpctrl@5980 {
+   compatible = "socionext,uniphier-smpctrl";
+   reg = <0x59801000 0x400>;
};
 
mio: mioctrl@5981 {
-- 
1.9.1

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


[U-Boot] [PATCH v4 4/4] ARM: dts: uniphier: add GPIO controller nodes

2016-02-16 Thread Masahiro Yamada
Make the GPIO driver really active.

Signed-off-by: Masahiro Yamada 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/dts/uniphier-ph1-ld4.dtsi | 112 ++
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 203 +
 arch/arm/dts/uniphier-ph1-pro5.dtsi| 203 +
 arch/arm/dts/uniphier-ph1-sld3.dtsi| 112 ++
 arch/arm/dts/uniphier-ph1-sld8.dtsi| 112 ++
 arch/arm/dts/uniphier-proxstream2.dtsi | 196 +++
 6 files changed, 938 insertions(+)

diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index 7c8759f..f13c6db 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -56,6 +56,118 @@
cache-level = <2>;
};
 
+   port0x: gpio@5508 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5508 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port1x: gpio@5510 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5510 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port2x: gpio@5518 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5518 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port3x: gpio@5520 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5520 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port4: gpio@5528 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5528 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port5x: gpio@5530 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5530 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port6x: gpio@5538 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5538 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port7x: gpio@5540 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5540 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port8x: gpio@5548 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5548 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port9x: gpio@5550 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5550 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port10x: gpio@5558 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5558 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port11x: gpio@5560 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5560 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port12x: gpio@5568 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5568 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port13x: gpio@5570 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5570 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port14x: gpio@5578 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5578 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port16x: gpio@5588 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5588 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
i2c0: i2c@5840 {
compatible = "socionext,uniphier-i2c";
status = "disabled";
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index cb5b8f1..6637aea 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -64,6 +64,209 @@
cache-level = <2>;
};
 
+   port0x: gpio@5508 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5508 0x8>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   port1x: gpio@5510 {
+   compatible = "socionext,uniphier-gpio";
+   reg = <0x5510 0x8>;
+   gpio-controller;
+   #g

[U-Boot] [PATCH v4 1/4] gpio: uniphier: add driver for UniPhier GPIO controller

2016-02-16 Thread Masahiro Yamada
This GPIO controller device is used on UniPhier SoCs.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass 
---

Changes in v4:
  - set uc_priv->bank_name

Changes in v3:
  - one gpio bank per register

Changes in v2:
  - Do not use "ngpio" property to specify the number of GPIO pins.
Instead, use .data field of OF match table.

 drivers/gpio/Kconfig |   6 ++
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-uniphier.c | 147 +++
 3 files changed, 154 insertions(+)
 create mode 100644 drivers/gpio/gpio-uniphier.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 845dc72..94fabb9 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -76,6 +76,12 @@ config SANDBOX_GPIO_COUNT
  of 'anonymous' GPIOs that do not belong to any device or bank.
  Select a suitable value depending on your needs.
 
+config GPIO_UNIPHIER
+   bool "UniPhier GPIO"
+   depends on ARCH_UNIPHIER
+   help
+ Say yes here to support UniPhier GPIOs.
+
 config VYBRID_GPIO
bool "Vybrid GPIO driver"
depends on DM
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 845a6d4..ca8c487 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -43,6 +43,7 @@ oby-$(CONFIG_SX151X)  += sx151x.o
 obj-$(CONFIG_SUNXI_GPIO)   += sunxi_gpio.o
 obj-$(CONFIG_LPC32XX_GPIO) += lpc32xx_gpio.o
 obj-$(CONFIG_STM32_GPIO)   += stm32_gpio.o
+obj-$(CONFIG_GPIO_UNIPHIER)+= gpio-uniphier.o
 obj-$(CONFIG_ZYNQ_GPIO)+= zynq_gpio.o
 obj-$(CONFIG_VYBRID_GPIO)  += vybrid_gpio.o
 obj-$(CONFIG_HIKEY_GPIO)   += hi6220_gpio.o
diff --git a/drivers/gpio/gpio-uniphier.c b/drivers/gpio/gpio-uniphier.c
new file mode 100644
index 000..80bb16e
--- /dev/null
+++ b/drivers/gpio/gpio-uniphier.c
@@ -0,0 +1,147 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNIPHIER_GPIO_PORTS_PER_BANK   8
+
+#define UNIPHIER_GPIO_REG_DATA 0   /* data */
+#define UNIPHIER_GPIO_REG_DIR  4   /* direction (1:in, 0:out) */
+
+struct uniphier_gpio_priv {
+   void __iomem *base;
+   char bank_name[16];
+};
+
+static void uniphier_gpio_offset_write(struct udevice *dev, unsigned offset,
+  unsigned reg, int value)
+{
+   struct uniphier_gpio_priv *priv = dev_get_priv(dev);
+   u32 tmp;
+
+   tmp = readl(priv->base + reg);
+   if (value)
+   tmp |= BIT(offset);
+   else
+   tmp &= ~BIT(offset);
+   writel(tmp, priv->base + reg);
+}
+
+static int uniphier_gpio_offset_read(struct udevice *dev, unsigned offset,
+unsigned reg)
+{
+   struct uniphier_gpio_priv *priv = dev_get_priv(dev);
+
+   return !!(readl(priv->base + reg) & BIT(offset));
+}
+
+static int uniphier_gpio_direction_input(struct udevice *dev, unsigned offset)
+{
+   uniphier_gpio_offset_write(dev, offset, UNIPHIER_GPIO_REG_DIR, 1);
+
+   return 0;
+}
+
+static int uniphier_gpio_direction_output(struct udevice *dev, unsigned offset,
+ int value)
+{
+   uniphier_gpio_offset_write(dev, offset, UNIPHIER_GPIO_REG_DATA, value);
+   uniphier_gpio_offset_write(dev, offset, UNIPHIER_GPIO_REG_DIR, 0);
+
+   return 0;
+}
+
+static int uniphier_gpio_get_value(struct udevice *dev, unsigned offset)
+{
+   return uniphier_gpio_offset_read(dev, offset, UNIPHIER_GPIO_REG_DATA);
+}
+
+static int uniphier_gpio_set_value(struct udevice *dev, unsigned offset,
+  int value)
+{
+   uniphier_gpio_offset_write(dev, offset, UNIPHIER_GPIO_REG_DATA, value);
+
+   return 0;
+}
+
+static int uniphier_gpio_get_function(struct udevice *dev, unsigned offset)
+{
+   return uniphier_gpio_offset_read(dev, offset, UNIPHIER_GPIO_REG_DIR) ?
+   GPIOF_INPUT : GPIOF_OUTPUT;
+}
+
+static const struct dm_gpio_ops uniphier_gpio_ops = {
+   .direction_input= uniphier_gpio_direction_input,
+   .direction_output   = uniphier_gpio_direction_output,
+   .get_value  = uniphier_gpio_get_value,
+   .set_value  = uniphier_gpio_set_value,
+   .get_function   = uniphier_gpio_get_function,
+};
+
+static int uniphier_gpio_probe(struct udevice *dev)
+{
+   struct uniphier_gpio_priv *priv = dev_get_priv(dev);
+   struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev);
+   DECLARE_GLOBAL_DATA_PTR;
+   fdt_addr_t addr;
+   fdt_size_t size;
+   unsigned int tmp;
+
+   addr = fdtdec_get_addr_size(gd->fdt_blob, dev->of_offset, "reg",
+   &size);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->base = map_sysmem(ad

[U-Boot] [PATCH v4 2/4] gpio: do not include for UniPhier

2016-02-16 Thread Masahiro Yamada
I implemented a GPIO driver based on Driver Model for the UniPhier
SoC family, but I could not find any good reason why such SoC
specific GPIO headers are needed.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/include/asm/gpio.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/include/asm/gpio.h b/arch/arm/include/asm/gpio.h
index d49ad08..fe4419c 100644
--- a/arch/arm/include/asm/gpio.h
+++ b/arch/arm/include/asm/gpio.h
@@ -1,2 +1,4 @@
+#ifndef CONFIG_ARCH_UNIPHIER
 #include 
+#endif
 #include 
-- 
1.9.1

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


[U-Boot] [PATCH v4 3/4] ARM: uniphier: enable GPIO command and driver for UniPhier SoCs

2016-02-16 Thread Masahiro Yamada
This allows to use the "gpio" command.

Signed-off-by: Masahiro Yamada 
Acked-by: Simon Glass 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 arch/arm/Kconfig | 1 +
 configs/uniphier_ld4_sld8_defconfig  | 2 ++
 configs/uniphier_pro4_defconfig  | 2 ++
 configs/uniphier_pro5_defconfig  | 2 ++
 configs/uniphier_pxs2_ld6b_defconfig | 2 ++
 configs/uniphier_sld3_defconfig  | 2 ++
 6 files changed, 11 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d8b63e9..94bd7ec 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -697,6 +697,7 @@ config ARCH_UNIPHIER
select SPL_OF_CONTROL
select DM
select SPL_DM
+   select DM_GPIO
select DM_SERIAL
select DM_I2C
help
diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index 535f96f..dbee08e 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -13,12 +13,14 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
+CONFIG_GPIO_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index 2361db6..3c2f7b0 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -12,12 +12,14 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
+CONFIG_GPIO_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pro5_defconfig b/configs/uniphier_pro5_defconfig
index be0d7b5..cf5f1ce 100644
--- a/configs/uniphier_pro5_defconfig
+++ b/configs/uniphier_pro5_defconfig
@@ -12,12 +12,14 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
+CONFIG_GPIO_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pxs2_ld6b_defconfig 
b/configs/uniphier_pxs2_ld6b_defconfig
index f8cb794..00a2900 100644
--- a/configs/uniphier_pxs2_ld6b_defconfig
+++ b/configs/uniphier_pxs2_ld6b_defconfig
@@ -13,12 +13,14 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
+CONFIG_GPIO_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig
index e369c45..013fc8a 100644
--- a/configs/uniphier_sld3_defconfig
+++ b/configs/uniphier_sld3_defconfig
@@ -11,11 +11,13 @@ CONFIG_CMD_NAND=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_FPGA is not set
+CONFIG_CMD_GPIO=y
 CONFIG_CMD_TFTPPUT=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
+CONFIG_GPIO_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
-- 
1.9.1

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


[U-Boot] [PATCH v4 0/4] UniPhier: add GPIO support

2016-02-16 Thread Masahiro Yamada


Changes in v4:
  - set uc_priv->bank_name

Changes in v3:
  - one gpio bank per register

Changes in v2:
  - Do not use "ngpio" property to specify the number of GPIO pins.
Instead, use .data field of OF match table.

Masahiro Yamada (4):
  gpio: uniphier: add driver for UniPhier GPIO controller
  gpio: do not include  for UniPhier
  ARM: uniphier: enable GPIO command and driver for UniPhier SoCs
  ARM: dts: uniphier: add GPIO controller nodes

 arch/arm/Kconfig   |   1 +
 arch/arm/dts/uniphier-ph1-ld4.dtsi | 112 ++
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 203 +
 arch/arm/dts/uniphier-ph1-pro5.dtsi| 203 +
 arch/arm/dts/uniphier-ph1-sld3.dtsi| 112 ++
 arch/arm/dts/uniphier-ph1-sld8.dtsi| 112 ++
 arch/arm/dts/uniphier-proxstream2.dtsi | 196 +++
 arch/arm/include/asm/gpio.h|   2 +
 configs/uniphier_ld4_sld8_defconfig|   2 +
 configs/uniphier_pro4_defconfig|   2 +
 configs/uniphier_pro5_defconfig|   2 +
 configs/uniphier_pxs2_ld6b_defconfig   |   2 +
 configs/uniphier_sld3_defconfig|   2 +
 drivers/gpio/Kconfig   |   6 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-uniphier.c   | 147 
 16 files changed, 1105 insertions(+)
 create mode 100644 drivers/gpio/gpio-uniphier.c

-- 
1.9.1

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


[U-Boot] [PATCH v3 2/3] ARM: uniphier: enable UniPhier SD/MMC host driver

2016-02-16 Thread Masahiro Yamada
Enable the driver in all UniPhier defconfig files and add some
needed defines to the common files.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 arch/arm/Kconfig | 1 +
 configs/uniphier_ld4_sld8_defconfig  | 1 +
 configs/uniphier_pro4_defconfig  | 1 +
 configs/uniphier_pro5_defconfig  | 1 +
 configs/uniphier_pxs2_ld6b_defconfig | 1 +
 configs/uniphier_sld3_defconfig  | 1 +
 include/configs/uniphier.h   | 4 
 7 files changed, 10 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 94bd7ec..37b20ff 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -700,6 +700,7 @@ config ARCH_UNIPHIER
select DM_GPIO
select DM_SERIAL
select DM_I2C
+   select DM_MMC
help
  Support for UniPhier SoC family developed by Socionext Inc.
  (formerly, System LSI Business Division of Panasonic Corporation)
diff --git a/configs/uniphier_ld4_sld8_defconfig 
b/configs/uniphier_ld4_sld8_defconfig
index dbee08e..892bccc 100644
--- a/configs/uniphier_ld4_sld8_defconfig
+++ b/configs/uniphier_ld4_sld8_defconfig
@@ -21,6 +21,7 @@ CONFIG_CMD_TIME=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
 CONFIG_GPIO_UNIPHIER=y
+CONFIG_MMC_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index 3c2f7b0..45ef883 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_TIME=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
 CONFIG_GPIO_UNIPHIER=y
+CONFIG_MMC_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pro5_defconfig b/configs/uniphier_pro5_defconfig
index cf5f1ce..0029cd3 100644
--- a/configs/uniphier_pro5_defconfig
+++ b/configs/uniphier_pro5_defconfig
@@ -20,6 +20,7 @@ CONFIG_CMD_TIME=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
 CONFIG_GPIO_UNIPHIER=y
+CONFIG_MMC_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_pxs2_ld6b_defconfig 
b/configs/uniphier_pxs2_ld6b_defconfig
index 00a2900..0115c21 100644
--- a/configs/uniphier_pxs2_ld6b_defconfig
+++ b/configs/uniphier_pxs2_ld6b_defconfig
@@ -21,6 +21,7 @@ CONFIG_CMD_TIME=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_SIMPLE_BUS=y
 CONFIG_GPIO_UNIPHIER=y
+CONFIG_MMC_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/configs/uniphier_sld3_defconfig b/configs/uniphier_sld3_defconfig
index 013fc8a..5f0d678 100644
--- a/configs/uniphier_sld3_defconfig
+++ b/configs/uniphier_sld3_defconfig
@@ -18,6 +18,7 @@ CONFIG_CMD_TIME=y
 # CONFIG_CMD_MISC is not set
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_GPIO_UNIPHIER=y
+CONFIG_MMC_UNIPHIER=y
 CONFIG_NAND_DENALI=y
 CONFIG_SYS_NAND_DENALI_64BIT=y
 CONFIG_NAND_DENALI_SPARE_AREA_SKIP_BYTES=8
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index fcec0c0..9d14155 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -146,6 +146,10 @@
 #define CONFIG_FAT_WRITE
 #define CONFIG_DOS_PARTITION
 
+/* SD/MMC */
+#define CONFIG_CMD_MMC
+#define CONFIG_GENERIC_MMC
+
 /* memtest works on */
 #define CONFIG_SYS_MEMTEST_START   CONFIG_SYS_SDRAM_BASE
 #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_SDRAM_BASE + 0x0100)
-- 
1.9.1

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


[U-Boot] [PATCH v3 0/3] UniPhier SD/eMMC controller driver

2016-02-16 Thread Masahiro Yamada


Changes in v3:
  - Use dev_err/dev_dbg instead of pr_err/pr_debug
  - Tidy up uniphier_sd_set_ios()
  - Allow to use DMA even in SPL if the target address is DMA'able

Changes in v2:
  - Fix the divisor bug on the older IP (on PH1-LD4, PH1-sLD8, PH1-Pro4)
  - Increase time out because "mmc erase" can sometimes take long
  - Move HOST_MODE register setting to uniphier_sd_init()
because this register does not need setting multipule times.

Masahiro Yamada (3):
  mmc: uniphier: add driver for UniPhier SD/MMC host controller
  ARM: uniphier: enable UniPhier SD/MMC host driver
  ARM: dts: uniphier: add SD/MMC host controller nodes

 arch/arm/Kconfig |   1 +
 arch/arm/dts/uniphier-ph1-ld4-ref.dts|   4 +
 arch/arm/dts/uniphier-ph1-ld4.dtsi   |  25 +
 arch/arm/dts/uniphier-ph1-ld6b-ref.dts   |   4 +
 arch/arm/dts/uniphier-ph1-pro4-ace.dts   |   4 +
 arch/arm/dts/uniphier-ph1-pro4-ref.dts   |   8 +
 arch/arm/dts/uniphier-ph1-pro4-sanji.dts |   4 +
 arch/arm/dts/uniphier-ph1-pro4.dtsi  |  37 ++
 arch/arm/dts/uniphier-ph1-pro5-4kbox.dts |   8 +
 arch/arm/dts/uniphier-ph1-pro5.dtsi  |  24 +
 arch/arm/dts/uniphier-ph1-sld3-ref.dts   |   4 +
 arch/arm/dts/uniphier-ph1-sld3.dtsi  |  19 +
 arch/arm/dts/uniphier-ph1-sld8-ref.dts   |   4 +
 arch/arm/dts/uniphier-ph1-sld8.dtsi  |  25 +
 arch/arm/dts/uniphier-pinctrl.dtsi   |  15 +
 arch/arm/dts/uniphier-proxstream2-gentil.dts |   4 +
 arch/arm/dts/uniphier-proxstream2-vodka.dts  |   4 +
 arch/arm/dts/uniphier-proxstream2.dtsi   |  24 +
 configs/uniphier_ld4_sld8_defconfig  |   1 +
 configs/uniphier_pro4_defconfig  |   1 +
 configs/uniphier_pro5_defconfig  |   1 +
 configs/uniphier_pxs2_ld6b_defconfig |   1 +
 configs/uniphier_sld3_defconfig  |   1 +
 doc/README.uniphier  |   1 +
 drivers/mmc/Kconfig  |   6 +
 drivers/mmc/Makefile |   1 +
 drivers/mmc/uniphier-sd.c| 746 +++
 include/configs/uniphier.h   |   4 +
 28 files changed, 981 insertions(+)
 create mode 100644 drivers/mmc/uniphier-sd.c

-- 
1.9.1

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


[U-Boot] [PATCH v3 3/3] ARM: dts: uniphier: add SD/MMC host controller nodes

2016-02-16 Thread Masahiro Yamada
This host controller is available for all UniPhier SoCs.

Signed-off-by: Masahiro Yamada 
---

Changes in v3: None
Changes in v2: None

 arch/arm/dts/uniphier-ph1-ld4-ref.dts|  4 +++
 arch/arm/dts/uniphier-ph1-ld4.dtsi   | 25 +++
 arch/arm/dts/uniphier-ph1-ld6b-ref.dts   |  4 +++
 arch/arm/dts/uniphier-ph1-pro4-ace.dts   |  4 +++
 arch/arm/dts/uniphier-ph1-pro4-ref.dts   |  8 ++
 arch/arm/dts/uniphier-ph1-pro4-sanji.dts |  4 +++
 arch/arm/dts/uniphier-ph1-pro4.dtsi  | 37 
 arch/arm/dts/uniphier-ph1-pro5-4kbox.dts |  8 ++
 arch/arm/dts/uniphier-ph1-pro5.dtsi  | 24 ++
 arch/arm/dts/uniphier-ph1-sld3-ref.dts   |  4 +++
 arch/arm/dts/uniphier-ph1-sld3.dtsi  | 19 ++
 arch/arm/dts/uniphier-ph1-sld8-ref.dts   |  4 +++
 arch/arm/dts/uniphier-ph1-sld8.dtsi  | 25 +++
 arch/arm/dts/uniphier-pinctrl.dtsi   | 15 +++
 arch/arm/dts/uniphier-proxstream2-gentil.dts |  4 +++
 arch/arm/dts/uniphier-proxstream2-vodka.dts  |  4 +++
 arch/arm/dts/uniphier-proxstream2.dtsi   | 24 ++
 17 files changed, 217 insertions(+)

diff --git a/arch/arm/dts/uniphier-ph1-ld4-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
index f62916d..d7b0007 100644
--- a/arch/arm/dts/uniphier-ph1-ld4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld4-ref.dts
@@ -51,6 +51,10 @@
status = "okay";
 };
 
+&sd {
+   status = "okay";
+};
+
 &usb0 {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-ld4.dtsi 
b/arch/arm/dts/uniphier-ph1-ld4.dtsi
index f13c6db..5ae029e 100644
--- a/arch/arm/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld4.dtsi
@@ -220,6 +220,31 @@
clock-frequency = <10>;
};
 
+   sd: sdhc@5a40 {
+   compatible = "socionext,uniphier-sdhc";
+   status = "disabled";
+   reg = <0x5a40 0x200>;
+   interrupts = <0 76 4>;
+   pinctrl-names = "default", "1.8v";
+   pinctrl-0 = <&pinctrl_sd>;
+   pinctrl-1 = <&pinctrl_sd_1v8>;
+   clocks = <&mio 0>;
+   bus-width = <4>;
+   };
+
+   emmc: sdhc@5a50 {
+   compatible = "socionext,uniphier-sdhc";
+   status = "disabled";
+   reg = <0x5a50 0x200>;
+   interrupts = <0 78 4>;
+   pinctrl-names = "default", "1.8v";
+   pinctrl-0 = <&pinctrl_emmc>;
+   pinctrl-1 = <&pinctrl_emmc_1v8>;
+   clocks = <&mio 1>;
+   bus-width = <8>;
+   non-removable;
+   };
+
usb0: usb@5a800100 {
compatible = "socionext,uniphier-ehci", "generic-ehci";
status = "disabled";
diff --git a/arch/arm/dts/uniphier-ph1-ld6b-ref.dts 
b/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
index dca408b..13a29fd 100644
--- a/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-ld6b-ref.dts
@@ -53,6 +53,10 @@
status = "okay";
 };
 
+&sd {
+   status = "okay";
+};
+
 &usb0 {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ace.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ace.dts
index 6e741ea..37e0853 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ace.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ace.dts
@@ -69,6 +69,10 @@
status = "okay";
 };
 
+&sd {
+   status = "okay";
+};
+
 &usb0 {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 202a642..07a9783 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -54,6 +54,14 @@
status = "okay";
 };
 
+&sd {
+   status = "okay";
+};
+
+&sd1 {
+   status = "okay";
+};
+
 &usb0 {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts 
b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
index 91a71ef..1ca1042 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
@@ -64,6 +64,10 @@
status = "okay";
 };
 
+&emmc {
+   status = "okay";
+};
+
 &usb0 {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index 6637aea..d5767b6 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -343,6 +343,43 @@
clock-frequency = <40>;
};
 
+   sd: sdhc@5a40 {
+   compatible = "socionext,uniphier-sdhc";
+   status = "disabled";
+   reg = <0x5a40 0x200>;
+   interrupts = <0 76 4>;
+   pinctrl-names = "default", "1.8v";
+   pinctrl-0 = <&pinctrl_sd>;
+   pinctrl-1 = <&pinctrl_sd_1v8>;
+   clocks = <&mio 0>;
+   bus-width = <4>;
+   };
+
+   emmc: sdhc@5a50 {

[U-Boot] [PATCH v3 1/3] mmc: uniphier: add driver for UniPhier SD/MMC host controller

2016-02-16 Thread Masahiro Yamada
Add a driver for the on-chip SD/eMMC host controller used by
UniPhier SoC family.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Use dev_err/dev_dbg instead of pr_err/pr_debug
  - Tidy up uniphier_sd_set_ios()
  - Allow to use DMA even in SPL if the target address is DMA'able

Changes in v2:
  - Fix the divisor bug on the older IP (on PH1-LD4, PH1-sLD8, PH1-Pro4)
  - Increase time out because "mmc erase" can sometimes take long
  - Move HOST_MODE register setting to uniphier_sd_init()
because this register does not need setting multipule times.

 doc/README.uniphier   |   1 +
 drivers/mmc/Kconfig   |   6 +
 drivers/mmc/Makefile  |   1 +
 drivers/mmc/uniphier-sd.c | 746 ++
 4 files changed, 754 insertions(+)
 create mode 100644 drivers/mmc/uniphier-sd.c

diff --git a/doc/README.uniphier b/doc/README.uniphier
index bcf0ac3..7cfff97 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -93,6 +93,7 @@ Supported devices
 
  - UART (on-chip)
  - NAND
+ - SD/eMMC
  - USB 2.0 (EHCI)
  - USB 3.0 (xHCI)
  - LAN (on-board SMSC9118)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 9f4b766..faffefd 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -37,4 +37,10 @@ config PIC32_SDHCI
help
  Support for Microchip PIC32 SDHCI controller.
 
+config MMC_UNIPHIER
+   bool "UniPhier SD/MMC Host Controller support"
+   depends on ARCH_UNIPHIER
+   help
+ This selects support for the SD/MMC Host Controller on UniPhier SoCs.
+
 endmenu
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index c9c3e3e..b85e4bf 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_SH_SDHI) += sh_sdhi.o
 obj-$(CONFIG_SOCFPGA_DWMMC) += socfpga_dw_mmc.o
 obj-$(CONFIG_SPEAR_SDHCI) += spear_sdhci.o
 obj-$(CONFIG_TEGRA_MMC) += tegra_mmc.o
+obj-$(CONFIG_MMC_UNIPHIER) += uniphier-sd.o
 obj-$(CONFIG_ZYNQ_SDHCI) += zynq_sdhci.o
 
 ifdef CONFIG_SPL_BUILD
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
new file mode 100644
index 000..800ba2f
--- /dev/null
+++ b/drivers/mmc/uniphier-sd.c
@@ -0,0 +1,746 @@
+/*
+ * Copyright (C) 2016 Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define UNIPHIER_SD_CMD0x000   /* command */
+#define   UNIPHIER_SD_CMD_NOSTOP   BIT(14) /* No automatic CMD12 issue */
+#define   UNIPHIER_SD_CMD_MULTIBIT(13) /* multiple block 
transfer */
+#define   UNIPHIER_SD_CMD_RD   BIT(12) /* 1: read, 0: write */
+#define   UNIPHIER_SD_CMD_DATA BIT(11) /* data transfer */
+#define   UNIPHIER_SD_CMD_APP  BIT(6)  /* ACMD preceded by CMD55 */
+#define   UNIPHIER_SD_CMD_NORMAL   (0 << 8)/* auto-detect of resp-type */
+#define   UNIPHIER_SD_CMD_RSP_NONE (3 << 8)/* response: none */
+#define   UNIPHIER_SD_CMD_RSP_R1   (4 << 8)/* response: R1, R5, R6, R7 */
+#define   UNIPHIER_SD_CMD_RSP_R1B  (5 << 8)/* response: R1b, R5b */
+#define   UNIPHIER_SD_CMD_RSP_R2   (6 << 8)/* response: R2 */
+#define   UNIPHIER_SD_CMD_RSP_R3   (7 << 8)/* response: R3, R4 */
+#define UNIPHIER_SD_ARG0x008   /* command argument */
+#define UNIPHIER_SD_STOP   0x010   /* stop action control */
+#define   UNIPHIER_SD_STOP_SEC BIT(8)  /* use sector count */
+#define   UNIPHIER_SD_STOP_STP BIT(0)  /* issue CMD12 */
+#define UNIPHIER_SD_SECCNT 0x014   /* sector counter */
+#define UNIPHIER_SD_RSP10  0x018   /* response[39:8] */
+#define UNIPHIER_SD_RSP32  0x020   /* response[71:40] */
+#define UNIPHIER_SD_RSP54  0x028   /* response[103:72] */
+#define UNIPHIER_SD_RSP76  0x030   /* response[127:104] */
+#define UNIPHIER_SD_INFO1  0x038   /* IRQ status 1 */
+#define   UNIPHIER_SD_INFO1_CD BIT(5)  /* state of card detect */
+#define   UNIPHIER_SD_INFO1_INSERT BIT(4)  /* card inserted */
+#define   UNIPHIER_SD_INFO1_REMOVE BIT(3)  /* card removed */
+#define   UNIPHIER_SD_INFO1_CMPBIT(2)  /* data complete */
+#define   UNIPHIER_SD_INFO1_RSPBIT(0)  /* response complete */
+#define UNIPHIER_SD_INFO2  0x03c   /* IRQ status 2 */
+#define   UNIPHIER_SD_INFO2_ERR_ILABIT(15) /* illegal access err */
+#define   UNIPHIER_SD_INFO2_CBSY   BIT(14) /* command busy */
+#define   UNIPHIER_SD_INFO2_BWEBIT(9)  /* write buffer ready */
+#define   UNIPHIER_SD_INFO2_BREBIT(8)  /* read buffer ready */
+#define   UNIPHIER_SD_INFO2_DAT0   BIT(7)  /* SDDAT0 */
+#define   UNIPHIER_SD_INFO2_ERR_RTOBIT(6)  /* response time out */
+#define   UNIPHIER_SD_INFO2_ERR_ILRBIT(5)  /* illegal read err */
+#define   UNIPHIER_SD_INFO2_ERR_ILW 

[U-Boot] [PATCH 2/4] ARM: uniphier: add a command to find the first MMC (non-SD) device

2016-02-16 Thread Masahiro Yamada
UniPhier SoC family supports both (e)MMC boot and SD card boot;
however, both of them are handled in the same uclass.

When booting from the eMMC, we want to know the device number
of the (e)MMC, not SD.  This command is useful to find the first
MMC (non-SD) device.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/boot-mode/boot-mode.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index 2f2e45d..481e209 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../sbc/sbc-regs.h"
 #include "../soc-info.h"
@@ -77,3 +78,38 @@ u32 spl_boot_mode(void)
 
return MMCSD_MODE_EMMCBOOT;
 }
+
+#ifdef CONFIG_DM_MMC
+static int find_first_mmc_device(void)
+{
+   struct mmc *mmc;
+   int i;
+
+   for (i = 0; (mmc = find_mmc_device(i)); i++) {
+   if (!mmc_init(mmc) && IS_MMC(mmc))
+   return i;
+   }
+
+   return -ENODEV;
+}
+
+#ifndef CONFIG_SPL_BUILD
+static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
+{
+   int dev;
+
+   dev = find_first_mmc_device();
+   if (dev < 0)
+   return CMD_RET_FAILURE;
+
+   setenv_ulong("mmc_first_dev", dev);
+   return CMD_RET_SUCCESS;
+}
+
+U_BOOT_CMD(
+  mmcsetn, 1,  1,  do_mmcsetn,
+   "Set the first MMC (not SD) dev number to \"mmc_first_dev\" enviroment",
+   ""
+);
+#endif
+#endif
-- 
1.9.1

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


[U-Boot] [PATCH 1/4] ARM: uniphier: add eMMC boot support

2016-02-16 Thread Masahiro Yamada
Export device nodes needed for eMMC boot (eMMC node, pinctrl, and
clock) to the SPL DTB.  CONFIG_SUPPORT_EMMC_BOOT is also necessary
to use "mmc partconf" command.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ph1-pro4-sanji.dts | 12 
 arch/arm/dts/uniphier-proxstream2-gentil.dts | 12 
 arch/arm/dts/uniphier-proxstream2-vodka.dts  | 12 
 arch/arm/mach-uniphier/boot-mode/boot-mode.c | 25 +
 include/configs/uniphier.h   |  3 +++
 5 files changed, 64 insertions(+)

diff --git a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts 
b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
index 1ca1042..82e2bd0 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-sanji.dts
@@ -95,6 +95,14 @@
u-boot,dm-pre-reloc;
 };
 
+&mio {
+   u-boot,dm-pre-reloc;
+};
+
+&emmc {
+   u-boot,dm-pre-reloc;
+};
+
 &pinctrl {
u-boot,dm-pre-reloc;
 };
@@ -102,3 +110,7 @@
 &pinctrl_uart0 {
u-boot,dm-pre-reloc;
 };
+
+&pinctrl_emmc {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/uniphier-proxstream2-gentil.dts 
b/arch/arm/dts/uniphier-proxstream2-gentil.dts
index c3551fe..eb1d2bc 100644
--- a/arch/arm/dts/uniphier-proxstream2-gentil.dts
+++ b/arch/arm/dts/uniphier-proxstream2-gentil.dts
@@ -75,6 +75,14 @@
u-boot,dm-pre-reloc;
 };
 
+&mio {
+   u-boot,dm-pre-reloc;
+};
+
+&emmc {
+   u-boot,dm-pre-reloc;
+};
+
 &pinctrl {
u-boot,dm-pre-reloc;
 };
@@ -82,3 +90,7 @@
 &pinctrl_uart2 {
u-boot,dm-pre-reloc;
 };
+
+&pinctrl_emmc {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/uniphier-proxstream2-vodka.dts 
b/arch/arm/dts/uniphier-proxstream2-vodka.dts
index d61e0b6..e7d5db8 100644
--- a/arch/arm/dts/uniphier-proxstream2-vodka.dts
+++ b/arch/arm/dts/uniphier-proxstream2-vodka.dts
@@ -60,6 +60,14 @@
u-boot,dm-pre-reloc;
 };
 
+&mio {
+   u-boot,dm-pre-reloc;
+};
+
+&emmc {
+   u-boot,dm-pre-reloc;
+};
+
 &pinctrl {
u-boot,dm-pre-reloc;
 };
@@ -67,3 +75,7 @@
 &pinctrl_uart2 {
u-boot,dm-pre-reloc;
 };
+
+&pinctrl_emmc {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index 935e551..2f2e45d 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 
 #include "../sbc/sbc-regs.h"
@@ -52,3 +53,27 @@ u32 spl_boot_device(void)
 
return ret == BOOT_DEVICE_USB ? BOOT_DEVICE_NOR : ret;
 }
+
+u32 spl_boot_mode(void)
+{
+   struct mmc *mmc;
+
+   /*
+* work around a bug in the Boot ROM of PH1-sLD3, LD4, Pro4, and sLD8:
+*
+* The boot ROM in these SoCs breaks the PARTITION_CONFIG [179] of
+* Extended CSD register; when switching to the Boot Partition 1, the
+* Boot ROM should issue the SWITCH command (CMD6) with Set Bits for
+* the Access Bits, but in fact it uses Write Byte for the Access Bits.
+* As a result, the BOOT_PARTITION_ENABLE field of the PARTITION_CONFIG
+* is lost.  This bug was fixed for PH1-Pro5 and later SoCs.
+*
+* Fixup mmc->part_config here because it is used to determine the
+* partition which the U-Boot image is read from.
+*/
+   mmc = find_mmc_device(0);
+   mmc->part_config &= ~EXT_CSD_BOOT_PART_NUM(PART_ACCESS_MASK);
+   mmc->part_config |= EXT_CSD_BOOT_PARTITION_ENABLE;
+
+   return MMCSD_MODE_EMMCBOOT;
+}
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 9d14155..19dbfbb 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -148,6 +148,7 @@
 
 /* SD/MMC */
 #define CONFIG_CMD_MMC
+#define CONFIG_SUPPORT_EMMC_BOOT
 #define CONFIG_GENERIC_MMC
 
 /* memtest works on */
@@ -263,6 +264,7 @@
 #define CONFIG_SPL_FRAMEWORK
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_MMC_SUPPORT
 
 #define CONFIG_SPL_LIBCOMMON_SUPPORT   /* for mem_malloc_init */
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
@@ -270,6 +272,7 @@
 #define CONFIG_SPL_BOARD_INIT
 
 #define CONFIG_SYS_NAND_U_BOOT_OFFS0x1
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0x80
 
 #define CONFIG_SPL_MAX_FOOTPRINT   0x1
 
-- 
1.9.1

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


[U-Boot] [PATCH 4/4] ARM: uniphier: default to environment in eMMC

2016-02-16 Thread Masahiro Yamada
Of the several boot devices supported, it looks like the eMMC is the
most commonly used.  Enable CONFIG_ENV_IS_IN_MMC by default.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/boot-mode/boot-mode.c |  5 +
 include/configs/uniphier.h   | 12 ++--
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-uniphier/boot-mode/boot-mode.c 
b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
index 481e209..d5ef10a 100644
--- a/arch/arm/mach-uniphier/boot-mode/boot-mode.c
+++ b/arch/arm/mach-uniphier/boot-mode/boot-mode.c
@@ -93,6 +93,11 @@ static int find_first_mmc_device(void)
return -ENODEV;
 }
 
+int mmc_get_env_dev(void)
+{
+   return find_first_mmc_device();
+}
+
 #ifndef CONFIG_SPL_BUILD
 static int do_mmcsetn(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
argv[])
 {
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 1b28cdc..b1c8ccb 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -99,16 +99,16 @@
 
 #define CONFIG_CONS_INDEX  1
 
-/*
- * For NAND booting the environment is embedded in the U-Boot image. Please 
take
- * look at the file board/amcc/canyonlands/u-boot-nand.lds for details.
- */
+/* #define CONFIG_ENV_IS_NOWHERE */
 /* #define CONFIG_ENV_IS_IN_NAND */
-#define CONFIG_ENV_IS_NOWHERE
+#define CONFIG_ENV_IS_IN_MMC
+#define CONFIG_ENV_OFFSET  0x8
 #define CONFIG_ENV_SIZE0x2000
-#define CONFIG_ENV_OFFSET  0x0
 /* #define CONFIG_ENV_OFFSET_REDUND(CONFIG_ENV_OFFSET + CONFIG_ENV_SIZE) */
 
+#define CONFIG_SYS_MMC_ENV_DEV 0
+#define CONFIG_SYS_MMC_ENV_PART1
+
 /* Time clock 1MHz */
 #define CONFIG_SYS_TIMER_RATE  100
 
-- 
1.9.1

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


[U-Boot] [PATCH 0/4] ARM: uniphier: eMMC boot support

2016-02-16 Thread Masahiro Yamada


Masahiro Yamada (4):
  ARM: uniphier: add eMMC boot support
  ARM: uniphier: add a command to find the first MMC (non-SD) device
  ARM: uniphier: add emmcupdate command
  ARM: uniphier: default to environment in eMMC

 arch/arm/dts/uniphier-ph1-pro4-sanji.dts | 12 +
 arch/arm/dts/uniphier-proxstream2-gentil.dts | 12 +
 arch/arm/dts/uniphier-proxstream2-vodka.dts  | 12 +
 arch/arm/mach-uniphier/boot-mode/boot-mode.c | 66 
 doc/README.uniphier  | 14 ++
 include/configs/uniphier.h   | 22 +++---
 6 files changed, 132 insertions(+), 6 deletions(-)

-- 
1.9.1

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


[U-Boot] [PATCH 3/4] ARM: uniphier: add emmcupdate command

2016-02-16 Thread Masahiro Yamada
The Boot ROM expects the boot image (SPL) in the Boot Partition 1.
So, updating images involves the hardware partition switch.  It might
be a bit advanced for some users.

To be user-friendly, this commit adds a useful command to update the
images; just put SPL and U-Boot proper into the public directory of
the TFTP server and execute "run emmcupdate" from the command line.

Signed-off-by: Masahiro Yamada 
---

 doc/README.uniphier| 14 ++
 include/configs/uniphier.h |  7 +++
 2 files changed, 21 insertions(+)

diff --git a/doc/README.uniphier b/doc/README.uniphier
index 7cfff97..47b4d78 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -78,6 +78,20 @@ directory, and then run the following command at the U-Boot 
command line:
   => run nandupdate
 
 
+Burn U-Boot images to eMMC
+--
+
+Write two files to the Boot partition 1 of the eMMC device as follows:
+ - spl/u-boot-spl.bin at the offset address 0x
+ - u-boot.img at the offset address 0x0001
+
+If a TFTP server is available, the images can be easily updated.
+Just copy the u-boot-spl-dtb.bin and u-boot-dtb.img to the TFTP public
+directory, and then run the following command at the U-Boot command line:
+
+  => run emmcupdate
+
+
 UniPhier specific commands
 --
 
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 19dbfbb..1b28cdc 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -233,6 +233,13 @@
"netdev=eth0\0" \
"verify=n\0"\
"nor_base=0x4200\0" \
+   "emmcupdate=mmcsetn &&" \
+   "mmc partconf $mmc_first_dev 0 1 1 &&"  \
+   "mmc erase 0 800 &&"\
+   "tftpboot u-boot-spl.bin &&"\
+   "mmc write $loadaddr 0 80 &&"   \
+   "tftpboot u-boot.img &&"\
+   "mmc write $loadaddr 80 780\0"  \
"nandupdate=nand erase 0 0x0010 &&" \
"tftpboot u-boot-spl.bin &&"\
"nand write $loadaddr 0 0x0001 &&"  \
-- 
1.9.1

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


Re: [U-Boot] [PATCH v2 1/3] mmc: uniphier: add driver for UniPhier SD/MMC host controller

2016-02-16 Thread Masahiro Yamada
Hi Marek,


2016-02-10 22:45 GMT+09:00 Marek Vasut :
> On 02/10/2016 02:28 PM, Masahiro Yamada wrote:
>> Add a driver for the on-chip SD/eMMC host controller used by
>> UniPhier SoC family.
>>
>> Signed-off-by: Masahiro Yamada 
>
> 前略 山田さん,
>
> [...]
>
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define pr_err   printf
>> +#define pr_warn  printf
>> +#ifdef DEBUG
>> +#define pr_debug printf
>> +#else
>> +#define pr_debug(...)
>> +#endif
>
> This should go into include/ somewhere, your driver shouldn't be a
> platform abstraction library.

Fixed in v3.



>> +static int uniphier_sd_wait_irq(struct uniphier_sd_priv *priv,
>> + unsigned int reg, u32 flag)
>> +{
>> + long wait = 100;
>> + int ret;
>
> Replace this with wait_for_bit() please .


It cannot check error during the loop.

I want to check the error flags in the loop
because no reason to wait for the time-out
if some error happens.


>> + while (!(readl(priv->regbase + reg) & flag)) {
>> + if (wait-- < 0) {
>> + pr_err("timeout\n");
>> + return -ETIMEDOUT;
>> + }
>> +
>> + ret = uniphier_sd_check_error(priv);
>> + if (ret)
>> + return ret;
>> +
>> + udelay(1);
>> + }
>> +
>> + return 0;
>> +}
>
> [...]
>
>> +static void uniphier_sd_dma_start(struct uniphier_sd_priv *priv,
>> +   dma_addr_t dma_addr)
>> +{
>> + u32 tmp;
>> +
>> + writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO1);
>> + writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO2);
>> +
>> + /* enable DMA */
>> + tmp = readl(priv->regbase + UNIPHIER_SD_EXTMODE);
>> + tmp |= UNIPHIER_SD_EXTMODE_DMA_EN;
>> + writel(tmp, priv->regbase + UNIPHIER_SD_EXTMODE);
>
> I'd say, use setbits_le32(), but could it be that this driver is kept in
> sync with Linux ?

Yes, I am developing the MMC driver
for Linux as well as U-Boot at the same time.

This is the U-Boot counter-part,
although the Linux one has not been upstreamed yet.

It can save my time to copy-paste code snippets between the two.

I want to sync as much code as possible.




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


[U-Boot] [PATCH v2] ARM: at91: sama5d2: configure the L2 cache memory

2016-02-16 Thread Samuel Mescoff
The SAMA5D2 has a second internal SRAM that can be reassigned as a L2
cache memory.
Make sure it is configured as a L2 cache memory when booting from a SPL
image.

Based on the commit b5ea95ef2b5b from the at91bootstrap repository.

Signed-off-by: Samuel Mescoff 
---

Changes for v2:
 - removed useless #ifdef CONFIG_SAMA5D2

 arch/arm/mach-at91/atmel_sfr.c| 7 +++
 arch/arm/mach-at91/include/mach/at91_common.h | 1 +
 arch/arm/mach-at91/include/mach/sama5_sfr.h   | 1 +
 arch/arm/mach-at91/spl_atmel.c| 4 
 4 files changed, 13 insertions(+)

diff --git a/arch/arm/mach-at91/atmel_sfr.c b/arch/arm/mach-at91/atmel_sfr.c
index 2bccb84..adf44c6 100644
--- a/arch/arm/mach-at91/atmel_sfr.c
+++ b/arch/arm/mach-at91/atmel_sfr.c
@@ -19,3 +19,10 @@ void redirect_int_from_saic_to_aic(void)
writel((key32 | ATMEL_SFR_AICREDIR_NSAIC), &sfr->aicredir);
}
 }
+
+void configure_2nd_sram_as_l2_cache(void)
+{
+   struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
+
+   writel(1, &sfr->l2cc_hramc);
+}
diff --git a/arch/arm/mach-at91/include/mach/at91_common.h 
b/arch/arm/mach-at91/include/mach/at91_common.h
index efcd74e..0742ffc 100644
--- a/arch/arm/mach-at91/include/mach/at91_common.h
+++ b/arch/arm/mach-at91/include/mach/at91_common.h
@@ -34,5 +34,6 @@ void at91_spl_board_init(void);
 void at91_disable_wdt(void);
 void matrix_init(void);
 void redirect_int_from_saic_to_aic(void);
+void configure_2nd_sram_as_l2_cache(void);
 
 #endif /* AT91_COMMON_H */
diff --git a/arch/arm/mach-at91/include/mach/sama5_sfr.h 
b/arch/arm/mach-at91/include/mach/sama5_sfr.h
index 7b19a20..b040256 100644
--- a/arch/arm/mach-at91/include/mach/sama5_sfr.h
+++ b/arch/arm/mach-at91/include/mach/sama5_sfr.h
@@ -25,6 +25,7 @@ struct atmel_sfr {
u32 sn0;/* 0x4c */
u32 sn1;/* 0x50 */
u32 aicredir;   /* 0x54 */
+   u32 l2cc_hramc; /* 0x58 */
 };
 
 /* Bit field in DDRCFG */
diff --git a/arch/arm/mach-at91/spl_atmel.c b/arch/arm/mach-at91/spl_atmel.c
index b2fb51d..688289e 100644
--- a/arch/arm/mach-at91/spl_atmel.c
+++ b/arch/arm/mach-at91/spl_atmel.c
@@ -79,6 +79,10 @@ void board_init_f(ulong dummy)
 {
switch_to_main_crystal_osc();
 
+#ifdef CONFIG_SAMA5D2
+   configure_2nd_sram_as_l2_cache();
+#endif
+
/* disable watchdog */
at91_disable_wdt();
 
-- 
2.5.0

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


Re: [U-Boot] [PATCH v2] ARM: at91: sama5d2: configure the L2 cache memory

2016-02-16 Thread Yang, Wenyou


> -Original Message-
> From: Samuel Mescoff [mailto:samuel.mesc...@mobile-devices.fr]
> Sent: 2016年2月16日 16:45
> To: u-boot@lists.denx.de
> Cc: Samuel Mescoff ;
> andreas.de...@googlemail.com; Yang, Wenyou ;
> Ferre, Nicolas 
> Subject: [U-Boot] [PATCH v2] ARM: at91: sama5d2: configure the L2 cache
> memory
> 
> The SAMA5D2 has a second internal SRAM that can be reassigned as a L2 cache
> memory.
> Make sure it is configured as a L2 cache memory when booting from a SPL image.
> 
> Based on the commit b5ea95ef2b5b from the at91bootstrap repository.
> 
> Signed-off-by: Samuel Mescoff 

It is OK for me.

Reviewed-by: Wenyou Yang 


> ---
> 
> Changes for v2:
>  - removed useless #ifdef CONFIG_SAMA5D2
> 
>  arch/arm/mach-at91/atmel_sfr.c| 7 +++
>  arch/arm/mach-at91/include/mach/at91_common.h | 1 +
>  arch/arm/mach-at91/include/mach/sama5_sfr.h   | 1 +
>  arch/arm/mach-at91/spl_atmel.c| 4 
>  4 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/mach-at91/atmel_sfr.c b/arch/arm/mach-at91/atmel_sfr.c
> index 2bccb84..adf44c6 100644
> --- a/arch/arm/mach-at91/atmel_sfr.c
> +++ b/arch/arm/mach-at91/atmel_sfr.c
> @@ -19,3 +19,10 @@ void redirect_int_from_saic_to_aic(void)
>   writel((key32 | ATMEL_SFR_AICREDIR_NSAIC), &sfr->aicredir);
>   }
>  }
> +
> +void configure_2nd_sram_as_l2_cache(void)
> +{
> + struct atmel_sfr *sfr = (struct atmel_sfr *)ATMEL_BASE_SFR;
> +
> + writel(1, &sfr->l2cc_hramc);
> +}
> diff --git a/arch/arm/mach-at91/include/mach/at91_common.h b/arch/arm/mach-
> at91/include/mach/at91_common.h
> index efcd74e..0742ffc 100644
> --- a/arch/arm/mach-at91/include/mach/at91_common.h
> +++ b/arch/arm/mach-at91/include/mach/at91_common.h
> @@ -34,5 +34,6 @@ void at91_spl_board_init(void);  void 
> at91_disable_wdt(void);
> void matrix_init(void);  void redirect_int_from_saic_to_aic(void);
> +void configure_2nd_sram_as_l2_cache(void);
> 
>  #endif /* AT91_COMMON_H */
> diff --git a/arch/arm/mach-at91/include/mach/sama5_sfr.h b/arch/arm/mach-
> at91/include/mach/sama5_sfr.h
> index 7b19a20..b040256 100644
> --- a/arch/arm/mach-at91/include/mach/sama5_sfr.h
> +++ b/arch/arm/mach-at91/include/mach/sama5_sfr.h
> @@ -25,6 +25,7 @@ struct atmel_sfr {
>   u32 sn0;/* 0x4c */
>   u32 sn1;/* 0x50 */
>   u32 aicredir;   /* 0x54 */
> + u32 l2cc_hramc; /* 0x58 */
>  };
> 
>  /* Bit field in DDRCFG */
> diff --git a/arch/arm/mach-at91/spl_atmel.c b/arch/arm/mach-at91/spl_atmel.c
> index b2fb51d..688289e 100644
> --- a/arch/arm/mach-at91/spl_atmel.c
> +++ b/arch/arm/mach-at91/spl_atmel.c
> @@ -79,6 +79,10 @@ void board_init_f(ulong dummy)  {
>   switch_to_main_crystal_osc();
> 
> +#ifdef CONFIG_SAMA5D2
> + configure_2nd_sram_as_l2_cache();
> +#endif
> +
>   /* disable watchdog */
>   at91_disable_wdt();
> 
> --
> 2.5.0


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


Re: [U-Boot] [PATCH] fastboot: update error and warning messages

2016-02-16 Thread Lukasz Majewski
Hi Marek,

> On 02/16/2016 02:20 AM, Steve Rae wrote:
> > ping -- Thanks!
> > 
> > On 16-01-27 03:42 PM, Marek Vasut wrote:
> >> On Thursday, January 28, 2016 at 12:02:41 AM, Steve Rae wrote:
> >>> Fix the formatting in error messages, and demote one error message
> >>> to a warning, as it is only informational.
> >>>
> >>> Signed-off-by: Steve Rae 
> >>
> >> I'd leave this to Lukasz, if he doesn't respond, ping me in a week
> >> or so.
> >>
> >> Best regards,
> >> Marek Vasut
> >>
> 
> Applied to u-boot-usb/master, thanks!
> 

+1

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] fixup! gpio: uniphier: add driver for UniPhier GPIO controller

2016-02-16 Thread Masahiro Yamada
Signed-off-by: Masahiro Yamada 
---

 doc/README.uniphier | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/README.uniphier b/doc/README.uniphier
index 47b4d78..5ac52bd 100644
--- a/doc/README.uniphier
+++ b/doc/README.uniphier
@@ -110,6 +110,7 @@ Supported devices
  - SD/eMMC
  - USB 2.0 (EHCI)
  - USB 3.0 (xHCI)
+ - GPIO
  - LAN (on-board SMSC9118)
  - I2C
  - EEPROM (connected to the on-board I2C bus)
-- 
1.9.1

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


Re: [U-Boot] [PATCH 04/16] trace: Fix compiler warnings in trace

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> With min() we must use the same type for each parameter. Fix two problems
> in trace.c which produce compiler warnings.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/trace.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH 05/16] lib: Don't instrument the div64 function

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> This function can be called from the timer code on instrumented functions.
> Mark it as 'notrace' so that it doesn't cause infinite recursion.
>
> Signed-off-by: Simon Glass 
> ---
>
>  lib/div64.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 08/16] timer: Provide an early timer

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> In some cases the timer must be accessible before driver model is active.
> Examples include when using CONFIG_TRACE to trace U-Boot's execution before
> driver model is set up. Enable this option to use an early timer. These
> functions must be supported by your timer driver: timer_early_get_count()
> and timer_early_get_rate().
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/timer/Kconfig | 10 ++
>  include/timer.h   | 21 +
>  lib/time.c| 28 +---
>  3 files changed, 52 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/timer/Kconfig b/drivers/timer/Kconfig
> index ff65a73..cb18f12 100644
> --- a/drivers/timer/Kconfig
> +++ b/drivers/timer/Kconfig
> @@ -9,6 +9,16 @@ config TIMER
>   will be used. The timer is usually a 32 bits free-running up
>   counter. There may be no real tick, and no timer interrupt.
>
> +config TIMER_EARLY
> +   bool "Allow timer to be used early in U-Boot"
> +   depends on TIMER
> +   help
> + In some cases the timer must be accessible before driver model is
> + active. Examples include when using CONFIG_TRACE to trace U-Boot's
> + execution before driver model is set up. Enable this option to
> + use an early timer. These functions must be supported by your timer
> + driver: timer_early_get_count() and timer_early_get_rate().
> +
>  config ALTERA_TIMER
> bool "Altera timer support"
> depends on TIMER
> diff --git a/include/timer.h b/include/timer.h
> index f14725c..a503bfd 100644
> --- a/include/timer.h
> +++ b/include/timer.h
> @@ -67,4 +67,25 @@ struct timer_dev_priv {
> unsigned long clock_rate;
>  };
>
> +/**
> + * timer_early_get_count() - Implement timer_get_count() before driver model
> + *
> + * If CONFIG_TIMER_EARLY is enabled, this function wil be called to return
> + * the current timer value before the proper driver model timer is ready.
> + * It should be implemented by one of the timer values. This is mostly useful
> + * for tracing.
> + */
> +u64 timer_early_get_count(void);
> +
> +/**
> + * timer_early_get_rate() - Get the timer rate before driver model
> + *
> + * If CONFIG_TIMER_EARLY is enabled, this function wil be called to return
> + * the current timer rate  in Hz before the proper driver model timer is 
> ready.

nits: two spaces between 'rate' and 'in'

> + * It should be implemented by one of the timer values. This is mostly useful
> + * for tracing. This corresponds to the clock_rate value in struct
> + * timer_dev_priv.

Is this supposed to be a hard-codeded value returned by the timer
driver? The timer-uclass driver gets this clock rate from device tree,
but I believe at that time when early timer is called, FDT blob might
not be available yet.

> + */
> +unsigned long timer_early_get_rate(void);
> +
>  #endif /* _TIMER_H_ */

[snip]

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


Re: [U-Boot] [PATCH 09/16] timer: Set up the real timer after driver model is available

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> When using the early timer, we need to manually trigger setting up the
> real timer. This will not happen automatically. Do this immediately after
> starting driver model.
>
> Signed-off-by: Simon Glass 
> ---
>
>  common/board_f.c |  6 ++
>  common/board_r.c | 14 --
>  2 files changed, 18 insertions(+), 2 deletions(-)
>

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


Re: [U-Boot] [PATCH 07/16] timer: Support tracing fully

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> A few of the functions in the timer uclass are not marked with 'notrace'. Fix
> this so that tracing can be used with CONFIG_TRACE.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/timer/timer-uclass.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/timer/timer-uclass.c b/drivers/timer/timer-uclass.c
> index 83d1a35..382c0f2 100644
> --- a/drivers/timer/timer-uclass.c
> +++ b/drivers/timer/timer-uclass.c
> @@ -22,7 +22,7 @@ DECLARE_GLOBAL_DATA_PTR;
>   * tick, and no timer interrupt.
>   */
>
> -int timer_get_count(struct udevice *dev, u64 *count)
> +int notrace timer_get_count(struct udevice *dev, u64 *count)
>  {
> const struct timer_ops *ops = device_get_ops(dev);
>
> @@ -32,9 +32,9 @@ int timer_get_count(struct udevice *dev, u64 *count)
> return ops->get_count(dev, count);

Besides making timer_get_count() and timer_get_rate() APIs notrace,
does it help to make the timer uclass ops notrace as well?

>  }
>
> -unsigned long timer_get_rate(struct udevice *dev)
> +unsigned long notrace timer_get_rate(struct udevice *dev)
>  {
> -   struct timer_dev_priv *uc_priv = dev_get_uclass_priv(dev);
> +   struct timer_dev_priv *uc_priv = dev->uclass_priv;

Why is this change needed?

>
> return uc_priv->clock_rate;
>  }
> --

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


Re: [U-Boot] [PATCH 10/16] sandbox: timer: Support the early timer

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> Add support for the early timer so we can use tracing with sandbox again.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/timer/sandbox_timer.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/timer/sandbox_timer.c b/drivers/timer/sandbox_timer.c
> index a8da936..4537c82 100644
> --- a/drivers/timer/sandbox_timer.c
> +++ b/drivers/timer/sandbox_timer.c
> @@ -18,9 +18,19 @@ void sandbox_timer_add_offset(unsigned long offset)
> sandbox_timer_offset += offset;
>  }
>
> -static int sandbox_timer_get_count(struct udevice *dev, u64 *count)
> +u64 notrace timer_early_get_count(void)
>  {
> -   *count = os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
> +   return os_get_nsec() / 1000 + sandbox_timer_offset * 1000;
> +}
> +
> +unsigned long notrace timer_early_get_rate(void)
> +{
> +   return 100;

Hard-coded?

> +}
> +
> +static notrace int sandbox_timer_get_count(struct udevice *dev, u64 *count)
> +{
> +   *count = timer_early_get_count();
>
> return 0;
>  }
> --

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


Re: [U-Boot] [PATCH 12/16] sandbox: Enable the early timer

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 9:36 AM, Simon Glass  wrote:
> Enable this so that tracing works with sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
>  configs/sandbox_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>

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


Re: [U-Boot] [PATCH 1/2] dm: core: Add uclass_first_device_err() to return a valid device

2016-02-16 Thread Bin Meng
Hi Simon,

On Fri, Feb 12, 2016 at 4:23 AM, Simon Glass  wrote:
> A common pattern is to call uclass_first_device() and then check if it
> actually returns a device. Add a new function which does this, returning
> an error if there are no devices in that uclass.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/core/uclass.c | 13 +
>  include/dm/uclass.h   | 15 +--
>  2 files changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/core/uclass.c b/drivers/core/uclass.c
> index 12095e7..1141ce1 100644
> --- a/drivers/core/uclass.c
> +++ b/drivers/core/uclass.c
> @@ -401,6 +401,19 @@ int uclass_first_device(enum uclass_id id, struct 
> udevice **devp)
> return uclass_get_device_tail(dev, ret, devp);
>  }
>
> +int uclass_first_device_err(enum uclass_id id, struct udevice **devp)

Or maybe another way is to change uclass_first_device() behavior to
return -ENODEV if device is not found? (move the return value test
logic into uclass_first_device)

> +{
> +   int ret;
> +
> +   ret = uclass_first_device(id, devp);
> +   if (ret)
> +   return ret;
> +   else if (!*devp)
> +   return -ENODEV;
> +
> +   return 0;
> +}
> +
>  int uclass_next_device(struct udevice **devp)
>  {
> struct udevice *dev = *devp;
> diff --git a/include/dm/uclass.h b/include/dm/uclass.h
> index bfbd27a..fd368b6 100644
> --- a/include/dm/uclass.h
> +++ b/include/dm/uclass.h
> @@ -200,18 +200,29 @@ int uclass_get_device_by_phandle(enum uclass_id id, 
> struct udevice *parent,
>   *
>   * @id: Uclass ID to look up
>   * @devp: Returns pointer to the first device in that uclass, or NULL if none
> - * @return 0 if OK (found or not found), -1 on error
> + * @return 0 if OK (found or not found), other -ve on error
>   */
>  int uclass_first_device(enum uclass_id id, struct udevice **devp);
>
>  /**
> + * uclass_first_device_err() - Get the first device in a uclass
> + *
> + * The device returned is probed if necessary, and ready for use
> + *
> + * @id: Uclass ID to look up
> + * @devp: Returns pointer to the first device in that uclass, or NULL if none
> + * @return 0 if found, -ENODEV if not found, other -ve on error
> + */
> +int uclass_first_device_err(enum uclass_id id, struct udevice **devp);
> +
> +/**
>   * uclass_next_device() - Get the next device in a uclass
>   *
>   * The device returned is probed if necessary, and ready for use
>   *
>   * @devp: On entry, pointer to device to lookup. On exit, returns pointer
>   * to the next device in the same uclass, or NULL if none
> - * @return 0 if OK (found or not found), -1 on error
> + * @return 0 if OK (found or not found), other -ve on error
>   */
>  int uclass_next_device(struct udevice **devp);
>
> --

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


Re: [U-Boot] [PATCH 02/30] dm: pci: Break out the common region display code

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Each region is displayed in almost the same way. Break out this common code
> into its own function.
>
> Signed-off-by: Simon Glass 
> ---
>
>  drivers/pci/pci_auto_common.c | 51 
> +++
>  1 file changed, 17 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/pci/pci_auto_common.c b/drivers/pci/pci_auto_common.c
> index 85c419e..a5c16b9 100644
> --- a/drivers/pci/pci_auto_common.c
> +++ b/drivers/pci/pci_auto_common.c
> @@ -62,6 +62,17 @@ int pciauto_region_allocate(struct pci_region *res, 
> pci_size_t size,
> return -1;
>  }
>
> +static void pciauto_show_region(const char *name, struct pci_region *region)
> +{
> +   pciauto_region_init(region);
> +   debug("PCI Autoconfig: Bus %s region: [0x%llx-0x%llx],\n"
> + "\t\tPhysical Memory [%llx-%llxx]\n", name,

While we are here, can we add '0x' prefix to Physical Memory output?

> + (unsigned long long)region->bus_start,
> + (unsigned long long)(region->bus_start + region->size - 1),
> + (unsigned long long)region->phys_start,
> + (unsigned long long)(region->phys_start + region->size - 1));

Why changing previous (u64) to (unsigned long long)?

> +}
> +
>  void pciauto_config_init(struct pci_controller *hose)
>  {
> int i;
> @@ -91,38 +102,10 @@ void pciauto_config_init(struct pci_controller *hose)
> }
>
>
> -   if (hose->pci_mem) {
> -   pciauto_region_init(hose->pci_mem);
> -
> -   debug("PCI Autoconfig: Bus Memory region: [0x%llx-0x%llx],\n"
> -  "\t\tPhysical Memory [%llx-%llxx]\n",
> -   (u64)hose->pci_mem->bus_start,
> -   (u64)(hose->pci_mem->bus_start + hose->pci_mem->size - 1),
> -   (u64)hose->pci_mem->phys_start,
> -   (u64)(hose->pci_mem->phys_start + hose->pci_mem->size - 
> 1));
> -   }
> -
> -   if (hose->pci_prefetch) {
> -   pciauto_region_init(hose->pci_prefetch);
> -
> -   debug("PCI Autoconfig: Bus Prefetchable Mem: 
> [0x%llx-0x%llx],\n"
> -  "\t\tPhysical Memory [%llx-%llx]\n",
> -   (u64)hose->pci_prefetch->bus_start,
> -   (u64)(hose->pci_prefetch->bus_start +
> -   hose->pci_prefetch->size - 1),
> -   (u64)hose->pci_prefetch->phys_start,
> -   (u64)(hose->pci_prefetch->phys_start +
> -   hose->pci_prefetch->size - 1));
> -   }
> -
> -   if (hose->pci_io) {
> -   pciauto_region_init(hose->pci_io);
> -
> -   debug("PCI Autoconfig: Bus I/O region: [0x%llx-0x%llx],\n"
> -  "\t\tPhysical Memory: [%llx-%llx]\n",
> -   (u64)hose->pci_io->bus_start,
> -   (u64)(hose->pci_io->bus_start + hose->pci_io->size - 1),
> -   (u64)hose->pci_io->phys_start,
> -   (u64)(hose->pci_io->phys_start + hose->pci_io->size - 1));
> -   }
> +   if (hose->pci_mem)
> +   pciauto_show_region("Memory", hose->pci_mem);
> +   if (hose->pci_prefetch)
> +   pciauto_show_region("Prefetchable Mem", hose->pci_mem);
> +   if (hose->pci_io)
> +   pciauto_show_region("I/O", hose->pci_io);
>  }
> --

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


Re: [U-Boot] [PATCH 03/30] dm: part: Correct a sandbox build warning

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Adjust the cast to avoid a warning when stdint.h is used.
>
> Signed-off-by: Simon Glass 
> ---
>
>  disk/part_efi.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index db5e7ed..7bd840f 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -658,11 +658,13 @@ int gpt_verify_partitions(struct blk_desc *dev_desc,
> gpt_part_size = le64_to_cpu(gpt_e[i].ending_lba) -
> le64_to_cpu(gpt_e[i].starting_lba) + 1;
> debug("size(LBA) - GPT: %8llu, ENV: %8llu ",
> - gpt_part_size, (u64) partitions[i].size);
> + (unsigned long long)gpt_part_size,
> + (unsigned long long)partitions[i].size);

Can you elaborate why this is needed?

>
> if (le64_to_cpu(gpt_part_size) != partitions[i].size) {
> error("Partition %s size: %llu does not match 
> %llu!\n",
> - efi_str, gpt_part_size, (u64) 
> partitions[i].size);
> + efi_str, (unsigned long long)gpt_part_size,
> + (unsigned long long)partitions[i].size);
> return -1;
> }
>
> @@ -678,12 +680,12 @@ int gpt_verify_partitions(struct blk_desc *dev_desc,
> /* Check if GPT and ENV start LBAs match */
> debug("start LBA - GPT: %8llu, ENV: %8llu\n",
>   le64_to_cpu(gpt_e[i].starting_lba),
> - (u64) partitions[i].start);
> + (unsigned long long)partitions[i].start);
>
> if (le64_to_cpu(gpt_e[i].starting_lba) != 
> partitions[i].start) {
> error("Partition %s start: %llu does not match 
> %llu!\n",
>   efi_str, le64_to_cpu(gpt_e[i].starting_lba),
> - (u64) partitions[i].start);
> + (unsigned long long)partitions[i].start);
> return -1;
> }
> }
> --

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


Re: [U-Boot] [PATCH 01/30] dm: Drop the block_dev_desc_t typedef

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Use 'struct' instead of a typdef. Also since 'struct block_dev_desc' is long
> and causes 80-column violations, rename it to struct blk_desc.
>
> Signed-off-by: Simon Glass 
> ---
>
>  api/api.c  |   2 +-
>  api/api_storage.c  |  14 ++---
>  board/cm5200/fwupdate.c|   2 +-
>  board/mpl/pip405/README|   4 +-
>  cmd/disk.c |   2 +-
>  cmd/fat.c  |   4 +-
>  cmd/gpt.c  |   8 +--
>  cmd/host.c |   4 +-
>  cmd/ide.c  |  22 
>  cmd/mmc.c  |   2 +-
>  cmd/part.c |   8 +--
>  cmd/read.c |   4 +-
>  cmd/reiser.c   |   4 +-
>  cmd/sata.c |  10 ++--
>  cmd/scsi.c |  12 ++---
>  cmd/unzip.c|   2 +-
>  cmd/usb.c  |   2 +-
>  cmd/usb_mass_storage.c |   6 +--
>  cmd/zfs.c  |   4 +-
>  common/env_fat.c   |   4 +-
>  common/fb_mmc.c|  12 ++---
>  common/spl/spl_ext.c   |   6 +--
>  common/spl/spl_fat.c   |   8 +--
>  common/spl/spl_sata.c  |   2 +-
>  common/spl/spl_usb.c   |   2 +-
>  common/usb_storage.c   |  22 
>  disk/part.c|  28 +-
>  disk/part_amiga.c  |  14 ++---
>  disk/part_dos.c|  19 +++
>  disk/part_efi.c|  38 ++---
>  disk/part_iso.c|  10 ++--
>  disk/part_mac.c|  19 ---
>  drivers/block/dwc_ahsata.c |   4 +-
>  drivers/block/sandbox.c|  12 ++---
>  drivers/block/systemace.c  |   8 +--
>  drivers/dfu/dfu_mmc.c  |   2 +-
>  drivers/mmc/mmc.c  |   4 +-
>  drivers/mmc/mmc_private.h  |   8 +--
>  drivers/mmc/mmc_write.c|   4 +-
>  fs/ext4/dev.c  |  53 +-
>  fs/ext4/ext4fs.c   |   2 +-
>  fs/fat/fat.c   |   6 +--
>  fs/fs.c|   6 +--
>  fs/reiserfs/dev.c  |  33 +---
>  fs/sandbox/sandboxfs.c |   4 +-
>  fs/ubifs/ubifs.c   |   2 +-
>  fs/zfs/dev.c   |  35 ++--
>  fs/zfs/zfs.c   |   2 +-
>  include/common.h   |   2 +-
>  include/ext4fs.h   |   6 +--
>  include/fat.h  |   4 +-
>  include/ide.h  |   6 +--
>  include/mmc.h  |   2 +-
>  include/part.h | 130 
> -
>  include/reiserfs.h |   2 +-
>  include/sandboxblockdev.h  |   2 +-
>  include/sandboxfs.h|   2 +-
>  include/sata.h |   2 +-
>  include/spl.h  |  10 ++--
>  include/systemace.h|   2 +-
>  include/ubifs_uboot.h  |   2 +-
>  include/usb.h  |   2 +-
>  include/usb_mass_storage.h |   2 +-
>  include/zfs_common.h   |   4 +-
>  lib/gunzip.c   |   2 +-
>  test/dm/usb.c  |   2 +-
>  66 files changed, 338 insertions(+), 331 deletions(-)
>

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


Re: [U-Boot] [PATCH 05/30] dm: part: Drop the common.h header

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> We should not include  in header files. Each C file should include
> it if needed.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/part.h | 1 -
>  1 file changed, 1 deletion(-)
>

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


Re: [U-Boot] [PATCH 06/30] dm: Add a new header for block devices

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> At present block devices are tied up with partitions. But not all block
> devices have partitions within them. They are in fact separate concepts.
>
> Create a separate blk.h header file for block devices.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/blk.h  | 71 
> ++
>  include/ide.h  | 12 ++
>  include/part.h | 49 +---
>  3 files changed, 74 insertions(+), 58 deletions(-)
>  create mode 100644 include/blk.h
>

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


Re: [U-Boot] [PATCH 07/30] dm: blk: Convert interface type to an enum

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Since these are sequentially numbered it makes sense to use an enum. It
> avoids having to maintain the maximum value, and provides a type we can use
> if it useful.

if it *is* useful?

>
> In fact the maximum value is not used. Rename it to COUNT, since MAX suggests
> it is the maximum valid value, but it is not.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/blk.h | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
>
> diff --git a/include/blk.h b/include/blk.h
> index 1e8334c..9ba7a62 100644
> --- a/include/blk.h
> +++ b/include/blk.h
> @@ -19,20 +19,23 @@ typedef ulong lbaint_t;
>  #define LBAFU "%" LBAFlength "u"
>
>  /* Interface types: */
> -#define IF_TYPE_UNKNOWN0
> -#define IF_TYPE_IDE1
> -#define IF_TYPE_SCSI   2
> -#define IF_TYPE_ATAPI  3
> -#define IF_TYPE_USB4
> -#define IF_TYPE_DOC5
> -#define IF_TYPE_MMC6
> -#define IF_TYPE_SD 7
> -#define IF_TYPE_SATA   8
> -#define IF_TYPE_HOST   9
> -#define IF_TYPE_MAX10  /* Max number of IF_TYPE_* supported 
> */
> +enum if_type_t {

I believe we should not add _t as it is not a typedef?

> +   IF_TYPE_UNKNOWN = 0,
> +   IF_TYPE_IDE,
> +   IF_TYPE_SCSI,
> +   IF_TYPE_ATAPI,
> +   IF_TYPE_USB,
> +   IF_TYPE_DOC,
> +   IF_TYPE_MMC,
> +   IF_TYPE_SD,
> +   IF_TYPE_SATA,
> +   IF_TYPE_HOST,
> +
> +   IF_TYPE_COUNT,  /* Number of interface types */
> +};
>
>  struct blk_desc {
> -   int if_type;/* type of the interface */
> +   enum if_type_t  if_type;/* type of the interface */
> int dev;/* device number */
> unsigned char   part_type;  /* partition type */
> unsigned char   target; /* target SCSI ID */
> --

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


Re: [U-Boot] [PATCH 09/30] dm: blk: Rename get_dev() to blk_get_dev()

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The current name is too generic. Add a 'blk_' prefix to aid searching and
> make its purpose clearer.
>
> Signed-off-by: Simon Glass 
> ---
>
>  api/api_storage.c | 12 +++-
>  cmd/gpt.c |  2 +-
>  cmd/read.c|  2 +-
>  common/fb_mmc.c   |  4 ++--
>  disk/part.c   |  4 ++--
>  include/part.h|  6 +++---
>  6 files changed, 16 insertions(+), 14 deletions(-)
>

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


Re: [U-Boot] [PATCH 08/30] dm: blk: Add comments to a few functions

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The block interface is not well documented in the code. Pick two important
> functions and add comments.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/part.h | 30 ++
>  1 file changed, 30 insertions(+)
>

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


Re: [U-Boot] [PATCH 2/3] common: env_flags: include common.h even for HOST_CC

2016-02-16 Thread Peter Robinson
>> When compiling with gcc 6 we get the following error due to ARRAY_SIZE being
>> defined elsewhere.
>>
>> common/env_flags.c:155: undefined reference to `ARRAY_SIZE'
>>
>> Signed-off-by: Peter Robinson 
>
> I'm going to take http://patchwork.ozlabs.org/patch/582527/ to fix this
> instead as I don't want to say that common.h must work in the case of
> USE_HOSTCC==true (I'm surprised it did, in fact).  Thanks!

What ever was pulled into RC2 works for me but I still needed my gcc6 patch.

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


Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

2016-02-16 Thread Masahiro Yamada
Hi Simon,


2016-01-29 1:39 GMT+09:00 Simon Glass :
> We need a way to support more than one board per binary in U-Boot with
> device tree. Various methods have been discussed. The one that seems to make
> the most sense is to adjust SPL so that it can load a FIT which contains
> U-Boot and several device tree binaries. This is how things with with Linux:
> load a FIT and select the correct device tree to pass to Linux.

I've just skimmed over the git-logs, but I am confused.


Please makes it clearer why this is useful.
In your way, how SPL is handled?

SPL is much more board-specific than U-Boot proper.
So, I assume SPL would remain as a per-board image
even after achieving one U-Boot proper for multi-boards.

Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper.

The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
generated by one-shot
and by one defconfig.


But, we would still have to do

make board_a_defconfig && make
make board_b_defconfig && make
make board_c_defconfig && make

to generate SPL for each of the three.
Is this correct?


Supposing my guess is correct, this series would not contribute
to decreasing the number of defconfig files.



Please explain which problem you are solving with this series.


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


[U-Boot] test/py main_signon

2016-02-16 Thread Michal Simek
Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.

Thanks,
Michal

U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)

Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB

Bad pattern found on console: main_signon

FAILED:
request = >

@pytest.fixture(scope='function')
def u_boot_console(request):
"""Generate the value of a test's u_boot_console fixture.

Args:
request: The pytest request.

Returns:
The fixture value.
"""

>   console.ensure_spawned()

test/py/conftest.py:311:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 

def ensure_spawned(self):
"""Ensure a connection to a correctly running U-Boot instance.

This may require spawning a new Sandbox process or resetting
target
hardware, as defined by the implementation sub-class.

This is an internal function and should not be called directly.

Args:
None.

Returns:
Nothing.
"""

if self.p:
return
try:
self.log.start_section('Starting U-Boot')
self.at_prompt = False
self.p = self.get_spawn()
# Real targets can take a long time to scroll large amounts of
# text if LCD is enabled. This value may need tweaking in the
# future, possibly per-test to be optimal. This works for 'help'
# on board 'seaboard'.
if not self.config.gdbserver:
self.p.timeout = 3
self.p.logfile_read = self.logstream
if self.config.buildconfig.get('config_spl', False) == 'y':
m = self.p.expect([pattern_u_boot_spl_signon] +
self.bad_patterns)
if m != 0:
raise Exception('Bad pattern found on console: ' +
>   self.bad_pattern_ids[m - 1])
E   Exception: Bad pattern found on
console: main_signon

test/py/u_boot_console_base.py:310: Exception

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


[U-Boot] [PATCH] test/py: only check for SPL signature if SPL uses serial output

2016-02-16 Thread Heiko Schocher
check for U-Boot SPL signature only if SPL really has
a serial output. So check if CONFIG_SPL_SERIAL_SUPPORT
is active in board config.

Signed-off-by: Heiko Schocher 
---
found this while trying test/py on the smartweb
board, which has SPL but no SPL serial output.

 test/py/u_boot_console_base.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index bc2bd76..f888d5c 100644
--- a/test/py/u_boot_console_base.py
+++ b/test/py/u_boot_console_base.py
@@ -304,10 +304,13 @@ class ConsoleBase(object):
 self.p.timeout = 3
 self.p.logfile_read = self.logstream
 if self.config.buildconfig.get('config_spl', False) == 'y':
-m = self.p.expect([pattern_u_boot_spl_signon] + 
self.bad_patterns)
-if m != 0:
-raise Exception('Bad pattern found on console: ' +
-self.bad_pattern_ids[m - 1])
+if self.config.buildconfig.get('config_spl_serial_support',
+   False) == 'y':
+m = self.p.expect([pattern_u_boot_spl_signon] +
+  self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])
 m = self.p.expect([pattern_u_boot_main_signon] + self.bad_patterns)
 if m != 0:
 raise Exception('Bad pattern found on console: ' +
-- 
2.5.0

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


Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

2016-02-16 Thread Tom Rini
On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
> Hi Simon,
> 
> 
> 2016-01-29 1:39 GMT+09:00 Simon Glass :
> > We need a way to support more than one board per binary in U-Boot with
> > device tree. Various methods have been discussed. The one that seems to make
> > the most sense is to adjust SPL so that it can load a FIT which contains
> > U-Boot and several device tree binaries. This is how things with with Linux:
> > load a FIT and select the correct device tree to pass to Linux.
> 
> I've just skimmed over the git-logs, but I am confused.
> 
> 
> Please makes it clearer why this is useful.
> In your way, how SPL is handled?
> 
> SPL is much more board-specific than U-Boot proper.
> So, I assume SPL would remain as a per-board image
> even after achieving one U-Boot proper for multi-boards.
> 
> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot proper.
> 
> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
> generated by one-shot
> and by one defconfig.
> 
> 
> But, we would still have to do
> 
> make board_a_defconfig && make
> make board_b_defconfig && make
> make board_c_defconfig && make
> 
> to generate SPL for each of the three.
> Is this correct?
> 
> 
> Supposing my guess is correct, this series would not contribute
> to decreasing the number of defconfig files.
> 
> 
> 
> Please explain which problem you are solving with this series.

It won't be just one board.  We need this so that we can replicate
existing (and very useful) functionality.  Today, am335x_evm_config
supports Beaglebone White, Beaglebone Black (could be faked enough for
U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
AM335x IDK EVM.  Each of these is different enough that they have their
own DT that we will need to pass up to U-Boot, and their own config
file.  With Simon's series we'll be able to move am335x_evm_config up to
DM in SPL and possibly even remove some of the am335x_evm subconfigs we
have today, once those specific options also move to Kconfig.

-- 
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 2/3] common: env_flags: include common.h even for HOST_CC

2016-02-16 Thread Tom Rini
On Tue, Feb 16, 2016 at 11:19:43AM +, Peter Robinson wrote:
> >> When compiling with gcc 6 we get the following error due to ARRAY_SIZE 
> >> being
> >> defined elsewhere.
> >>
> >> common/env_flags.c:155: undefined reference to `ARRAY_SIZE'
> >>
> >> Signed-off-by: Peter Robinson 
> >
> > I'm going to take http://patchwork.ozlabs.org/patch/582527/ to fix this
> > instead as I don't want to say that common.h must work in the case of
> > USE_HOSTCC==true (I'm surprised it did, in fact).  Thanks!
> 
> What ever was pulled into RC2 works for me but I still needed my gcc6 patch.

Somewhere along the lines, Linux stopped having compiler-gccN.h and just
has compiler-gcc.h and compiler-clang.h.  Would you feel up to making a
pass at migrating those changes or should I?  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 00/26] spl: Support loading a FIT image containing U-Boot

2016-02-16 Thread Masahiro Yamada
2016-02-16 21:17 GMT+09:00 Tom Rini :
> On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
>> Hi Simon,
>>
>>
>> 2016-01-29 1:39 GMT+09:00 Simon Glass :
>> > We need a way to support more than one board per binary in U-Boot with
>> > device tree. Various methods have been discussed. The one that seems to 
>> > make
>> > the most sense is to adjust SPL so that it can load a FIT which contains
>> > U-Boot and several device tree binaries. This is how things with with 
>> > Linux:
>> > load a FIT and select the correct device tree to pass to Linux.
>>
>> I've just skimmed over the git-logs, but I am confused.
>>
>>
>> Please makes it clearer why this is useful.
>> In your way, how SPL is handled?
>>
>> SPL is much more board-specific than U-Boot proper.
>> So, I assume SPL would remain as a per-board image
>> even after achieving one U-Boot proper for multi-boards.
>>
>> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot 
>> proper.
>>
>> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
>> generated by one-shot
>> and by one defconfig.
>>
>>
>> But, we would still have to do
>>
>> make board_a_defconfig && make
>> make board_b_defconfig && make
>> make board_c_defconfig && make
>>
>> to generate SPL for each of the three.
>> Is this correct?
>>
>>
>> Supposing my guess is correct, this series would not contribute
>> to decreasing the number of defconfig files.
>>
>>
>>
>> Please explain which problem you are solving with this series.
>
> It won't be just one board.  We need this so that we can replicate
> existing (and very useful) functionality.  Today, am335x_evm_config
> supports Beaglebone White, Beaglebone Black (could be faked enough for
> U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
> AM335x IDK EVM.  Each of these is different enough that they have their
> own DT that we will need to pass up to U-Boot, and their own config
> file.  With Simon's series we'll be able to move am335x_evm_config up to
> DM in SPL and possibly even remove some of the am335x_evm subconfigs we
> have today, once those specific options also move to Kconfig.

So, this series is useful to merge some boards
that are different enough to have their own DT,
but that are similar enough to share one SPL binary, correct?



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


Re: [U-Boot] i.MX286 U-Boot fails with code HTLLCL0x8050100b

2016-02-16 Thread Stuart Longland
On 15/02/16 14:09, Stuart Longland wrote:
> I ask again: Is there somewhere else I should be looking for the cause
> of the above issue?

Well, found my issue in the end I think.  In exasperation I dd'ed one of
my working SD card images, proved that the machine booted, then dd'ed
the newly build U-Boot image over the top of the old U-Boot partition.

It worked.

So I'll put this down to the i.MX286 boot ROM being *exceptionally*
picky about partition placement.  If things aren't *exactly* right,
it'll flatly refuse to work.

I might see if I can reproduce the bad image and hex-dump it to better
understand what was "wrong".
-- 
Stuart Longland
Systems Engineer
 _ ___
\  /|_) |   T: +61 7 3535 9619
 \/ | \ | 38b Douglas StreetF: +61 7 3535 9699
   SYSTEMSMilton QLD 4064   http://www.vrt.com.au


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


[U-Boot] [PATCH] ARM: zynq: Enable u-boot,dm-pre-reloc for qspi

2016-02-16 Thread Nathan Rossi
Enable u-boot,dm-pre-reloc for qspi for zc706, zed and microzed.

Signed-off-by: Nathan Rossi 
Cc: Albert Aribaud 
Cc: Michal Simek 
Cc: Simon Glass 
---
 arch/arm/dts/zynq-microzed.dts | 1 +
 arch/arm/dts/zynq-zc706.dts| 1 +
 arch/arm/dts/zynq-zed.dts  | 1 +
 3 files changed, 3 insertions(+)

diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
index e841a1d..793ab44 100644
--- a/arch/arm/dts/zynq-microzed.dts
+++ b/arch/arm/dts/zynq-microzed.dts
@@ -24,6 +24,7 @@
 };
 
 &qspi {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
index 1ba3a1c..1610520 100644
--- a/arch/arm/dts/zynq-zc706.dts
+++ b/arch/arm/dts/zynq-zc706.dts
@@ -306,6 +306,7 @@
 };
 
 &qspi {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
index 5ec59e2..ec9b2f7 100644
--- a/arch/arm/dts/zynq-zed.dts
+++ b/arch/arm/dts/zynq-zed.dts
@@ -61,6 +61,7 @@
 };
 
 &qspi {
+   u-boot,dm-pre-reloc;
status = "okay";
 };
 
-- 
2.7.0

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


Re: [U-Boot] test/py main_signon

2016-02-16 Thread Heiko Schocher

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.


Does this board has SPL support without SPL serial output?

If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/

Thanks!

bye,
Heiko


Thanks,
Michal

U-Boot 2016.03-rc2 (Feb 16 2016 - 13:10:03 +0100)

Model: Zynq ZC702 Development Board
Board: Xilinx Zynq
I2C:   ready
DRAM:  ECC disabled 1 GiB

Bad pattern found on console: main_signon

FAILED:
request = >

 @pytest.fixture(scope='function')
 def u_boot_console(request):
 """Generate the value of a test's u_boot_console fixture.

 Args:
 request: The pytest request.

 Returns:
 The fixture value.
 """


   console.ensure_spawned()


test/py/conftest.py:311:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _

self = 

 def ensure_spawned(self):
 """Ensure a connection to a correctly running U-Boot instance.

 This may require spawning a new Sandbox process or resetting
target
 hardware, as defined by the implementation sub-class.

 This is an internal function and should not be called directly.

 Args:
 None.

 Returns:
 Nothing.
 """

 if self.p:
 return
 try:
 self.log.start_section('Starting U-Boot')
 self.at_prompt = False
 self.p = self.get_spawn()
 # Real targets can take a long time to scroll large amounts of
 # text if LCD is enabled. This value may need tweaking in the
 # future, possibly per-test to be optimal. This works for 'help'
 # on board 'seaboard'.
 if not self.config.gdbserver:
 self.p.timeout = 3
 self.p.logfile_read = self.logstream
 if self.config.buildconfig.get('config_spl', False) == 'y':
 m = self.p.expect([pattern_u_boot_spl_signon] +
self.bad_patterns)
 if m != 0:
 raise Exception('Bad pattern found on console: ' +

   self.bad_pattern_ids[m - 1])

E   Exception: Bad pattern found on
console: main_signon

test/py/u_boot_console_base.py:310: Exception

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



--
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 00/26] spl: Support loading a FIT image containing U-Boot

2016-02-16 Thread Tom Rini
On Tue, Feb 16, 2016 at 09:30:44PM +0900, Masahiro Yamada wrote:
> 2016-02-16 21:17 GMT+09:00 Tom Rini :
> > On Tue, Feb 16, 2016 at 08:34:59PM +0900, Masahiro Yamada wrote:
> >> Hi Simon,
> >>
> >>
> >> 2016-01-29 1:39 GMT+09:00 Simon Glass :
> >> > We need a way to support more than one board per binary in U-Boot with
> >> > device tree. Various methods have been discussed. The one that seems to 
> >> > make
> >> > the most sense is to adjust SPL so that it can load a FIT which contains
> >> > U-Boot and several device tree binaries. This is how things with with 
> >> > Linux:
> >> > load a FIT and select the correct device tree to pass to Linux.
> >>
> >> I've just skimmed over the git-logs, but I am confused.
> >>
> >>
> >> Please makes it clearer why this is useful.
> >> In your way, how SPL is handled?
> >>
> >> SPL is much more board-specific than U-Boot proper.
> >> So, I assume SPL would remain as a per-board image
> >> even after achieving one U-Boot proper for multi-boards.
> >>
> >> Let's say we want to support Board-A, Board-B, Board-C with one U-Boot 
> >> proper.
> >>
> >> The U-Boot proper + FIT (including DTB-A, DTB-B, DTB-C) would be
> >> generated by one-shot
> >> and by one defconfig.
> >>
> >>
> >> But, we would still have to do
> >>
> >> make board_a_defconfig && make
> >> make board_b_defconfig && make
> >> make board_c_defconfig && make
> >>
> >> to generate SPL for each of the three.
> >> Is this correct?
> >>
> >>
> >> Supposing my guess is correct, this series would not contribute
> >> to decreasing the number of defconfig files.
> >>
> >>
> >>
> >> Please explain which problem you are solving with this series.
> >
> > It won't be just one board.  We need this so that we can replicate
> > existing (and very useful) functionality.  Today, am335x_evm_config
> > supports Beaglebone White, Beaglebone Black (could be faked enough for
> > U-Boot), AM335x GP EVM, AM335x EVM SK and if you tweak the default UART
> > AM335x IDK EVM.  Each of these is different enough that they have their
> > own DT that we will need to pass up to U-Boot, and their own config
> > file.  With Simon's series we'll be able to move am335x_evm_config up to
> > DM in SPL and possibly even remove some of the am335x_evm subconfigs we
> > have today, once those specific options also move to Kconfig.
> 
> So, this series is useful to merge some boards
> that are different enough to have their own DT,
> but that are similar enough to share one SPL binary, correct?

Yes.  It _may_ even be useful later on to support a more broad set of
boards than we do today (ie it's not impossible that one binary could
support the TI AM43xx EVMs as well, or all TI EVMs that have the EEPROM
that identifies the model, for some narrow scope of boot devices).

-- 
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 10/30] dm: blk: Rename get_device() to blk_get_device_str()

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The current name is too generic. The function returns a block device based
> on a provided string. Rename it to aid searching and make its purpose
> clearer. Also add a few comments.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/part.c |  6 +++---
>  cmd/unzip.c|  2 +-
>  cmd/usb_mass_storage.c |  2 +-
>  disk/part.c|  6 +++---
>  include/part.h | 34 ++
>  test/dm/usb.c  |  2 +-
>  6 files changed, 39 insertions(+), 13 deletions(-)
>

Reviewed-by: Bin Meng 

One comment below

> diff --git a/cmd/part.c b/cmd/part.c
> index a572aab..f05699d 100644
> --- a/cmd/part.c
> +++ b/cmd/part.c
> @@ -81,7 +81,7 @@ static int do_part_list(int argc, char * const argv[])
> return CMD_RET_USAGE;
> }
>
> -   ret = get_device(argv[0], argv[1], &desc);
> +   ret = blk_get_device_str(argv[0], argv[1], &desc);
> if (ret < 0)
> return 1;
>
> @@ -128,7 +128,7 @@ static int do_part_start(int argc, char * const argv[])
>
> part = simple_strtoul(argv[2], NULL, 0);
>
> -   ret = get_device(argv[0], argv[1], &desc);
> +   ret = blk_get_device_str(argv[0], argv[1], &desc);
> if (ret < 0)
> return 1;
>
> @@ -162,7 +162,7 @@ static int do_part_size(int argc, char * const argv[])
>
> part = simple_strtoul(argv[2], NULL, 0);
>
> -   ret = get_device(argv[0], argv[1], &desc);
> +   ret = blk_get_device_str(argv[0], argv[1], &desc);
> if (ret < 0)
> return 1;
>
> diff --git a/cmd/unzip.c b/cmd/unzip.c
> index 5be1566..588fa75 100644
> --- a/cmd/unzip.c
> +++ b/cmd/unzip.c
> @@ -53,7 +53,7 @@ static int do_gzwrite(cmd_tbl_t *cmdtp, int flag,
>
> if (argc < 5)
> return CMD_RET_USAGE;
> -   ret = get_device(argv[1], argv[2], &bdev);
> +   ret = blk_get_device_str(argv[1], argv[2], &bdev);
> if (ret < 0)
> return CMD_RET_FAILURE;
>
> diff --git a/cmd/usb_mass_storage.c b/cmd/usb_mass_storage.c
> index 03b7e21..fcac389 100644
> --- a/cmd/usb_mass_storage.c
> +++ b/cmd/usb_mass_storage.c
> @@ -69,7 +69,7 @@ static int ums_init(const char *devtype, const char 
> *devnums)
> if (!devnum)
> break;
>
> -   ret = get_device(devtype, devnum, &block_dev);
> +   ret = blk_get_device_str(devtype, devnum, &block_dev);
> if (ret < 0)
> goto cleanup;
>
> diff --git a/disk/part.c b/disk/part.c
> index 2466c3e..700e505 100644
> --- a/disk/part.c
> +++ b/disk/part.c
> @@ -449,8 +449,8 @@ int get_partition_info(struct blk_desc *dev_desc, int 
> part,
> return -1;
>  }
>
> -int get_device(const char *ifname, const char *dev_hwpart_str,
> -  struct blk_desc **dev_desc)
> +int blk_get_device_str(const char *ifname, const char *dev_hwpart_str,
> +  struct blk_desc **dev_desc)
>  {
> char *ep;
> char *dup_str = NULL;
> @@ -598,7 +598,7 @@ int get_device_and_partition(const char *ifname, const 
> char *dev_part_str,
> }
>
> /* Look up the device */
> -   dev = get_device(ifname, dev_str, dev_desc);
> +   dev = blk_get_device_str(ifname, dev_str, dev_desc);
> if (dev < 0)
> goto cleanup;
>
> diff --git a/include/part.h b/include/part.h
> index ddc4422..d05b48b 100644
> --- a/include/part.h
> +++ b/include/part.h
> @@ -101,8 +101,34 @@ int get_partition_info(struct blk_desc *dev_desc, int 
> part,
>  void print_part(struct blk_desc *dev_desc);
>  void init_part(struct blk_desc *dev_desc);
>  void dev_print(struct blk_desc *dev_desc);
> -int get_device(const char *ifname, const char *dev_str,
> -  struct blk_desc **dev_desc);
> +
> +/**
> + * blk_get_device_str() - Get a block device given its interface/ hw 
> partition

nits: need one space before /, or remove space before 'hw'?

I am not sure if blk_get_device_str() is a good name, but I cannot
think of a better name..

> + *
> + * Each interface allocates its own devices and typically struct blk_desc is
> + * contained with the interface's data structure. There is no global
> + * numbering for block devices, so the interface name must be provided.
> + *
> + * The hardware parition is not related to the normal software partitioning
> + * of a device - each hardware partition is effectively a separately
> + * accessible block device. When a hardware parition is selected on MMC the
> + * other hardware partitions become inaccessible. The same block device is
> + * used to access all hardware partitions, but its capacity may change when a
> + * different hardware partition is selected.
> + *
> + * When a hardware partition number is given, the block device switches to
> + * that hardware partition.
> + *
> + * @ifname:Interface name (e.g. "ide", "scsi")
> 

Re: [U-Boot] [PATCH] Gracefully handle 64-bit Load Address and Entry Point Address mkimage parameters

2016-02-16 Thread William Cohen
On 02/15/2016 06:34 AM, Wolfgang Denk wrote:
> Dear William,
> 
> In message <1455506732-22307-1-git-send-email-wco...@redhat.com> you wrote:
>>
>> Recent MIPS Linux kernels are using a 64-bit value for the load
>> address (0x8001) for the Creator CI20 board kernel.  When
>> this argument was passed to the mkimage program running on a 32-bit
>> machine such as the Creator CI20 board the load address was
>> incorrectly obtained from the first half of the argument, 0x
>> by the strtoul.  The mkimage should be able to tolerate the longer,
>> 64-bit signed version of the arguments with the use of strtoull.
> 
> Hm...  I think we have multiple problems here.

Hi,

The write up in the patch wasn't as clear as it should have been. I
have revised the patch to try to make the reason for this patch
clearer.  The MIP Linux kernel is using sign-extending 32-bit values
to 64-bit values, so the truncation of the strtoll values to 32-bits
is actually desired. The revised patch now passes the linux kernel
checkpatch.pl checks.  I will be resending the patch in a moment.

-Will
> 
> First, the old legacy uImage header usersd 32 bit data types for the
> addresses.  This is a binary data structure, and there is no way to
> extend it for 64 bit addresses without breaking compatibility.
> 
> 
>> -params.addr = strtoul (*++argv, &ptr, 16);
>> +params.addr = strtoull (*++argv, &ptr, 16);
> 
> I don't see what you win here...  strtoull() returns unsigned long long,
> but params.addr is an unsigned int, so the value will be truncated to
> 32 bit.  Are you sure this is what you want?
> 
>>  fprintf (stderr,
>>  "%s: invalid load address %s\n",
>> @@ -146,7 +146,7 @@ int main(int argc, char **argv)
>>  case 'e':
>>  if (--argc <= 0)
>>  usage ();
>> -params.ep = strtoul (*++argv, &ptr, 16);
>> +params.ep = strtoull (*++argv, &ptr, 16);
> 
> Ditto...
> 
> 
> Also please note that your patch triggers a number of checkpatch
> warnings and an error, especially:
> 
> WARNING: space prohibited between function name and open parenthesis '('
> #108: FILE: tools/mkimage.c:132:
> +   params.addr = strtoull (*++argv, &ptr, 16);
> 
> WARNING: space prohibited between function name and open parenthesis '('
> #117: FILE: tools/mkimage.c:149:
> +   params.ep = strtoull (*++argv, &ptr, 16);
> 
> ERROR: Missing Signed-off-by: line(s)
> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

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


[U-Boot] [PATCH] Gracefully handle 64-bit signed-extended 32-bit Load addresses

2016-02-16 Thread William Cohen
To follow the MIPS 32-bit and 64-bit memory map conventions (*) recent
MIPS Linux kernels are using a 64-bit sign extended value
(0x8001) for the 32-bit load address (0x8001) of the
Creator CI20 board kernel.  When this 64-bit argument was passed to
mkimage running on a 32-bit machine such as the Creator CI20 board the
load address was incorrectly formed from the upper 32-bit sign-extend
bits (0x) by the strtoul instead of from the lower 32-bits
(0x8001).  The mkimage should be able to tolerate the longer
sign-extended 64-bit version of the 32-bit arguments with the use of
strtoull.  Use of the strtoll in place of the strtol in mkimage.c
resolves the issue of self hosted kernel builds for the Creator CI20
board (+) and (++).

(*) 
http://techpubs.sgi.com/library/dynaweb_docs/0620/SGI_Developer/books/DevDriver_PG/sgi_html/ch01.html
(+) https://github.com/MIPS/CI20_linux/issues/23
(++) https://github.com/MIPS/CI20_linux/issues/22

Signed-off-by: William Cohen 
---
 tools/mkimage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 8f8b6df..facebcd 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -129,7 +129,7 @@ int main(int argc, char **argv)
case 'a':
if (--argc <= 0)
usage ();
-   params.addr = strtoul (*++argv, &ptr, 16);
+   params.addr = strtoull(*++argv, &ptr, 16);
if (*ptr) {
fprintf (stderr,
"%s: invalid load address %s\n",
@@ -146,7 +146,7 @@ int main(int argc, char **argv)
case 'e':
if (--argc <= 0)
usage ();
-   params.ep = strtoul (*++argv, &ptr, 16);
+   params.ep = strtoull(*++argv, &ptr, 16);
if (*ptr) {
fprintf (stderr,
"%s: invalid entry point %s\n",
-- 
2.5.0

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


Re: [U-Boot] [PATCH 11/30] dm: blk: Rename get_device_and_partition()

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Rename this function to blk_get_device_part_str(). This is a better name
> because it makes it clear that the function returns a block device and
> parses a string.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/disk.c   |  2 +-
>  cmd/fat.c|  4 ++--
>  cmd/part.c   |  2 +-
>  cmd/reiser.c |  4 ++--
>  cmd/zfs.c|  4 ++--
>  common/env_fat.c |  4 ++--
>  disk/part.c  |  2 +-
>  fs/fs.c  |  2 +-
>  fs/ubifs/ubifs.c |  2 +-
>  include/part.h   | 38 --
>  10 files changed, 49 insertions(+), 15 deletions(-)
>

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


Re: [U-Boot] [PATCH 12/30] dm: part: Add a cast to avoid a compiler warning

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> In part_amiga.c the name is unsigned by bcpl_strcpy() requires a signed
> pointer. Add a cast to fix the warning.

is unsigned *but* bcpl_strcpy() ?

>
> Signed-off-by: Simon Glass 
> ---
>
>  disk/part_amiga.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH 13/30] dm: sandbox: Enable all partition types

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> It is useful to have sandbox build as much code as possible to avoid having
> to build every board to detect build errors. Also we may add tests for some
> more partition types at some point.
>
> Enable all partition types in sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/configs/sandbox.h | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>

Reviewed-by: Bin Meng 

One nits below:

> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
> index 4bffd8d..0f02839 100644
> --- a/include/configs/sandbox.h
> +++ b/include/configs/sandbox.h
> @@ -53,8 +53,11 @@
>
>  #define CONFIG_CMD_GPT
>  #define CONFIG_PARTITION_UUIDS
> -#define CONFIG_EFI_PARTITION
> +#define CONFIG_MAC_PARTITION
>  #define CONFIG_DOS_PARTITION
> +#define CONFIG_ISO_PARTITION
> +#define CONFIG_AMIGA_PARTITION
> +#define CONFIG_EFI_PARTITION
>

Guess we can use proper alphabetical order for these partitions? Like
AMIGA, DOS, EFI, ISO, MAC ..

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


Re: [U-Boot] [PATCH v2 1/3] mmc: uniphier: add driver for UniPhier SD/MMC host controller

2016-02-16 Thread Marek Vasut
On 02/16/2016 09:18 AM, Masahiro Yamada wrote:
> Hi Marek,

Hi!

[...]

>>> +static int uniphier_sd_wait_irq(struct uniphier_sd_priv *priv,
>>> + unsigned int reg, u32 flag)
>>> +{
>>> + long wait = 100;
>>> + int ret;
>>
>> Replace this with wait_for_bit() please .
> 
> 
> It cannot check error during the loop.
> 
> I want to check the error flags in the loop
> because no reason to wait for the time-out
> if some error happens.

You have a point there.

I wonder if it'd make sense to extend the wait_for_bit with some
callback maybe ?

>>> + while (!(readl(priv->regbase + reg) & flag)) {
>>> + if (wait-- < 0) {
>>> + pr_err("timeout\n");
>>> + return -ETIMEDOUT;
>>> + }
>>> +
>>> + ret = uniphier_sd_check_error(priv);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + udelay(1);
>>> + }
>>> +
>>> + return 0;
>>> +}
>>
>> [...]
>>
>>> +static void uniphier_sd_dma_start(struct uniphier_sd_priv *priv,
>>> +   dma_addr_t dma_addr)
>>> +{
>>> + u32 tmp;
>>> +
>>> + writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO1);
>>> + writel(0, priv->regbase + UNIPHIER_SD_DMA_INFO2);
>>> +
>>> + /* enable DMA */
>>> + tmp = readl(priv->regbase + UNIPHIER_SD_EXTMODE);
>>> + tmp |= UNIPHIER_SD_EXTMODE_DMA_EN;
>>> + writel(tmp, priv->regbase + UNIPHIER_SD_EXTMODE);
>>
>> I'd say, use setbits_le32(), but could it be that this driver is kept in
>> sync with Linux ?
> 
> Yes, I am developing the MMC driver
> for Linux as well as U-Boot at the same time.
> 
> This is the U-Boot counter-part,
> although the Linux one has not been upstreamed yet.
> 
> It can save my time to copy-paste code snippets between the two.
> 
> I want to sync as much code as possible.

Understood, thanks!

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


Re: [U-Boot] [PATCH 14/30] dm: part: Convert partition API use to linker lists

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> We can use linker lists instead of explicitly declaring each function.
> This makes the code shorter by avoiding switch() statements and lots of
> header file declarations.
>
> While this does clean up the code it introduces a few code issues with SPL.
> SPL never needs to print partition information since this all happens from
> commands. SPL mostly doesn't need to obtain information about a partition
> either, except in a few cases. Add these cases so that the code will be
> dropped from each partition driver when not needed. This avoids code bloat.
>
> I think this is still a win, since it is not a bad thing to be explicit
> about which features are used in SPL. But others may like to weigh in.
>
> Signed-off-by: Simon Glass 
> ---
>
>  disk/part.c   | 184 
> +-
>  disk/part_amiga.c |  16 +++--
>  disk/part_dos.c   |   9 ++-
>  disk/part_efi.c   |  10 ++-
>  disk/part_iso.c   |  16 +++--
>  disk/part_mac.c   |  16 +++--
>  include/part.h|  79 ++-
>  7 files changed, 157 insertions(+), 173 deletions(-)
>

[snip]

> diff --git a/disk/part_amiga.c b/disk/part_amiga.c
> index 5702c95..0f569f0 100644
> --- a/disk/part_amiga.c
> +++ b/disk/part_amiga.c
> @@ -207,7 +207,7 @@ struct bootcode_block *get_bootcode(struct blk_desc 
> *dev_desc)
>   * Test if the given partition has an Amiga partition table/Rigid
>   * Disk block
>   */
> -int test_part_amiga(struct blk_desc *dev_desc)
> +static int test_part_amiga(struct blk_desc *dev_desc)
>  {
>  struct rigid_disk_block *rdb;
>  struct bootcode_block *bootcode;
> @@ -291,8 +291,8 @@ static struct partition_block *find_partition(struct 
> blk_desc *dev_desc,
>  /*
>   * Get info about a partition
>   */
> -int get_partition_info_amiga(struct blk_desc *dev_desc, int part,
> -disk_partition_t *info)
> +static int get_partition_info_amiga(struct blk_desc *dev_desc, int part,
> +   disk_partition_t *info)
>  {
>  struct partition_block *p = find_partition(dev_desc, part-1);
>  struct amiga_part_geometry *g;
> @@ -319,7 +319,7 @@ int get_partition_info_amiga(struct blk_desc *dev_desc, 
> int part,
>  return 0;
>  }
>
> -void print_part_amiga(struct blk_desc *dev_desc)
> +static void print_part_amiga(struct blk_desc *dev_desc)
>  {
>  struct rigid_disk_block *rdb;
>  struct bootcode_block *boot;
> @@ -379,4 +379,12 @@ void print_part_amiga(struct blk_desc *dev_desc)
>  }
>  }
>
> +U_BOOT_PART_TYPE(amiga) = {
> +   .name   = "AMIGA",
> +   .part_type  = PART_TYPE_AMIGA,
> +   .get_info   = get_partition_info_amiga,
> +   .print  = print_part_amiga,
> +   .test   = test_part_amiga,
> +};
> +
>  #endif
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index ea0315c..7567ed3 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -87,7 +87,7 @@ static int test_block_type(unsigned char *buffer)
>  }
>
>
> -int test_part_dos(struct blk_desc *dev_desc)
> +static int test_part_dos(struct blk_desc *dev_desc)
>  {
> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
>
> @@ -295,5 +295,12 @@ int get_partition_info_dos(struct blk_desc *dev_desc, 
> int part,
> return get_partition_info_extended(dev_desc, 0, 0, 1, part, info, 0);
>  }
>
> +U_BOOT_PART_TYPE(dos) = {
> +   .name   = "DOS",
> +   .part_type  = PART_TYPE_DOS,
> +   .get_info   = part_get_info_ptr(get_partition_info_dos),

Does this compile?

> +   .print  = part_print_ptr(print_part_dos),

and this?

> +   .test   = test_part_dos,
> +};
>
>  #endif
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index 7bd840f..6f80877 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -319,7 +319,7 @@ int get_partition_info_efi_by_name(struct blk_desc 
> *dev_desc,
> return -2;
>  }
>
> -int test_part_efi(struct blk_desc *dev_desc)
> +static int test_part_efi(struct blk_desc *dev_desc)
>  {
> ALLOC_CACHE_ALIGN_BUFFER_PAD(legacy_mbr, legacymbr, 1, 
> dev_desc->blksz);
>
> @@ -953,4 +953,12 @@ static int is_pte_valid(gpt_entry * pte)
> return 1;
> }
>  }
> +
> +U_BOOT_PART_TYPE(efi) = {
> +   .name   = "EFI",
> +   .part_type  = PART_TYPE_EFI,
> +   .get_info   = part_get_info_ptr(get_partition_info_efi),
> +   .print  = part_print_ptr(print_part_efi),

and these?

> +   .test   = test_part_efi,
> +};
>  #endif
> diff --git a/disk/part_iso.c b/disk/part_iso.c
> index 2984df5..1d72d23 100644
> --- a/disk/part_iso.c
> +++ b/disk/part_iso.c
> @@ -217,14 +217,13 @@ found:
> return 0;
>  }
>
> -int get_partition_info_iso(struct blk_desc *dev_desc, int part_num,
> -  disk_partition_t *info)
> +static int get_partition_info_iso(struct blk_d

Re: [U-Boot] [PATCH 15/30] dm: part: Rename some partition functions

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Rename three partition functions so that they start with part_. This makes
> it clear what they relate to.
>
> Signed-off-by: Simon Glass 
> ---
>
>  board/cm5200/fwupdate.c   |  2 +-
>  cmd/ide.c |  6 +++---
>  cmd/mmc.c |  2 +-
>  cmd/part.c|  8 
>  cmd/read.c|  2 +-
>  cmd/sata.c|  6 +++---
>  cmd/scsi.c|  6 +++---
>  cmd/usb.c |  4 ++--
>  common/fb_mmc.c   | 10 +-
>  common/spl/spl_ext.c  |  6 ++
>  common/spl/spl_mmc.c  |  2 +-
>  common/usb_storage.c  |  2 +-
>  disk/part.c   | 12 ++--
>  disk/part_amiga.c |  4 ++--
>  disk/part_dos.c   | 19 +--
>  disk/part_efi.c   | 10 +-
>  disk/part_iso.c   | 17 +
>  disk/part_mac.c   |  4 ++--
>  drivers/block/pata_bfin.c |  2 +-
>  drivers/block/sandbox.c   |  2 +-
>  drivers/block/systemace.c |  2 +-
>  drivers/dfu/dfu_mmc.c |  2 +-
>  drivers/mmc/mmc.c |  2 +-
>  fs/fat/fat.c  |  2 +-
>  include/part.h| 21 ++---
>  25 files changed, 76 insertions(+), 79 deletions(-)
>

[snip]

> diff --git a/disk/part_amiga.c b/disk/part_amiga.c
> index 0f569f0..d323b4b 100644
> --- a/disk/part_amiga.c
> +++ b/disk/part_amiga.c
> @@ -291,7 +291,7 @@ static struct partition_block *find_partition(struct 
> blk_desc *dev_desc,
>  /*
>   * Get info about a partition
>   */
> -static int get_partition_info_amiga(struct blk_desc *dev_desc, int part,
> +static int part_get_info_amiga(struct blk_desc *dev_desc, int part,
> disk_partition_t *info)
>  {
>  struct partition_block *p = find_partition(dev_desc, part-1);
> @@ -382,7 +382,7 @@ static void print_part_amiga(struct blk_desc *dev_desc)
>  U_BOOT_PART_TYPE(amiga) = {
> .name   = "AMIGA",
> .part_type  = PART_TYPE_AMIGA,
> -   .get_info   = get_partition_info_amiga,
> +   .get_info   = part_get_info_amiga,
> .print  = print_part_amiga,
> .test   = test_part_amiga,

Can we rename these two to: part_print_amiga and part_test_amiga too?

>  };
> diff --git a/disk/part_dos.c b/disk/part_dos.c
> index 7567ed3..4a56391 100644
> --- a/disk/part_dos.c
> +++ b/disk/part_dos.c
> @@ -167,11 +167,10 @@ static void print_partition_extended(struct blk_desc 
> *dev_desc,
>
>  /*  Print a partition that is relative to its Extended partition table
>   */
> -static int get_partition_info_extended(struct blk_desc *dev_desc,
> -  lbaint_t ext_part_sector,
> -  lbaint_t relative, int part_num,
> -  int which_part, disk_partition_t *info,
> -  unsigned int disksig)
> +static int part_get_info_extended(struct blk_desc *dev_desc,
> + lbaint_t ext_part_sector, lbaint_t relative,
> + int part_num, int which_part,
> + disk_partition_t *info, unsigned int 
> disksig)
>  {
> ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
> dos_partition_t *pt;
> @@ -259,7 +258,7 @@ static int get_partition_info_extended(struct blk_desc 
> *dev_desc,
> lbaint_t lba_start
> = le32_to_int (pt->start4) + relative;
>
> -   return get_partition_info_extended (dev_desc, 
> lba_start,
> +   return part_get_info_extended(dev_desc, lba_start,
>  ext_part_sector == 0 ? lba_start : relative,
>  part_num, which_part, info, disksig);
> }
> @@ -289,16 +288,16 @@ void print_part_dos(struct blk_desc *dev_desc)
> print_partition_extended(dev_desc, 0, 0, 1, 0);
>  }
>
> -int get_partition_info_dos(struct blk_desc *dev_desc, int part,
> -  disk_partition_t *info)
> +int part_get_info_dos(struct blk_desc *dev_desc, int part,
> + disk_partition_t *info)
>  {
> -   return get_partition_info_extended(dev_desc, 0, 0, 1, part, info, 0);
> +   return part_get_info_extended(dev_desc, 0, 0, 1, part, info, 0);
>  }
>
>  U_BOOT_PART_TYPE(dos) = {
> .name   = "DOS",
> .part_type  = PART_TYPE_DOS,
> -   .get_info   = part_get_info_ptr(get_partition_info_dos),
> +   .get_info   = part_get_info_ptr(part_get_info_dos),
> .print  = part_print_ptr(print_part_dos),
> .test   = test_part_dos,

ditto.

>  };
> diff --git a/disk/part_efi.c b/disk/part_efi.c
> index 6f80877..eed8593 100644
> --- a/disk/part_efi.c
> +++ b/disk/part_efi.c
> @@ -237,8 +237,8 @@ void

Re: [U-Boot] [PATCH 16/30] dm: cbfs: Fix handling of invalid type

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> The comment for file_cbfs_type() says that it returns 0 for an invalid type.
> The code appears to check for -1, except that it uses an unsigned variable
> to store the type. This results in a warning on 64-bit machines.
>
> Adjust it to make the meaning clearer. Continue to handle the -1 case since
> it may be needed.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/cbfs.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index 35d8a7a..cdfc9b6 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -103,7 +103,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> printf(" size  type  name\n");
> printf("--\n");
> while (file) {
> -   u32 type = file_cbfs_type(file);
> +   int type = file_cbfs_type(file);

but file_cbfs_type() returns u32 as its type..

> char *type_name = NULL;
> const char *filename = file_cbfs_name(file);
>
> @@ -140,7 +140,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> case CBFS_COMPONENT_CMOS_LAYOUT:
> type_name = "cmos layout";
> break;
> -   case -1UL:
> +   case -1:

What about: case (u32)-1UL:

> type_name = "null";
> break;
> }
> --

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


Re: [U-Boot] [PATCH 17/30] dm: sandbox: Enable cbfs and cramfs

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> Enable these two filesystems to provide better build coverage in sandbox.
>
> Signed-off-by: Simon Glass 
> ---
>
>  include/configs/sandbox.h | 3 +++
>  1 file changed, 3 insertions(+)

Reviewed-by: Bin Meng 

One comment below:

>
> diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
> index 0f02839..2268c4e 100644
> --- a/include/configs/sandbox.h
> +++ b/include/configs/sandbox.h
> @@ -44,6 +44,9 @@
>  #define CONFIG_CMD_FAT
>  #define CONFIG_CMD_EXT4
>  #define CONFIG_CMD_EXT4_WRITE
> +#define CONFIG_CMD_CBFS
> +#define CONFIG_CMD_CRAMFS
> +#define CONFIG_CRAMFS_CMDLINE

It looks CONFIG_CRAMFS_CMDLINE is nothing but a duplicated macro of
CONFIG_CMD_CRAMFS. Maybe a separate patch to drop
CONFIG_CRAMFS_CMDLINE?

>  #define CONFIG_CMD_PART
>  #define CONFIG_DOS_PARTITION
>  #define CONFIG_HOST_MAX_DEVICES 4
> --

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


Re: [U-Boot] [PATCH 18/30] dm: block: Rename device number member dev to devnum

2016-02-16 Thread Bin Meng
Hi Simon,

On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> This is a device number, and we want to use 'dev' to mean a driver model
> device. Rename the member.
>
> Signed-off-by: Simon Glass 
> ---
>
>  board/sunxi/board.c  |  4 ++--
>  cmd/cbfs.c   |  1 +
>  cmd/disk.c   |  2 +-
>  cmd/fat.c|  4 ++--
>  cmd/ide.c| 12 ++--
>  cmd/mmc_spi.c|  4 ++--
>  cmd/reiser.c |  4 ++--
>  cmd/sata.c   |  6 +++---
>  cmd/scsi.c   |  6 +++---
>  cmd/usb_mass_storage.c   |  2 +-
>  cmd/zfs.c|  2 +-
>  common/env_fat.c |  4 ++--
>  common/fb_mmc.c  |  4 ++--
>  common/usb_storage.c |  6 +++---
>  disk/part.c  |  8 ++--
>  disk/part_dos.c  | 29 +
>  disk/part_efi.c  |  4 ++--
>  disk/part_iso.c  | 39 ---
>  disk/part_mac.c  | 22 +++---
>  drivers/block/sandbox.c  |  6 +++---
>  drivers/block/systemace.c|  2 +-
>  drivers/mmc/arm_pl180_mmci.c |  2 +-
>  drivers/mmc/mmc.c|  8 
>  drivers/mmc/mmc_write.c  |  4 ++--
>  drivers/mmc/mxsmmc.c | 24 
>  drivers/mmc/omap_hsmmc.c |  4 ++--
>  drivers/mmc/sdhci.c  |  2 +-
>  fs/fat/fat.c |  4 ++--
>  include/blk.h|  2 +-
>  29 files changed, 112 insertions(+), 109 deletions(-)
>
> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index 420481a..fd0cab9 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -336,8 +336,8 @@ int board_mmc_init(bd_t *bis)
> if (!sunxi_mmc_has_egon_boot_signature(mmc0) &&
> sunxi_mmc_has_egon_boot_signature(mmc1)) {
> /* Booting from emmc / mmc2, swap */
> -   mmc0->block_dev.dev = 1;
> -   mmc1->block_dev.dev = 0;
> +   mmc0->block_dev.devnum = 1;
> +   mmc1->block_dev.devnum = 0;
> }
>  #endif
>
> diff --git a/cmd/cbfs.c b/cmd/cbfs.c
> index cdfc9b6..779e9c0 100644
> --- a/cmd/cbfs.c
> +++ b/cmd/cbfs.c
> @@ -141,6 +141,7 @@ int do_cbfs_ls(cmd_tbl_t *cmdtp, int flag, int argc, char 
> *const argv[])
> type_name = "cmos layout";
> break;
> case -1:
> +   case 0:

Guess you didn't want this change (a git rebase ordering issue?)

> type_name = "null";
> break;
> }

[snip]

Other than that,
Reviewed-by: Bin Meng 

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


Re: [U-Boot] [PATCH 19/30] dm: block: Adjust device calls to go through helpers function

2016-02-16 Thread Bin Meng
On Mon, Feb 15, 2016 at 10:16 AM, Simon Glass  wrote:
> To ease conversion to driver model, add helper functions which deal with
> calling each block device method. With driver model we can reimplement these
> functions with the same arguments.
>
> Use inline functions to avoid increasing code size on some boards.
>
> Signed-off-by: Simon Glass 
> ---
>
>  cmd/disk.c|  6 +++---
>  cmd/ide.c |  4 ++--
>  cmd/read.c|  2 +-
>  cmd/usb.c |  6 ++
>  common/fb_mmc.c   |  5 +++--
>  disk/part_amiga.c |  9 -
>  disk/part_dos.c   |  8 +++-
>  disk/part_efi.c   | 34 +++---
>  disk/part_iso.c   |  6 +++---
>  disk/part_mac.c   |  9 -
>  fs/ext4/dev.c | 23 ++-
>  fs/ext4/ext4_common.c | 27 +--
>  fs/fat/fat.c  |  6 +++---
>  fs/fat/fat_write.c|  5 ++---
>  include/blk.h | 29 +
>  test/dm/usb.c |  2 +-
>  16 files changed, 94 insertions(+), 87 deletions(-)
>

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


[U-Boot] [PATCH] dm: ns16550: Add support for reg-offset property

2016-02-16 Thread Michal Simek
reg-offset is the part of standard 8250 binding in the kernel.
It is shifting start of address space by reg-offset.
On Xilinx platform this offset is typically 0x1000.

Signed-off-by: Michal Simek 
---

 drivers/serial/ns16550.c | 6 --
 include/ns16550.h| 1 +
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 93dad338b375..28da9ddfd859 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -105,7 +105,7 @@ static void ns16550_writeb(NS16550_t port, int offset, int 
value)
 * As far as we know it doesn't make sense to support selection of
 * these options at run-time, so use the existing CONFIG options.
 */
-   serial_out_shift(addr, plat->reg_shift, value);
+   serial_out_shift(addr + plat->reg_offset, plat->reg_shift, value);
 }
 
 static int ns16550_readb(NS16550_t port, int offset)
@@ -116,7 +116,7 @@ static int ns16550_readb(NS16550_t port, int offset)
offset *= 1 << plat->reg_shift;
addr = map_physmem(plat->base, 0, MAP_NOCACHE) + offset;
 
-   return serial_in_shift(addr, plat->reg_shift);
+   return serial_in_shift(addr + plat->reg_offset, plat->reg_shift);
 }
 
 /* We can clean these up once everything is moved to driver model */
@@ -401,6 +401,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
return -EINVAL;
 
plat->base = addr;
+   plat->reg_offset = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"reg-offset", 0);
plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 "reg-shift", 0);
plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
diff --git a/include/ns16550.h b/include/ns16550.h
index 4e620676c453..5eeacd6ff945 100644
--- a/include/ns16550.h
+++ b/include/ns16550.h
@@ -54,6 +54,7 @@
  */
 struct ns16550_platdata {
unsigned long base;
+   int reg_offset;
int reg_shift;
int clock;
 };
-- 
1.9.1

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


Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

2016-02-16 Thread Tom Warren
Simon

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Sunday, February 14, 2016 6:19 PM
> To: Stephen Warren 
> Cc: U-Boot Mailing List ; Marcel Ziswiler
> ; Tom Warren ;
> Stephen Warren ; Pantelis Antoniou  consulting.com>; Marek Vasut ; Pavel Herrmann
> ; Anatolij Gustschin 
> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> drivers to driver model
> 
> Hi,
> 
> On 1 February 2016 at 17:00, Stephen Warren 
> wrote:
> >
> > On 01/30/2016 04:37 PM, Simon Glass wrote:
> >>
> >> This series moves these two drivers over to use driver model for video.
> >>
> >> This involves the following steps:
> >> - Sync up some device tree files with Linux
> >> - Implement a proper PWM driver
> >> - Clean up and unify the driver code
> >> - Modify the existing drivers to work with driver model
> >>
> >> The tegra20 display driver uses device tree bindings invented in 2011
> >> before Linux had this or anyone was able to agree a standard. It
> >> seems possible to move it to the new bindings (like tegra124) except
> >> for the issue of time delays between stages. It isn't clear how this
> >> should work, and Linux implements this by including all LCD
> >> definitions in the kernel source code, and not using any delays. This
> >> causes strange display artifacts on the display when starting up, but
> >> perhaps is harmless to the display. Future work will sync up the
> >> device tree more for seaboard, and thus tidy this up for nvidia boards.
> >>
> >> A bug in the keyboard driver is also fixed by this series. The series
> >> is tested on seaboard and nyan-big, the two boards I have which
> >> support a display.
> >>
> >> This series is available at u-boot-dm/tegra-working.
> >
> >
> > This changes the name of the output device from "lcd" to "vidconsole".
> Anyone who doesn't reset their environment to default when switching to this
> new U-Boot will lose their display output because of this. Is there any way to
> maintain compatibility?
> >
> > Aside from that, I don't see any issues on Springbank (Seaboard),
> > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > Tested-by: Stephen Warren 
> 
> It looks like some of the patches have been applied and all Tegra boards are
> now giving Kconfig warnings.
> 
> Tom Warren, are you able to pick up the rest of the series?
I had thought these had already gone in via the dm repo. If not, please list 
those that still need to be picked up and I'll take them in via tegra. Best to 
assign the appropriate ones to me in patchwork. Currently it seems they're all 
assigned to me. Which patches have already been applied?

Tom

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


Re: [U-Boot] [PATCH v2 02/18] gpio: Add support for Qualcomm gpio controller

2016-02-16 Thread Simon Glass
Hi,

On 9 February 2016 at 14:25, Jagan Teki  wrote:
> On 8 February 2016 at 02:27, Mateusz Kulikowski
>  wrote:
>> Add support for gpio controllers on Qualcomm Snapdragon devices.
>> This devices are usually called Top Level Mode Multiplexing in
>> Qualcomm documentation.
>>
>> Signed-off-by: Mateusz Kulikowski 
>> Reviewed-by: Simon Glass 
>> Tested-by: Simon Glass 
>> ---
>>
>> Changes in v3: None
>> Changes in v2:
>> - Reordered includes (again)
>> - Added newlines between returns
>> - Fixed error handling in msm_gpio_probe
>> - Added reviewed-by
>>
>> Changes in v1:
>> - Added dt binding documentation
>> - Added help to KConfig
>> - Use clrsetbits() to switch direction
>> - Fixed include order
>> - Added #defines for registers/register fields
>> - Added secondary compatible string
>>
>>  doc/device-tree-bindings/gpio/gpio-msm.txt |  22 +
>>  drivers/gpio/Kconfig   |  14 +++
>>  drivers/gpio/Makefile  |   1 +
>>  drivers/gpio/msm_gpio.c| 135 
>> +
>>  4 files changed, 172 insertions(+)
>>  create mode 100644 doc/device-tree-bindings/gpio/gpio-msm.txt
>>  create mode 100644 drivers/gpio/msm_gpio.c
>>
>> diff --git a/doc/device-tree-bindings/gpio/gpio-msm.txt 
>> b/doc/device-tree-bindings/gpio/gpio-msm.txt
>> new file mode 100644
>> index 000..966ce0a
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/gpio/gpio-msm.txt
>> @@ -0,0 +1,22 @@
>> +Qualcomm Snapdragon GPIO controller
>> +
>> +Required properties:
>> +- compatible : "qcom,msm8916-pinctrl" or "qcom,apq8016-pinctrl"
>> +- reg : Physical base address and length of the controller's registers.
>> +   This controller is called "Top Level Mode Multiplexing" in
>> +   Qualcomm documentation.
>> +- #gpio-cells : Should be one (pin number).
>> +- gpio-controller : Marks the device node as a GPIO controller.
>> +- gpio-count: Number of GPIO pins.
>> +- gpio-bank-name: (optional) name of gpio bank. As default "soc" is used.
>> +
>> +Example:
>> +
>> +soc_gpios: pinctrl@100 {
>> +   compatible = "qcom,msm8916-pinctrl";
>
> Can't this driver goes into pinctrl (I mean gpio handling pincontrol),
> because Linux handle these gpio msm8916-pinctrl through pinctrl
> subsystem as per as I know, let me know in case if I miss anything
> here.

I think Mateusz is planning to add this later. It would be good to get
this in as a starting point for this platform.

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


Re: [U-Boot] [PATCH] fdt: Try to read #address-cells/size-cells from parent

2016-02-16 Thread Simon Glass
Hi Michal,

On 15 February 2016 at 02:58, Michal Simek  wrote:
> Hi Simon,
>
> On 10.2.2016 13:04, Michal Simek wrote:
>> Read #address-cells and #size-cells from parent if they are not present in
>> current node.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>> I have code which read information about memory for zynqmp but memory
>> node most of the time doesn't contain #address/size-cells which are
>> present in parent node.
>> That's why let's try to read it from parent.
>>
>> Also I think that we shouldn't return 2 if property is not found because
>> it has side effect on 32bit systems with #address/size-cells = <1>;
>>
>> ---
>>  lib/libfdt/fdt_addresses.c | 18 ++
>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/libfdt/fdt_addresses.c b/lib/libfdt/fdt_addresses.c
>> index 76054d98e5fd..b164d0988079 100644
>> --- a/lib/libfdt/fdt_addresses.c
>> +++ b/lib/libfdt/fdt_addresses.c
>> @@ -19,10 +19,15 @@ int fdt_address_cells(const void *fdt, int nodeoffset)
>>   const fdt32_t *ac;
>>   int val;
>>   int len;
>> + int parent;
>>
>>   ac = fdt_getprop(fdt, nodeoffset, "#address-cells", &len);
>> - if (!ac)
>> - return 2;
>> + if (!ac) {
>> + parent = fdt_parent_offset(fdt, nodeoffset);
>> + ac = fdt_getprop(fdt, parent, "#address-cells", &len);
>> + if (!ac)
>> + return 2;
>> + }
>>
>>   if (len != sizeof(*ac))
>>   return -FDT_ERR_BADNCELLS;
>> @@ -39,10 +44,15 @@ int fdt_size_cells(const void *fdt, int nodeoffset)
>>   const fdt32_t *sc;
>>   int val;
>>   int len;
>> + int parent;
>>
>>   sc = fdt_getprop(fdt, nodeoffset, "#size-cells", &len);
>> - if (!sc)
>> - return 2;
>> + if (!sc) {
>> + parent = fdt_parent_offset(fdt, nodeoffset);
>> + sc = fdt_getprop(fdt, parent, "#size-cells", &len);
>> + if (!sc)
>> + return 2;
>> + }
>>
>>   if (len != sizeof(*sc))
>>   return -FDT_ERR_BADNCELLS;
>>
>
> Simon: Any comment?

It seems risky to change the behaviour here. Also fdt_parent_offset() is slow.

Can you point me to the binding / example DT that you are trying to parse?

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


Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

2016-02-16 Thread Simon Glass
Hi,

On 15 February 2016 at 18:06, Bin Meng  wrote:
> +Simon,
>
> Hi Joe,
>
> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
>  wrote:
>> Hi Bin,
>>
>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
>>> Hi Michal,
>>>
>>> On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
 Hi Bin,

 2016-02-14 3:25 GMT+01:00 Bin Meng :
>
> Hi Michal,
>
> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
> > Add support for reading MAC address from I2C EEPROM.
> >
>
> Is this a feature provided by the GEM MAC IP?
>
> > Signed-off-by: Michal Simek 
> > ---
> >
> >  drivers/net/zynq_gem.c | 16 
> >  1 file changed, 16 insertions(+)
> >
> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> > index b3821c31a91d..ace60c901cb5 100644
> > --- a/drivers/net/zynq_gem.c
> > +++ b/drivers/net/zynq_gem.c
> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
> > return 0;
> >  }
> >
> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
> > +{
> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
> > +
> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> > +   pdata->enetaddr, ARRAY_SIZE(pdata->enetaddr)))
>
> This call to eeprom_read() looks to me a board-specific feature, that
> an on-board eeprom is used to store the MAC address for the GEM?
>

 Right. it is board specific feature I can
 The question is if this should really go to board specific file
 or to be the part of DT binding. I didn't look at the kernel if someone has
 some sort of eeprom binding for this case
 but I expect local mac addresses via DT are used. Or passing via command
 line does it.

 Anyway there is mac_read_from_eeprom() but it is ancient one.
 Do you any preference for the name of function?
>>>
>>> I think the intention of the read_rom_hwaddr op is to read the MAC
>>> address via the ethernet controller defined mechanism (eg: e1000 can
>>> read its MAC address from either an EEPROM or an SPI flash), or via
>>> SoC defined mechanism (eg: the ethernet IP is only seen on a specific
>>> SoC, and reading the MAC address only makes sense on that specific
>>> SoC). If this is a board-specific mechanism, I don't think we should
>>> put the codes into driver's read_rom_hwaddr(). Again, if it is
>>> board-specific, we may not come up with a standard DT binding for such
>>> stuff, unless we can enumerate all possible ways for storing MAC
>>> address on a board (EEPROM, SPI flash, eMMC, SD)?
>>
>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
>>
>
> I haven't noticed this before.
>
>> This is the concept I had in mind for handling this sort of thing.
>>
>
> Your patch looks good to me, but I added Simon, who is not a big fan
> of using weak in driver model :-)

My main concern with 'weak' is using it in place of what I see as a
proper API. The drivers should really stand alone and not call into
board code, and vice versa. If the driver needs some settings, then
perhaps we can provide it via device tree / platform data?

What will the other zynq boards do to read this information? How
different will each implementation be?

That said, since this is confined to zynq it's not a big concern.

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


Re: [U-Boot] [PATCH 3/3] spi: omap3: Convert to driver model

2016-02-16 Thread Simon Glass
On 11 February 2016 at 12:00, Jagan Teki  wrote:
> After this conversion the driver will able to support
> both dm and non-dm and code is more extensible like we
> can remove the non-dm part simply without touching anycode
> if all the boards which are using this driver become dm driven.
>
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Christophe Ricard 
> Signed-off-by: Jagan Teki 
> ---
>  drivers/spi/omap3_spi.c | 678 
> +---
>  1 file changed, 407 insertions(+), 271 deletions(-)

Reviewed-by: Simon Glass 

Can CONFIG_OMAP3_SPI_D0_D1_SWAPPED be moved to device tree for the DM version?

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


Re: [U-Boot] [PATCH 3/4] stm32x7: add support for stm32x7 serial driver

2016-02-16 Thread Simon Glass
On 11 February 2016 at 16:47, Vikas Manocha  wrote:
> This patch adds support for stm32f7 family usart peripheral.
>
> Signed-off-by: Vikas Manocha 
> ---
>  drivers/serial/Makefile   |  1 +
>  drivers/serial/serial_stm32x7.c   | 83 
> +++
>  drivers/serial/serial_stm32x7.h   | 37 ++
>  include/dm/platform_data/serial_stm32x7.h | 17 +++
>  4 files changed, 138 insertions(+)
>  create mode 100644 drivers/serial/serial_stm32x7.c
>  create mode 100644 drivers/serial/serial_stm32x7.h
>  create mode 100644 include/dm/platform_data/serial_stm32x7.h

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


Re: [U-Boot] [PATCH v2 2/7] arm: omap: sata: compile out sata init apis when CONFIG_DISK is defined

2016-02-16 Thread Simon Glass
On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Compile out sata init/reset apis as this will be implemented in
> disk-uclass driver to initialize sata devices.
>
> Signed-off-by: Mugunthan V N 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 2 ++
>  1 file changed, 2 insertions(+)

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


Re: [U-Boot] [PATCH v2 1/7] arm: omap: sata: move enable sata clocks to enable_basic_clocks()

2016-02-16 Thread Simon Glass
On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> All the clocks which has to be enabled has to be done in
> enable_basic_clocks(), so moving enable sata clock to common
> clocks enable function.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 23 ---
>  arch/arm/cpu/armv7/omap5/hw_data.c| 12 
>  2 files changed, 12 insertions(+), 23 deletions(-)

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


Re: [U-Boot] [PATCH V2 1/2] pinctrl: imx: Introduce pinctrl driver for i.MX6

2016-02-16 Thread Simon Glass
Hi Peng,

On 15 February 2016 at 01:33, Peng Fan  wrote:
> Hi Simon,
>
> Gentle ping..

Do you mean Stefan? I reviewed the previous so did not think it
necessary to look again.

>
> Thanks,
> Peng.

Regards,
Simon

>
> On Wed, Feb 03, 2016 at 10:06:07AM +0800, Peng Fan wrote:
>>Introduce pinctrl for i.MX6
>>1. pinctrl-imx.c is for common usage. It's used by i.MX6/7.
>>2. Add PINCTRL_IMX PINCTRL_IMX6 Kconfig entry.
>>3. To the pinctrl_ops implementation, only set_state is implemented.
>>   To i.MX6/7, the pinctrl dts entry is as following:
>>&iomuxc {
>>pinctrl-names = "default";
>>
>>pinctrl_csi1: csi1grp {
>>fsl,pins = <
>>MX6UL_PAD_CSI_MCLK__CSI_MCLK0x1b088
>>MX6UL_PAD_CSI_PIXCLK__CSI_PIXCLK0x1b088
>>MX6UL_PAD_CSI_VSYNC__CSI_VSYNC  0x1b088
>>>;
>>};
>>
>>[.]
>>};
>>  there is no property named function or groups. So pinctrl_generic_set_state
>>  can not be used here.
>>5. This driver is a simple implementation for i.mx iomux controller,
>>   only parse the fsl,pins property and write value to registers.
>>6. With DEBUG enabled, we can see log when "i2c bus 0":
>>   "
>>   set_state_simple op missing
>>   imx_pinctrl_set_state: i2c1grp
>>   mux_reg 0x14c, conf_reg 0x3bc, input_reg 0x5d8, mux_mode 0x0, input_val 
>> 0x1, config_val 0x407f
>>   write mux: offset 0x14c val 0x10
>>   select_input: offset 0x5d8 val 0x1
>>   write config: offset 0x3bc val 0x7f
>>   mux_reg 0x148, conf_reg 0x3b8, input_reg 0x5d4, mux_mode 0x0, input_val 
>> 0x1, config_val 0x407f
>>   write mux: offset 0x148 val 0x10
>>   select_input: offset 0x5d4 val 0x1
>>   write config: offset 0x3b8 val 0x7f
>>   "
>>   this means imx6 pinctrl driver works as expected.
>>
>>Signed-off-by: Peng Fan 
>>Reviewed-by: Simon Glass 
>>---
>>
>>V2:
>> Add more details in Kconfig entry
>> Use fdt_getprop and fdtdec_get_int_array as suggested by Simon
>> Add reviewed-by Simon
>> Refer linux binding doc in code.
>>
>> drivers/pinctrl/Kconfig|   1 +
>> drivers/pinctrl/Makefile   |   1 +
>> drivers/pinctrl/nxp/Kconfig|  16 +++
>> drivers/pinctrl/nxp/Makefile   |   2 +
>> drivers/pinctrl/nxp/pinctrl-imx.c  | 241 
>> +
>> drivers/pinctrl/nxp/pinctrl-imx.h  |  50 
>> drivers/pinctrl/nxp/pinctrl-imx6.c |  41 +++
>> 7 files changed, 352 insertions(+)
>> create mode 100644 drivers/pinctrl/nxp/Kconfig
>> create mode 100644 drivers/pinctrl/nxp/Makefile
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.c
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx.h
>> create mode 100644 drivers/pinctrl/nxp/pinctrl-imx6.c
>>
>>diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
>>index 57e6142..9fd8f62 100644
>>--- a/drivers/pinctrl/Kconfig
>>+++ b/drivers/pinctrl/Kconfig
>>@@ -133,6 +133,7 @@ config PINCTRL_SANDBOX
>>
>> endif
>>
>>+source "drivers/pinctrl/nxp/Kconfig"
>> source "drivers/pinctrl/uniphier/Kconfig"
>>
>> endmenu
>>diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
>>index 70d25dc..dcd20bf 100644
>>--- a/drivers/pinctrl/Makefile
>>+++ b/drivers/pinctrl/Makefile
>>@@ -5,6 +5,7 @@
>> obj-y += pinctrl-uclass.o
>> obj-$(CONFIG_$(SPL_)PINCTRL_GENERIC)  += pinctrl-generic.o
>>
>>+obj-y += nxp/
>> obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
>> obj-$(CONFIG_PINCTRL_SANDBOX) += pinctrl-sandbox.o
>>
>>diff --git a/drivers/pinctrl/nxp/Kconfig b/drivers/pinctrl/nxp/Kconfig
>>new file mode 100644
>>index 000..f1c9b92
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/Kconfig
>>@@ -0,0 +1,16 @@
>>+config PINCTRL_IMX
>>+  bool
>>+
>>+config PINCTRL_IMX6
>>+  bool "IMX6 pinctrl driver"
>>+  depends on ARCH_MX6 && PINCTRL_FULL
>>+  select DEVRES
>>+  select PINCTRL_IMX
>>+  help
>>+Say Y here to enable the imx6 pinctrl driver
>>+
>>+This provides a simple pinctrl driver for i.MX6 SoC familiy,
>>+i.MX6DQ/SL/SX/UL/DQP. This feature depends on device tree
>>+configuration. This driver is different from the linux one,
>>+this is a simple implementation, only parses the 'fsl,pins'
>>+property and configure related registers.
>>diff --git a/drivers/pinctrl/nxp/Makefile b/drivers/pinctrl/nxp/Makefile
>>new file mode 100644
>>index 000..7fd9850
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/Makefile
>>@@ -0,0 +1,2 @@
>>+obj-$(CONFIG_PINCTRL_IMX) += pinctrl-imx.o
>>+obj-$(CONFIG_PINCTRL_IMX6)+= pinctrl-imx6.o
>>diff --git a/drivers/pinctrl/nxp/pinctrl-imx.c 
>>b/drivers/pinctrl/nxp/pinctrl-imx.c
>>new file mode 100644
>>index 000..40b0616
>>--- /dev/null
>>+++ b/drivers/pinctrl/nxp/pinctrl-imx.c
>>@@ -0,0 +1,241 @@
>>+/*
>>+ * Copyright (C) 2016 Peng Fan 
>>+ *
>>+ * SPDX-License-Identifier:   GPL-2.0+
>>+ */
>>+
>>+#include 
>>+#include 
>>+#include 
>>+#include 
>>+

Re: [U-Boot] how does board_init_f() -> board_init_r?

2016-02-16 Thread Simon Glass
+Stephen who will know more

Hi,

On 13 February 2016 at 18:52, quantumlight  wrote:
> I am trying to modify the bootloader code for NVIDIA's jetson board.
>
> So I am looking at crt0.S. It seems that two builds happen, one with
> CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin
> and spl/u-boot-spl.bin.

SPL is built with ARMv4t
U-Boot proper is built with ARMv7

That's why SPL is used on Tegra. The SPL does not actually load
U-Boot. In fact both are bundle together and loaded at the same time.
SPL simply jumps to U-Boot when needed.

>
> However, I am unable to find the code path that calls board_init_r() after
> board_init_f() finishes, although there are several candidates:
>
> 1) crt0.S - if CONFIG_SPL_BUILD was not defined, then it would fall straight
> through to board_init_r() - HOWEVER, for u-boot.bin, isn't CONFIG_SPL_BUILD
> defined in autoconf.h? Or is this some clever magic between how u-boot.bin
> and spl/u-boot-spl.bin are stitched together?

For U-Boot, CONFIG_SPL_BUILD is not defined. That define means you are
building SPL.

The clever magic is mostly 'cat'. SPL is padded a little and then
U-Boot is added on the end.

> 2) _weak board_init_f in arch/arm/lib/spl.c - HOWEVER, shouldn't this be
> overloaded by board_init_f in common/board_f.c?

The latter is only used in U-Boot proper. SPL has its own board_init_f().

> 3) board_init_f_r in common/board_f.c - HOWEVER, nothing calls
> board_init_f_r().

No, that is not used on ARM.

>
> Can someone illuminate me on how this happens?
>

See the README under Board Initialisation Flow. In brief, the link
between board_init_f() and board_init_r() is generally the crt0.S that
you found. The catch is that some boards don't implement
board_init_f() in SPL, and so use the weak one, which in fact calls
board_init_r() directly.

See also arch/arm/mach-tegra/board.c which I think contains the code
to jump to SPL.

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


Re: [U-Boot] [PATCH v2 4/7] arm: omap-common: sata: prepare driver for DM conversion

2016-02-16 Thread Simon Glass
On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Prepare sata driver for DM conversion by abstracting sata phy
> init to seperate function.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  arch/arm/cpu/armv7/omap-common/sata.c | 13 +
>  include/sata.h|  2 ++
>  2 files changed, 11 insertions(+), 4 deletions(-)

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


Re: [U-Boot] [PATCH v2 6/7] defconfig: dra74_evm: enable disk driver model

2016-02-16 Thread Simon Glass
On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Enable disk driver model for dra74_evm as dwc_ahci supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  configs/dra74_evm_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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


Re: [U-Boot] [PATCH v2 7/7] defconfig: dra72_evm: enable disk driver model

2016-02-16 Thread Simon Glass
On 3 February 2016 at 04:59, Mugunthan V N  wrote:
> Enable disk driver model for dra72_evm as dwc_ahci supports
> driver model
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Tom Rini 
> ---
>  configs/dra72_evm_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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


Re: [U-Boot] [RFC PATCH v4 1/3] sandbox: Fix compiling warning on 32-bit host

2016-02-16 Thread Simon Glass
+Masahiro

Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> Fix the following compiling warning on 32-bit host
>
> disk/part_efi.c: In function 'alloc_read_gpt_entries':
> disk/part_efi.c:894:2: warning: format '%zu' expects argument of
>  type 'size_t', but argument 5 has type 'long unsigned int'
>  [-Wformat]
> disk/part_efi.c:907:4: warning: format '%zX' expects argument of
>  type 'size_t', but argument 3 has type 'long unsigned int'
>  [-Wformat]
> cmd/lzmadec.c: In function 'do_lzmadec':
> cmd/lzmadec.c:39:12: warning: passing argument 2 of
>  'lzmaBuffToBuffDecompress' from incompatible pointer type
>  [enabled by default]
> include/lzma/../../lib/lzma/LzmaTools.h:17:12: note: expected
>  'SizeT *' but argument is of type 'long unsigned int *'
> lib/hashtable.c: In function 'hexport_r':
> lib/hashtable.c:605:2: warning: format '%zu' expects argument of
>  type 'size_t', but argument 5 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>  type 'size_t', but argument 2 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c:661:5: warning: format '%zu' expects argument of
>  type 'size_t', but argument 3 has type 'long unsigned int'
>  [-Wformat]
> lib/hashtable.c: In function 'himport_r':
> lib/hashtable.c:793:3: warning: format '%zu' expects argument of
>  type 'size_t', but argument 2 has type 'long unsigned int'
>  [-Wformat]
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   New patch to fix compiling warnings for sandbox built on 32-bit host
>   Still need to change CONFIG_SANDBOX_BITS_PER_LONG to 32 to avoid
>   these warnings
>   include/asm-generic/bitops/__fls.h:17:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:19:3: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:22:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:26:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:30:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:34:2: warning: left shift
>count >= width of type [enabled by default]
>   include/asm-generic/bitops/__fls.h:38:2: warning: left shift
>count >= width of type [enabled by default]
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/sandbox/cpu/cpu.c   |3 ++-
>  arch/sandbox/include/asm/types.h |4 ++--
>  arch/sandbox/lib/bootm.c |3 ++-
>  arch/sandbox/lib/pci_io.c|2 +-
>  cmd/bootm.c  |4 ++--
>  cmd/lzmadec.c|5 +++--
>  disk/part_efi.c  |2 +-
>  include/image.h  |6 ++
>  lib/hashtable.c  |2 +-
>  9 files changed, 20 insertions(+), 11 deletions(-)

I think this makes sense. But one nit - the % is not included in the
macros in inttypes,h. What do you think about doing the same with your
macro?

>
> diff --git a/arch/sandbox/cpu/cpu.c b/arch/sandbox/cpu/cpu.c
> index 196f3e1..7aad876 100644
> --- a/arch/sandbox/cpu/cpu.c
> +++ b/arch/sandbox/cpu/cpu.c
> @@ -62,7 +62,8 @@ void *map_physmem(phys_addr_t paddr, unsigned long len, 
> unsigned long flags)
> map_dev = NULL;
> if (enable_pci_map && !pci_map_physmem(paddr, &len, &map_dev, &ptr)) {
> if (plen != len) {
> -   printf("%s: Warning: partial map at %x, wanted %lx, 
> got %lx\n",
> +   printf("%s: Warning: partial map at " PRIpa
> +  ", wanted %lx, got %lx\n",
>__func__, paddr, len, plen);
> }
> map_len = len;
> diff --git a/arch/sandbox/include/asm/types.h 
> b/arch/sandbox/include/asm/types.h
> index 42c09e2..c3bb76e 100644
> --- a/arch/sandbox/include/asm/types.h
> +++ b/arch/sandbox/include/asm/types.h
> @@ -53,8 +53,8 @@ typedef __UINT64_TYPE__ u64;
>  #define BITS_PER_LONG  CONFIG_SANDBOX_BITS_PER_LONG
>
>  typedef unsigned long dma_addr_t;
> -typedef u32 phys_addr_t;
> -typedef u32 phys_size_t;
> +typedef unsigned long phys_addr_t;
> +typedef unsigned long phys_size_t;
>
>  #endif /* __KERNEL__ */
>
> diff --git a/arch/sandbox/lib/bootm.c b/arch/sandbox/lib/bootm.c
> index d49c927..9ca89b5 100644
> --- a/arch/sandbox/lib/bootm.c
> +++ b/arch/sandbox/lib/bootm.c
> @@ -54,7 +54,8 @@ int do_bootm_linux(int flag, int argc, char *argv[], 
> bootm_headers_t *images)
>  {
> if (flag & (BOOTM_STATE_OS_GO | BOOTM_STATE_OS_FAKE_GO)) {
> bootstage_mark(BOOTSTAGE_ID_RUN_OS);
> -   printf("## Transferring control to Linux (at address 
> %08lx)...\n",
> +   printf("## Transferring control to Linux (at address " PRIpa
> +  ")...\n",
>images

Re: [U-Boot] [RFC PATCH v4 3/3] common: Fix load and entry addresses in FIT image

2016-02-16 Thread Simon Glass
Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> FIT image supports more than 32 bits in addresses by using #address-cell
> field. However the address length is not handled when parsing FIT images.
>

nit: How about saying "fix this by adding support for 64-bit
addresses" or similar

> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   Separate ulong to phys_addr_t change to another patch.
>
> Changes in v3:
>   Define PRIpa for host and target in common/image-fit.c so printf works
>   properly for 32-, 64-bit targets and host tools.
>
> Changes in v2:
>   Make a common function for both load and entry addresses.
>   Simplify calculation of addresses in a similar way as fdtdec_get_number()
>   fdtdec_get_number() is not used, or too many files need to be included
> and/or twisted for host tool
>   Continue to use %08llx for print format for load and entry addresses
> because %pa does not always work for host tool (mkimage)
>
>  common/image-fit.c |   54 
> ++--
>  1 file changed, 31 insertions(+), 23 deletions(-)
>
> diff --git a/common/image-fit.c b/common/image-fit.c
> index bfa76a2..c000475 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -433,7 +433,7 @@ void fit_image_print(const void *fit, int image_noffset, 
> const char *p)
>
> if ((type == IH_TYPE_KERNEL) || (type == IH_TYPE_STANDALONE) ||
> (type == IH_TYPE_RAMDISK)) {
> -   fit_image_get_entry(fit, image_noffset, &entry);
> +   ret = fit_image_get_entry(fit, image_noffset, &entry);
> printf("%s  Entry Point:  ", p);
> if (ret)
> printf("unavailable\n");
> @@ -675,6 +675,34 @@ int fit_image_get_comp(const void *fit, int noffset, 
> uint8_t *comp)
> return 0;
>  }
>
> +static int fit_image_get_address(const void *fit, int noffset, char *name,
> + phys_addr_t *load)
> +{
> +   int len, cell_len;
> +   const fdt32_t *cell;
> +   unsigned long long load64 = 0;
> +
> +   cell = fdt_getprop(fit, noffset, name, &len);
> +   if (cell == NULL) {
> +   fit_get_debug(fit, noffset, name, len);
> +   return -1;
> +   }
> +
> +   if (len > sizeof(phys_addr_t)) {
> +   printf("Unsupported %s address size\n", name);
> +   return -1;
> +   }
> +
> +   cell_len = len >> 2;
> +   /* Use load64 to avoid compiling warning for 32-bit target */
> +   while (cell_len--) {
> +   load64 = (load64 << 32) | uimage_to_cpu(*cell);
> +   cell++;
> +   }
> +   *load = (phys_addr_t)load64;
> +
> +   return 0;
> +}
>  /**
>   * fit_image_get_load() - get load addr property for given component image 
> node
>   * @fit: pointer to the FIT format image header
> @@ -690,17 +718,7 @@ int fit_image_get_comp(const void *fit, int noffset, 
> uint8_t *comp)
>   */
>  int fit_image_get_load(const void *fit, int noffset, phys_addr_t *load)
>  {
> -   int len;
> -   const uint32_t *data;
> -
> -   data = fdt_getprop(fit, noffset, FIT_LOAD_PROP, &len);
> -   if (data == NULL) {
> -   fit_get_debug(fit, noffset, FIT_LOAD_PROP, len);
> -   return -1;
> -   }
> -
> -   *load = uimage_to_cpu(*data);
> -   return 0;
> +   return fit_image_get_address(fit, noffset, FIT_LOAD_PROP, load);

I think it would make sense to have your new fit_image_get_address()
in one patch, and the enhancement to support more address sizes in
another.

>  }
>
>  /**
> @@ -722,17 +740,7 @@ int fit_image_get_load(const void *fit, int noffset, 
> phys_addr_t *load)
>   */
>  int fit_image_get_entry(const void *fit, int noffset, phys_addr_t *entry)
>  {
> -   int len;
> -   const uint32_t *data;
> -
> -   data = fdt_getprop(fit, noffset, FIT_ENTRY_PROP, &len);
> -   if (data == NULL) {
> -   fit_get_debug(fit, noffset, FIT_ENTRY_PROP, len);
> -   return -1;
> -   }
> -
> -   *entry = uimage_to_cpu(*data);
> -   return 0;
> +   return fit_image_get_address(fit, noffset, FIT_ENTRY_PROP, entry);
>  }
>
>  /**
> --
> 1.7.9.5
>

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


Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

2016-02-16 Thread Simon Glass
Hi Tom,

On 16 February 2016 at 08:47, Tom Warren  wrote:
>
> Simon
>
> > -Original Message-
> > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> > Sent: Sunday, February 14, 2016 6:19 PM
> > To: Stephen Warren 
> > Cc: U-Boot Mailing List ; Marcel Ziswiler
> > ; Tom Warren ;
> > Stephen Warren ; Pantelis Antoniou  > consulting.com>; Marek Vasut ; Pavel Herrmann
> > ; Anatolij Gustschin 
> > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> > drivers to driver model
> >
> > Hi,
> >
> > On 1 February 2016 at 17:00, Stephen Warren 
> > wrote:
> > >
> > > On 01/30/2016 04:37 PM, Simon Glass wrote:
> > >>
> > >> This series moves these two drivers over to use driver model for video.
> > >>
> > >> This involves the following steps:
> > >> - Sync up some device tree files with Linux
> > >> - Implement a proper PWM driver
> > >> - Clean up and unify the driver code
> > >> - Modify the existing drivers to work with driver model
> > >>
> > >> The tegra20 display driver uses device tree bindings invented in 2011
> > >> before Linux had this or anyone was able to agree a standard. It
> > >> seems possible to move it to the new bindings (like tegra124) except
> > >> for the issue of time delays between stages. It isn't clear how this
> > >> should work, and Linux implements this by including all LCD
> > >> definitions in the kernel source code, and not using any delays. This
> > >> causes strange display artifacts on the display when starting up, but
> > >> perhaps is harmless to the display. Future work will sync up the
> > >> device tree more for seaboard, and thus tidy this up for nvidia boards.
> > >>
> > >> A bug in the keyboard driver is also fixed by this series. The series
> > >> is tested on seaboard and nyan-big, the two boards I have which
> > >> support a display.
> > >>
> > >> This series is available at u-boot-dm/tegra-working.
> > >
> > >
> > > This changes the name of the output device from "lcd" to "vidconsole".
> > Anyone who doesn't reset their environment to default when switching to this
> > new U-Boot will lose their display output because of this. Is there any way 
> > to
> > maintain compatibility?
> > >
> > > Aside from that, I don't see any issues on Springbank (Seaboard),
> > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > > Tested-by: Stephen Warren 
> >
> > It looks like some of the patches have been applied and all Tegra boards are
> > now giving Kconfig warnings.
> >
> > Tom Warren, are you able to pick up the rest of the series?
> I had thought these had already gone in via the dm repo. If not, please list 
> those that still need to be picked up and I'll take them in via tegra. Best 
> to assign the appropriate ones to me in patchwork. Currently it seems they're 
> all assigned to me. Which patches have already been applied?

I think it was the follow-up patches to add the environment
work-around that was applied.

6c88b51 video: tegra: Enable the 'lcd' env variable work-around
a2931b3 dm: video: Add a temporary work-around for old stdout var

I see the original v2 series here:

http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839

so that is what needs to be applied I think. Then the Tegra config
issue should be fixed.

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


Re: [U-Boot] test/py main_signon

2016-02-16 Thread Michal Simek
Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>> Hi Stephen,
>>
>> trying to run the latest testing on zynq board and getting this
>> main_signon error.
>>
>> This is what I am running
>> ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
>> and getting below.
> 
> Does this board has SPL support without SPL serial output?

I do load u-boot via jtag that's why SPL logs are not visible.

> If so, can you try my patch:
> http://patchwork.ozlabs.org/patch/583348/

I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.

Thanks,
Michal


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


Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

2016-02-16 Thread Joe Hershberger
Hi Simon,

On Tue, Feb 16, 2016 at 9:59 AM, Simon Glass  wrote:
> Hi,
>
> On 15 February 2016 at 18:06, Bin Meng  wrote:
>> +Simon,
>>
>> Hi Joe,
>>
>> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
>>  wrote:
>>> Hi Bin,
>>>
>>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
 Hi Michal,

 On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
> Hi Bin,
>
> 2016-02-14 3:25 GMT+01:00 Bin Meng :
>>
>> Hi Michal,
>>
>> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
>> > Add support for reading MAC address from I2C EEPROM.
>> >
>>
>> Is this a feature provided by the GEM MAC IP?
>>
>> > Signed-off-by: Michal Simek 
>> > ---
>> >
>> >  drivers/net/zynq_gem.c | 16 
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
>> > index b3821c31a91d..ace60c901cb5 100644
>> > --- a/drivers/net/zynq_gem.c
>> > +++ b/drivers/net/zynq_gem.c
>> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
>> > return 0;
>> >  }
>> >
>> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
>> > +{
>> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
>> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
>> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
>> > +
>> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
>> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
>> > +   pdata->enetaddr, ARRAY_SIZE(pdata->enetaddr)))
>>
>> This call to eeprom_read() looks to me a board-specific feature, that
>> an on-board eeprom is used to store the MAC address for the GEM?
>>
>
> Right. it is board specific feature I can
> The question is if this should really go to board specific file
> or to be the part of DT binding. I didn't look at the kernel if someone 
> has
> some sort of eeprom binding for this case
> but I expect local mac addresses via DT are used. Or passing via command
> line does it.
>
> Anyway there is mac_read_from_eeprom() but it is ancient one.
> Do you any preference for the name of function?

 I think the intention of the read_rom_hwaddr op is to read the MAC
 address via the ethernet controller defined mechanism (eg: e1000 can
 read its MAC address from either an EEPROM or an SPI flash), or via
 SoC defined mechanism (eg: the ethernet IP is only seen on a specific
 SoC, and reading the MAC address only makes sense on that specific
 SoC). If this is a board-specific mechanism, I don't think we should
 put the codes into driver's read_rom_hwaddr(). Again, if it is
 board-specific, we may not come up with a standard DT binding for such
 stuff, unless we can enumerate all possible ways for storing MAC
 address on a board (EEPROM, SPI flash, eMMC, SD)?
>>>
>>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
>>>
>>
>> I haven't noticed this before.
>>
>>> This is the concept I had in mind for handling this sort of thing.
>>>
>>
>> Your patch looks good to me, but I added Simon, who is not a big fan
>> of using weak in driver model :-)
>
> My main concern with 'weak' is using it in place of what I see as a
> proper API. The drivers should really stand alone and not call into
> board code, and vice versa. If the driver needs some settings, then
> perhaps we can provide it via device tree / platform data?

The problem with using the device tree is we want to share with Linux.
Linux DTs will not describe this sort of thing. Platform data,
maybe... but it is not something that is defined. That means it will
be very difficult to make standard.

On a side note, the same thing troubles me wrt MDIO and phy
descriptions in DTs. It seems each MAC device tree has a different way
to describe the relationships.

> What will the other zynq boards do to read this information? How
> different will each implementation be?

That's part of the problem. It's hard to make a good API when it's
only the first or second board that wants to do this. The next one
will have a different requirement.

> That said, since this is confined to zynq it's not a big concern.

It seems like it's worth cleaning up after there is a clear need to
have an API. Until there are a number of boards that need something
like this, I think an informal API (like this weak stuff) is simpler.

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


Re: [U-Boot] [PATCH] fdt: Try to read #address-cells/size-cells from parent

2016-02-16 Thread Michal Simek
Hi Simon,

On 16.2.2016 17:00, Simon Glass wrote:
> Hi Michal,
> 
> On 15 February 2016 at 02:58, Michal Simek  wrote:
>> Hi Simon,
>>
>> On 10.2.2016 13:04, Michal Simek wrote:
>>> Read #address-cells and #size-cells from parent if they are not present in
>>> current node.
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>> I have code which read information about memory for zynqmp but memory
>>> node most of the time doesn't contain #address/size-cells which are
>>> present in parent node.
>>> That's why let's try to read it from parent.
>>>
>>> Also I think that we shouldn't return 2 if property is not found because
>>> it has side effect on 32bit systems with #address/size-cells = <1>;
>>>
>>> ---
>>>  lib/libfdt/fdt_addresses.c | 18 ++
>>>  1 file changed, 14 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/libfdt/fdt_addresses.c b/lib/libfdt/fdt_addresses.c
>>> index 76054d98e5fd..b164d0988079 100644
>>> --- a/lib/libfdt/fdt_addresses.c
>>> +++ b/lib/libfdt/fdt_addresses.c
>>> @@ -19,10 +19,15 @@ int fdt_address_cells(const void *fdt, int nodeoffset)
>>>   const fdt32_t *ac;
>>>   int val;
>>>   int len;
>>> + int parent;
>>>
>>>   ac = fdt_getprop(fdt, nodeoffset, "#address-cells", &len);
>>> - if (!ac)
>>> - return 2;
>>> + if (!ac) {
>>> + parent = fdt_parent_offset(fdt, nodeoffset);
>>> + ac = fdt_getprop(fdt, parent, "#address-cells", &len);
>>> + if (!ac)
>>> + return 2;
>>> + }
>>>
>>>   if (len != sizeof(*ac))
>>>   return -FDT_ERR_BADNCELLS;
>>> @@ -39,10 +44,15 @@ int fdt_size_cells(const void *fdt, int nodeoffset)
>>>   const fdt32_t *sc;
>>>   int val;
>>>   int len;
>>> + int parent;
>>>
>>>   sc = fdt_getprop(fdt, nodeoffset, "#size-cells", &len);
>>> - if (!sc)
>>> - return 2;
>>> + if (!sc) {
>>> + parent = fdt_parent_offset(fdt, nodeoffset);
>>> + sc = fdt_getprop(fdt, parent, "#size-cells", &len);
>>> + if (!sc)
>>> + return 2;
>>> + }
>>>
>>>   if (len != sizeof(*sc))
>>>   return -FDT_ERR_BADNCELLS;
>>>
>>
>> Simon: Any comment?
> 
> It seems risky to change the behaviour here. Also fdt_parent_offset() is slow.
> 
> Can you point me to the binding / example DT that you are trying to parse?

Look at dram_init(), etc.
https://github.com/Xilinx/u-boot-xlnx/blob/master/board/xilinx/zynqmp/zynqmp.c

fdt_get_reg() is calling fdt_size_cells()


And this is DTS fragment.
#address-cells = <2>;
#size-cells = <1>;

memory {
device_type = "memory";
reg = <0x0 0x0 0x8000>, <0x8 0x 0x8000>;
};

Code is in memory node I need to work with and asking for size-cells.
Current code returns 2 instead of error and the rest of code just works
with size = 2 which is incorrect for this setup.

I have already changed size-cells = 2 in our repo because I need to
support for more than 4GB memory anyway but this should point to the
problem in that generic functions.

Thanks,
Michal

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


Re: [U-Boot] [PATCH 1/6] net: gem: Add support for reading MAC from I2C EEPROM

2016-02-16 Thread Simon Glass
Hi Joe,

On 16 February 2016 at 09:06, Joe Hershberger  wrote:
>
> Hi Simon,
>
> On Tue, Feb 16, 2016 at 9:59 AM, Simon Glass  wrote:
> > Hi,
> >
> > On 15 February 2016 at 18:06, Bin Meng  wrote:
> >> +Simon,
> >>
> >> Hi Joe,
> >>
> >> On Tue, Feb 16, 2016 at 12:01 AM, Joe Hershberger
> >>  wrote:
> >>> Hi Bin,
> >>>
> >>> On Sun, Feb 14, 2016 at 6:00 AM, Bin Meng  wrote:
>  Hi Michal,
> 
>  On Sun, Feb 14, 2016 at 6:03 PM, Michal Simek  wrote:
> > Hi Bin,
> >
> > 2016-02-14 3:25 GMT+01:00 Bin Meng :
> >>
> >> Hi Michal,
> >>
> >> On Sat, Feb 13, 2016 at 6:39 PM, Michal Simek  wrote:
> >> > Add support for reading MAC address from I2C EEPROM.
> >> >
> >>
> >> Is this a feature provided by the GEM MAC IP?
> >>
> >> > Signed-off-by: Michal Simek 
> >> > ---
> >> >
> >> >  drivers/net/zynq_gem.c | 16 
> >> >  1 file changed, 16 insertions(+)
> >> >
> >> > diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> >> > index b3821c31a91d..ace60c901cb5 100644
> >> > --- a/drivers/net/zynq_gem.c
> >> > +++ b/drivers/net/zynq_gem.c
> >> > @@ -627,6 +627,21 @@ static int zynq_gem_remove(struct udevice *dev)
> >> > return 0;
> >> >  }
> >> >
> >> > +static int zynq_gem_read_rom_hwaddr(struct udevice *dev)
> >> > +{
> >> > +#if defined(CONFIG_ZYNQ_GEM_EEPROM_ADDR) && \
> >> > +defined(CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET)
> >> > +   struct eth_pdata *pdata = dev_get_platdata(dev);
> >> > +
> >> > +   if (eeprom_read(CONFIG_ZYNQ_GEM_EEPROM_ADDR,
> >> > +   CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET,
> >> > +   pdata->enetaddr, 
> >> > ARRAY_SIZE(pdata->enetaddr)))
> >>
> >> This call to eeprom_read() looks to me a board-specific feature, that
> >> an on-board eeprom is used to store the MAC address for the GEM?
> >>
> >
> > Right. it is board specific feature I can
> > The question is if this should really go to board specific file
> > or to be the part of DT binding. I didn't look at the kernel if someone 
> > has
> > some sort of eeprom binding for this case
> > but I expect local mac addresses via DT are used. Or passing via command
> > line does it.
> >
> > Anyway there is mac_read_from_eeprom() but it is ancient one.
> > Do you any preference for the name of function?
> 
>  I think the intention of the read_rom_hwaddr op is to read the MAC
>  address via the ethernet controller defined mechanism (eg: e1000 can
>  read its MAC address from either an EEPROM or an SPI flash), or via
>  SoC defined mechanism (eg: the ethernet IP is only seen on a specific
>  SoC, and reading the MAC address only makes sense on that specific
>  SoC). If this is a board-specific mechanism, I don't think we should
>  put the codes into driver's read_rom_hwaddr(). Again, if it is
>  board-specific, we may not come up with a standard DT binding for such
>  stuff, unless we can enumerate all possible ways for storing MAC
>  address on a board (EEPROM, SPI flash, eMMC, SD)?
> >>>
> >>> Did you see this: https://patchwork.ozlabs.org/patch/573373/
> >>>
> >>
> >> I haven't noticed this before.
> >>
> >>> This is the concept I had in mind for handling this sort of thing.
> >>>
> >>
> >> Your patch looks good to me, but I added Simon, who is not a big fan
> >> of using weak in driver model :-)
> >
> > My main concern with 'weak' is using it in place of what I see as a
> > proper API. The drivers should really stand alone and not call into
> > board code, and vice versa. If the driver needs some settings, then
> > perhaps we can provide it via device tree / platform data?
>
> The problem with using the device tree is we want to share with Linux.
> Linux DTs will not describe this sort of thing. Platform data,
> maybe... but it is not something that is defined. That means it will
> be very difficult to make standard.
>
> On a side note, the same thing troubles me wrt MDIO and phy
> descriptions in DTs. It seems each MAC device tree has a different way
> to describe the relationships.
>
> > What will the other zynq boards do to read this information? How
> > different will each implementation be?
>
> That's part of the problem. It's hard to make a good API when it's
> only the first or second board that wants to do this. The next one
> will have a different requirement.
>
> > That said, since this is confined to zynq it's not a big concern.
>
> It seems like it's worth cleaning up after there is a clear need to
> have an API. Until there are a number of boards that need something
> like this, I think an informal API (like this weak stuff) is simpler.

Sounds reasonable to me.

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


Re: [U-Boot] Warnings from Tegra LCD conversion?

2016-02-16 Thread Simon Glass
Hi Stephen,

On 15 February 2016 at 22:29, Stephen Warren  wrote:
> While checking on the travis-ci.org runs that include test/py testing of
> sandbox, I noticed some new warnings on AArch64 Tegra boards. See the
> log at:
>
> https://travis-ci.org/u-boot/u-boot/jobs/109471848
>
>> Building current source for 33 boards (2 threads, 1 job per thread)
>>aarch64:  +   e2220-1170
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2571
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2371-
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)
>>aarch64:  +   p2371-2180
>> +warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet direct 
>> dependencies (DM_VIDEO)

See the other thread - the patches for the environment work-around
were applied, but the Tegra LCD conversion was not. Hopefully Tom can
get these in and the problem should go away.

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


Re: [U-Boot] [PATCH v2 3/7] drivers: block: disk-uclass: implement scsi_init()

2016-02-16 Thread Simon Glass
Hi Mugunthan and Bin,

On 14 February 2016 at 20:03, Bin Meng  wrote:
> Hi Simon,
>
> On Sun, Feb 7, 2016 at 4:29 AM, Simon Glass  wrote:
>> Hi Bin,
>>
>> On 3 February 2016 at 04:59, Mugunthan V N  wrote:
>>>
>>> Implement scsi_init() api to probe driver model based sata
>>> devices.
>>>
>>> Signed-off-by: Mugunthan V N 
>>> ---
>>>  drivers/block/disk-uclass.c | 39 +++
>>>  1 file changed, 39 insertions(+)
>>
>> This patch seems odd to me. I would hope that scsi_init() would go
>> away with driver model and it would happen as part of the controller
>> probe. But of course we cannot probe SCSI from UCLASS_DISK. I think
>> the uclass 'disk' is too broad to be useful.
>>
>
> I agree. I raised similar comment before that this just looks a place
> holder for the SCSI stuff.
>
>> So I am wondering whether the decision to use UCLASS_DISK instead of
>> UCLASS_AHCI was a mistake.
>>
>> Perhaps instead we should have:
>>
>> UCLASS_AHCI
>> UCLASS_SCSI
>> UCLASS_MMC
>> etc...
>>
>
> I still think UCLASS_AHCI is not a good name. Maybe UCLASS_ATA as we
> are talking about protocols here (SCSI, MMC).

UCLASS_ATA seems confusing. How would we distinguish IDE and SATA?

BTW since your email I have sent a patch to implement block devices.
>From what I can tell the above approach will work well. I think our
uclasses should mirror the current IF_TYPE values:

/* Interface types: */
#define IF_TYPE_UNKNOWN 0
#define IF_TYPE_IDE 1
#define IF_TYPE_SCSI 2
#define IF_TYPE_ATAPI 3
#define IF_TYPE_USB 4
#define IF_TYPE_DOC 5
#define IF_TYPE_MMC 6
#define IF_TYPE_SD 7
#define IF_TYPE_SATA 8
#define IF_TYPE_HOST 9

>
>> and each of these devices can have a UCLASS_BLK under them (the block 
>> device).
>>
>> Possibly we could even have a dummy UCLASS_DISK device under each of
>> the above, but I'm not sure that is useful.
>>
>> What do you think?
>>
>
> [snip]
>
> Regards,
> Bin

Since this patch is presumably destined for the current release and we
don't intend to change UCLASS_DISK for that release, I think this
patch can go in as is. We can fix it up later. Also note that
scsi_get_device() is not the same as scsi_get_dev().

It would be better to use uclass_get_device() though.

Reviewed-by: Simon Glass 

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


Re: [U-Boot] [PATCH] ARM: zynq: Enable u-boot, dm-pre-reloc for qspi

2016-02-16 Thread Michal Simek
On 16.2.2016 14:05, Nathan Rossi wrote:
> Enable u-boot,dm-pre-reloc for qspi for zc706, zed and microzed.
> 
> Signed-off-by: Nathan Rossi 
> Cc: Albert Aribaud 
> Cc: Michal Simek 
> Cc: Simon Glass 
> ---
>  arch/arm/dts/zynq-microzed.dts | 1 +
>  arch/arm/dts/zynq-zc706.dts| 1 +
>  arch/arm/dts/zynq-zed.dts  | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/arch/arm/dts/zynq-microzed.dts b/arch/arm/dts/zynq-microzed.dts
> index e841a1d..793ab44 100644
> --- a/arch/arm/dts/zynq-microzed.dts
> +++ b/arch/arm/dts/zynq-microzed.dts
> @@ -24,6 +24,7 @@
>  };
>  
>  &qspi {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/dts/zynq-zc706.dts b/arch/arm/dts/zynq-zc706.dts
> index 1ba3a1c..1610520 100644
> --- a/arch/arm/dts/zynq-zc706.dts
> +++ b/arch/arm/dts/zynq-zc706.dts
> @@ -306,6 +306,7 @@
>  };
>  
>  &qspi {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/dts/zynq-zed.dts b/arch/arm/dts/zynq-zed.dts
> index 5ec59e2..ec9b2f7 100644
> --- a/arch/arm/dts/zynq-zed.dts
> +++ b/arch/arm/dts/zynq-zed.dts
> @@ -61,6 +61,7 @@
>  };
>  
>  &qspi {
> + u-boot,dm-pre-reloc;
>   status = "okay";
>  };
>  

Applied.

Thanks,
Michal
> 

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


Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

2016-02-16 Thread Tom Warren
Simon,

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Tuesday, February 16, 2016 9:03 AM
> To: Tom Warren 
> Cc: Stephen Warren ; U-Boot Mailing List  b...@lists.denx.de>; Marcel Ziswiler ; Stephen
> Warren ; Pantelis Antoniou  consulting.com>; Marek Vasut ; Pavel Herrmann
> ; Anatolij Gustschin 
> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
> drivers to driver model
> 
> Hi Tom,
> 
> On 16 February 2016 at 08:47, Tom Warren  wrote:
> >
> > Simon
> >
> > > -Original Message-
> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
> > > Glass
> > > Sent: Sunday, February 14, 2016 6:19 PM
> > > To: Stephen Warren 
> > > Cc: U-Boot Mailing List ; Marcel Ziswiler
> > > ; Tom Warren ;
> > > Stephen Warren ; Pantelis Antoniou
> > > ; Marek Vasut
> > > ; Pavel Herrmann ;
> > > Anatolij Gustschin 
> > > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and
> > > tegra124 video drivers to driver model
> > >
> > > Hi,
> > >
> > > On 1 February 2016 at 17:00, Stephen Warren 
> > > wrote:
> > > >
> > > > On 01/30/2016 04:37 PM, Simon Glass wrote:
> > > >>
> > > >> This series moves these two drivers over to use driver model for video.
> > > >>
> > > >> This involves the following steps:
> > > >> - Sync up some device tree files with Linux
> > > >> - Implement a proper PWM driver
> > > >> - Clean up and unify the driver code
> > > >> - Modify the existing drivers to work with driver model
> > > >>
> > > >> The tegra20 display driver uses device tree bindings invented in
> > > >> 2011 before Linux had this or anyone was able to agree a
> > > >> standard. It seems possible to move it to the new bindings (like
> > > >> tegra124) except for the issue of time delays between stages. It
> > > >> isn't clear how this should work, and Linux implements this by
> > > >> including all LCD definitions in the kernel source code, and not
> > > >> using any delays. This causes strange display artifacts on the
> > > >> display when starting up, but perhaps is harmless to the display.
> > > >> Future work will sync up the device tree more for seaboard, and thus
> tidy this up for nvidia boards.
> > > >>
> > > >> A bug in the keyboard driver is also fixed by this series. The
> > > >> series is tested on seaboard and nyan-big, the two boards I have
> > > >> which support a display.
> > > >>
> > > >> This series is available at u-boot-dm/tegra-working.
> > > >
> > > >
> > > > This changes the name of the output device from "lcd" to "vidconsole".
> > > Anyone who doesn't reset their environment to default when switching
> > > to this new U-Boot will lose their display output because of this.
> > > Is there any way to maintain compatibility?
> > > >
> > > > Aside from that, I don't see any issues on Springbank (Seaboard),
> > > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
> > > > Tested-by: Stephen Warren 
> > >
> > > It looks like some of the patches have been applied and all Tegra
> > > boards are now giving Kconfig warnings.
> > >
> > > Tom Warren, are you able to pick up the rest of the series?
> > I had thought these had already gone in via the dm repo. If not, please list
> those that still need to be picked up and I'll take them in via tegra. Best to
> assign the appropriate ones to me in patchwork. Currently it seems they're all
> assigned to me. Which patches have already been applied?
> 
> I think it was the follow-up patches to add the environment work-around that
> was applied.
> 
> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
> a2931b3 dm: video: Add a temporary work-around for old stdout var
> 
> I see the original v2 series here:
> 
> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
> 
> so that is what needs to be applied I think. Then the Tegra config issue 
> should
> be fixed.
I've applied the 23 v2 DM video patches to u-boot-tegra/master, then rebased 
against current u-boot/master.

I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet 
direct dependencies (DM_VIDEO)' spew for almost every board (w/MAKEALL -s 
tegra).

Am I missing some patches? 
--
nvpublic
> 
> Regards,
> Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [RFC PATCH v4 2/3] common: Convert ulong to phys_addr_t for image addresses

2016-02-16 Thread Simon Glass
Hi York,

On 12 February 2016 at 13:59, York Sun  wrote:
> When dealing with image addresses, ulong has been used. Some files
> are used by both host and target. It is OK for the target, but not
> always enough for host tools including mkimage. This patch replaces
> "ulong" with "phys_addr_t" to make sure addresses are correct for
> both the target and the host.
>
> This issue was found on 32-bit host when compiling for 64-bit target
> to support images with address higher than 32-bit space.
>
> Signed-off-by: York Sun 
>
> ---
>
> Changes in v4:
>   New patch, separated from fixing FIT image.
>
> Changes in v3: None
> Changes in v2: None
>
>  arch/powerpc/lib/bootm.c |4 ++--
>  cmd/ximg.c   |9 +
>  common/bootm.c   |   21 +++--
>  common/bootm_os.c|   14 --
>  common/image-android.c   |6 +++---
>  common/image-fdt.c   |   16 
>  common/image-fit.c   |   27 ++-
>  common/image.c   |   17 ++---
>  include/bootm.h  |6 +++---
>  include/image.h  |   30 ++
>  tools/default_image.c|2 +-
>  11 files changed, 83 insertions(+), 69 deletions(-)
>
> diff --git a/arch/powerpc/lib/bootm.c b/arch/powerpc/lib/bootm.c
> index ef15e7a..794382a 100644
> --- a/arch/powerpc/lib/bootm.c
> +++ b/arch/powerpc/lib/bootm.c
> @@ -47,7 +47,7 @@ static void boot_jump_linux(bootm_headers_t *images)
>  #endif
>
> kernel = (void (*)(bd_t *, ulong, ulong, ulong,
> -  ulong, ulong, ulong))images->ep;
> +  ulong, ulong, ulong))(uintptr_t)images->ep;
> debug ("## Transferring control to Linux (at address %08lx) ...\n",
> (ulong)kernel);
>
> @@ -335,7 +335,7 @@ void boot_jump_vxworks(bootm_headers_t *images)
> WATCHDOG_RESET();
>
> ((void (*)(void *, ulong, ulong, ulong,
> -   ulong, ulong, ulong))images->ep)(images->ft_addr,
> +   ulong, ulong, ulong))(uintptr_t)images->ep)(images->ft_addr,
> 0, 0, EPAPR_MAGIC, getenv_bootm_mapsize(), 0, 0);
>  }
>  #endif
> diff --git a/cmd/ximg.c b/cmd/ximg.c
> index d033c15..70d6d14 100644
> --- a/cmd/ximg.c
> +++ b/cmd/ximg.c
> @@ -33,7 +33,8 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char * 
> const argv[])
>  {
> ulong   addr = load_addr;
> ulong   dest = 0;
> -   ulong   data, len;
> +   phys_addr_t data;
> +   ulong   len;
> int verify;
> int part = 0;
>  #if defined(CONFIG_IMAGE_FORMAT_LEGACY)
> @@ -173,7 +174,7 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, char 
> * const argv[])
> return 1;
> }
>
> -   data = (ulong)fit_data;
> +   data = (phys_addr_t)(uintptr_t)fit_data;
> len = (ulong)fit_len;
> break;
>  #endif
> @@ -205,14 +206,14 @@ do_imgextract(cmd_tbl_t * cmdtp, int flag, int argc, 
> char * const argv[])
> }
>  #else  /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */
> printf("   Loading part %d ... ", part);
> -   memmove((char *) dest, (char *)data, len);
> +   memmove((char *)dest, (char *)(uintptr_t)data, len);
>  #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */
> break;
>  #ifdef CONFIG_GZIP
> case IH_COMP_GZIP:
> printf("   Uncompressing part %d ... ", part);
> if (gunzip((void *) dest, unc_len,
> -  (uchar *) data, &len) != 0) {
> +  (uchar *)(uintptr_t)data, &len) != 0) {

The uintptr_t cast presumably defeats the warning. Is the intention to
convert a 64-bit value to 32-bit?

Is it true that sizeof(phys_addr_t) is always sizeof(ulong) on the target?

> puts("GUNZIP ERROR - image not loaded\n");
> return 1;
> }
> diff --git a/common/bootm.c b/common/bootm.c
> index 99d574d..785858c 100644
> --- a/common/bootm.c
> +++ b/common/bootm.c
> @@ -43,7 +43,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
>  static const void *boot_get_kernel(cmd_tbl_t *cmdtp, int flag, int argc,
>char * const argv[], bootm_headers_t 
> *images,
> -  ulong *os_data, ulong *os_len);
> +  phys_addr_t *os_data, ulong *os_len);
>
>  #ifdef CONFIG_LMB
>  static void boot_start_lmb(bootm_headers_t *images)
> @@ -325,9 +325,9 @@ static int handle_decomp_error(int comp_type, size_t 
> uncomp_size,
> return BOOTM_ERR_RESET;
>  }
>
> -int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
> -  void *load_buf, void *im

Re: [U-Boot] [PATCH 3/3] spi: omap3: Convert to driver model

2016-02-16 Thread Tom Rini
On Tue, Feb 16, 2016 at 09:00:28AM -0700, Simon Glass wrote:
> On 11 February 2016 at 12:00, Jagan Teki  wrote:
> > After this conversion the driver will able to support
> > both dm and non-dm and code is more extensible like we
> > can remove the non-dm part simply without touching anycode
> > if all the boards which are using this driver become dm driven.
> >
> > Cc: Tom Rini 
> > Cc: Simon Glass 
> > Cc: Christophe Ricard 
> > Signed-off-by: Jagan Teki 
> > ---
> >  drivers/spi/omap3_spi.c | 678 
> > +---
> >  1 file changed, 407 insertions(+), 271 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> Can CONFIG_OMAP3_SPI_D0_D1_SWAPPED be moved to device tree for the DM version?

Yes, there is already a binding for this:
- ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
  input. The default is D0 as input and
  D1 as output.


-- 
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] test/py: only check for SPL signature if SPL uses serial output

2016-02-16 Thread Stephen Warren

On 02/16/2016 05:13 AM, Heiko Schocher wrote:

check for U-Boot SPL signature only if SPL really has
a serial output. So check if CONFIG_SPL_SERIAL_SUPPORT
is active in board config.


Nit: That's wrapped really narrow. Any chance of wrapping to more like 
72-74 characters?



diff --git a/test/py/u_boot_console_base.py b/test/py/u_boot_console_base.py
index bc2bd76..f888d5c 100644



  if self.config.buildconfig.get('config_spl', False) == 'y':
-m = self.p.expect([pattern_u_boot_spl_signon] + 
self.bad_patterns)
-if m != 0:
-raise Exception('Bad pattern found on console: ' +
-self.bad_pattern_ids[m - 1])
+if self.config.buildconfig.get('config_spl_serial_support',
+   False) == 'y':
+m = self.p.expect([pattern_u_boot_spl_signon] +
+  self.bad_patterns)
+if m != 0:
+raise Exception('Bad pattern found on console: ' +
+self.bad_pattern_ids[m - 1])


Conceptually this change looks fine. Rather than using nested ifs, why 
not write "if a and b:" and so avoid adding an extra indent level? I'd 
also introduce some variables to shorten the text a bit:


bcfg = u_boot_console.config.buildconfig
if bcfg.get('config_spl', 'n') == 'y' and
bcfg.get('config_spl_serial_support', 'n') == 'y':
...

or:

bcfg = u_boot_console.config.buildconfig
config_spl = bcfg.get('config_spl', 'n') == 'y'
config_spl_serial_support = bcfg.get('config_spl_serial_support',
'n') == 'y'
if config_spl and config_spl_serial_support:
...

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


Re: [U-Boot] test/py main_signon

2016-02-16 Thread Stephen Warren

On 02/16/2016 09:04 AM, Michal Simek wrote:

Hi Heiko,

On 16.2.2016 14:32, Heiko Schocher wrote:

Hello Michal,

Am 16.02.2016 um 13:12 schrieb Michal Simek:

Hi Stephen,

trying to run the latest testing on zynq board and getting this
main_signon error.

This is what I am running
./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
and getting below.


Does this board has SPL support without SPL serial output?


I do load u-boot via jtag that's why SPL logs are not visible.


If so, can you try my patch:
http://patchwork.ozlabs.org/patch/583348/


I have applied your patch but it is still not working.

If I run full flow with SPL then I can't see any issue.


I assume this is resolved then?

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


Re: [U-Boot] how does board_init_f() -> board_init_r?

2016-02-16 Thread Stephen Warren

On 02/16/2016 09:01 AM, Simon Glass wrote:

+Stephen who will know more

Hi,

On 13 February 2016 at 18:52, quantumlight  wrote:

I am trying to modify the bootloader code for NVIDIA's jetson board.

So I am looking at crt0.S. It seems that two builds happen, one with
CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin
and spl/u-boot-spl.bin.


SPL is built with ARMv4t
U-Boot proper is built with ARMv7

That's why SPL is used on Tegra. The SPL does not actually load
U-Boot. In fact both are bundle together and loaded at the same time.
SPL simply jumps to U-Boot when needed.


There's some more background on this topic at:

ftp://download.nvidia.com/tegra-public-appnotes/index.html

In particular, see the "Tegra Boot Flow" link/document.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video drivers to driver model

2016-02-16 Thread Simon Glass
Hi Tom,

On 16 February 2016 at 09:23, Tom Warren  wrote:
> Simon,
>
>> -Original Message-
>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> Sent: Tuesday, February 16, 2016 9:03 AM
>> To: Tom Warren 
>> Cc: Stephen Warren ; U-Boot Mailing List > b...@lists.denx.de>; Marcel Ziswiler ; Stephen
>> Warren ; Pantelis Antoniou > consulting.com>; Marek Vasut ; Pavel Herrmann
>> ; Anatolij Gustschin 
>> Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and tegra124 video
>> drivers to driver model
>>
>> Hi Tom,
>>
>> On 16 February 2016 at 08:47, Tom Warren  wrote:
>> >
>> > Simon
>> >
>> > > -Original Message-
>> > > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
>> > > Glass
>> > > Sent: Sunday, February 14, 2016 6:19 PM
>> > > To: Stephen Warren 
>> > > Cc: U-Boot Mailing List ; Marcel Ziswiler
>> > > ; Tom Warren ;
>> > > Stephen Warren ; Pantelis Antoniou
>> > > ; Marek Vasut
>> > > ; Pavel Herrmann ;
>> > > Anatolij Gustschin 
>> > > Subject: Re: [PATCH v2 00/23] dm: tegra: Convert tegra20 and
>> > > tegra124 video drivers to driver model
>> > >
>> > > Hi,
>> > >
>> > > On 1 February 2016 at 17:00, Stephen Warren 
>> > > wrote:
>> > > >
>> > > > On 01/30/2016 04:37 PM, Simon Glass wrote:
>> > > >>
>> > > >> This series moves these two drivers over to use driver model for 
>> > > >> video.
>> > > >>
>> > > >> This involves the following steps:
>> > > >> - Sync up some device tree files with Linux
>> > > >> - Implement a proper PWM driver
>> > > >> - Clean up and unify the driver code
>> > > >> - Modify the existing drivers to work with driver model
>> > > >>
>> > > >> The tegra20 display driver uses device tree bindings invented in
>> > > >> 2011 before Linux had this or anyone was able to agree a
>> > > >> standard. It seems possible to move it to the new bindings (like
>> > > >> tegra124) except for the issue of time delays between stages. It
>> > > >> isn't clear how this should work, and Linux implements this by
>> > > >> including all LCD definitions in the kernel source code, and not
>> > > >> using any delays. This causes strange display artifacts on the
>> > > >> display when starting up, but perhaps is harmless to the display.
>> > > >> Future work will sync up the device tree more for seaboard, and thus
>> tidy this up for nvidia boards.
>> > > >>
>> > > >> A bug in the keyboard driver is also fixed by this series. The
>> > > >> series is tested on seaboard and nyan-big, the two boards I have
>> > > >> which support a display.
>> > > >>
>> > > >> This series is available at u-boot-dm/tegra-working.
>> > > >
>> > > >
>> > > > This changes the name of the output device from "lcd" to "vidconsole".
>> > > Anyone who doesn't reset their environment to default when switching
>> > > to this new U-Boot will lose their display output because of this.
>> > > Is there any way to maintain compatibility?
>> > > >
>> > > > Aside from that, I don't see any issues on Springbank (Seaboard),
>> > > > Harmony, Ventana, Paz00, or p2371-2180, so the series,
>> > > > Tested-by: Stephen Warren 
>> > >
>> > > It looks like some of the patches have been applied and all Tegra
>> > > boards are now giving Kconfig warnings.
>> > >
>> > > Tom Warren, are you able to pick up the rest of the series?
>> > I had thought these had already gone in via the dm repo. If not, please 
>> > list
>> those that still need to be picked up and I'll take them in via tegra. Best 
>> to
>> assign the appropriate ones to me in patchwork. Currently it seems they're 
>> all
>> assigned to me. Which patches have already been applied?
>>
>> I think it was the follow-up patches to add the environment work-around that
>> was applied.
>>
>> 6c88b51 video: tegra: Enable the 'lcd' env variable work-around
>> a2931b3 dm: video: Add a temporary work-around for old stdout var
>>
>> I see the original v2 series here:
>>
>> http://patchwork.ozlabs.org/project/uboot/list/?delegate=4839
>>
>> so that is what needs to be applied I think. Then the Tegra config issue 
>> should
>> be fixed.
> I've applied the 23 v2 DM video patches to u-boot-tegra/master, then rebased 
> against current u-boot/master.
>
> I see the 'warning: (TEGRA_COMMON) selects VIDCONSOLE_AS_LCD which has unmet 
> direct dependencies (DM_VIDEO)' spew for almost every board (w/MAKEALL -s 
> tegra).
>
> Am I missing some patches?

I'll make some time to look but I am tied up most of the day so it
will be later, sorry.

The original series is at u-boot-dm/rke-working if that helps.

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


[U-Boot] [PATCH] usb: gadget: composite: Correct recovery path for register

2016-02-16 Thread Semen Protsenko
From: Sam Protsenko 

In case when usb_composite_register() failed once (for whatever reason),
it will fail further even if all conditions are correct. Example:

=> fastboot 2
Invalid Controller Index
couldn't find an available UDC
g_dnl_register: failed!, error: -19
exit not allowed from main input shell.

=> fastboot 0
g_dnl_register: failed!, error: -22
exit not allowed from main input shell.

Despite that 0 is correct index for USB controller, "fastboot 0" command
will fail, because "composite" structure wasn't cleared properly on
previous fail (on "fastboot 2" command).

This patch fixes that erroneous behavior, allowing us to use composite
even after previous failure.

Signed-off-by: Sam Protsenko 
---
 drivers/usb/gadget/composite.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 60f9272..d0ee784 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1077,6 +1077,8 @@ static struct usb_gadget_driver composite_driver = {
  */
 int usb_composite_register(struct usb_composite_driver *driver)
 {
+   int res;
+
if (!driver || !driver->dev || !driver->bind || composite)
return -EINVAL;
 
@@ -1084,7 +1086,11 @@ int usb_composite_register(struct usb_composite_driver 
*driver)
driver->name = "composite";
composite = driver;
 
-   return usb_gadget_register_driver(&composite_driver);
+   res = usb_gadget_register_driver(&composite_driver);
+   if (res != 0)
+   composite = NULL;
+
+   return res;
 }
 
 /**
-- 
2.7.0

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


[U-Boot] Beaglebone Black broken since commit fd61d39970b9901217efc7536d9f3a61b4e1752a

2016-02-16 Thread Guillaume Gardet

Hi,

Beaglebone black (am335x_evm_defconfig) is broken (with MMC boot and u-boot.img 
on ext4 partition).
I bisected it to commit fd61d39970b9901217efc7536d9f3a61b4e1752a
spl: mmc: add break statements in spl_mmc_load_image()
from Nikita Kiryanov (in Cc).

Working image gives:

U-Boot SPL 2016.01-rc1-00036-g483ab3d (Feb 16 2016 - 19:04:10)
bad magic
bad magic
spl_register_fat_device: fat register err - -1
spl_register_fat_device: fat register err - -1
spl_load_image_fat: error reading image u-boot.img, err - -1
spl: ext4fs_open failed
spl: ext4fs_open failed
spl_load_image_ext: error reading image uImage, err - -1


U-Boot 2016.01-rc1-00033-g9884f44 (Feb 16 2016 - 18:55:52 +0100)


Since this commit, we get:

U-Boot SPL 2016.01-rc1-00037-gfd61d39 (Feb 16 2016 - 19:01:54)
bad magic
bad magic
### ERROR ### Please RESET the board ###



Guillaume

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


[U-Boot] [PATCH v2] spi: omap3: Convert to driver model

2016-02-16 Thread Jagan Teki
After this conversion the driver will able to support
both dm and non-dm and code is more extensible like we
can remove the non-dm part simply without touching anycode
if all the boards which are using this driver become dm driven.

Cc: Tom Rini 
Reviewed-by: Simon Glass 
Acked-by: Christophe Ricard 
Signed-off-by: Jagan Teki 
---
Changes for v2:
- Added dm pindir-d0-out-d1-in logic
- Updated comment about 4-wire master mode as per Linux.

 drivers/spi/omap3_spi.c | 684 +---
 1 file changed, 413 insertions(+), 271 deletions(-)

diff --git a/drivers/spi/omap3_spi.c b/drivers/spi/omap3_spi.c
index 8b0f665..a04340b 100644
--- a/drivers/spi/omap3_spi.c
+++ b/drivers/spi/omap3_spi.c
@@ -1,4 +1,6 @@
 /*
+ * Copyright (C) 2016 Jagan Teki 
+ *
  * Copyright (C) 2010 Dirk Behme 
  *
  * Driver for McSPI controller on OMAP3. Based on davinci_spi.c
@@ -15,6 +17,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -65,6 +68,8 @@
 #define OMAP3_MCSPI_CHCTRL_DIS (0 << 0)
 
 #define OMAP3_MCSPI_WAKEUPENABLE_WKEN  BIT(0)
+#define MCSPI_PINDIR_D0_IN_D1_OUT  0
+#define MCSPI_PINDIR_D0_OUT_D1_IN  1
 
 #define OMAP3_MCSPI_MAX_FREQ   4800
 #define SPI_WAIT_TIMEOUT   10
@@ -93,312 +98,123 @@ struct mcspi {
/* channel3: 0x68 - 0x78, bus 0 */
 };
 
-struct omap3_spi_slave {
-   struct spi_slave slave;
+struct omap3_spi_priv {
struct mcspi *regs;
+   unsigned int cs;
unsigned int freq;
unsigned int mode;
+   unsigned int wordlen;
+   unsigned int pin_dir:1;
 };
 
-static inline struct omap3_spi_slave *to_omap3_spi(struct spi_slave *slave)
-{
-   return container_of(slave, struct omap3_spi_slave, slave);
-}
-
-static void spi_reset(struct omap3_spi_slave *ds)
-{
-   unsigned int tmp;
-
-   writel(OMAP3_MCSPI_SYSCONFIG_SOFTRESET, &ds->regs->sysconfig);
-   do {
-   tmp = readl(&ds->regs->sysstatus);
-   } while (!(tmp & OMAP3_MCSPI_SYSSTATUS_RESETDONE));
-
-   writel(OMAP3_MCSPI_SYSCONFIG_AUTOIDLE |
-OMAP3_MCSPI_SYSCONFIG_ENAWAKEUP |
-OMAP3_MCSPI_SYSCONFIG_SMARTIDLE,
-&ds->regs->sysconfig);
-
-   writel(OMAP3_MCSPI_WAKEUPENABLE_WKEN, &ds->regs->wakeupenable);
-}
-
-static void omap3_spi_write_chconf(struct omap3_spi_slave *ds, int val)
+static void omap3_spi_write_chconf(struct omap3_spi_priv *priv, int val)
 {
-   writel(val, &ds->regs->channel[ds->slave.cs].chconf);
+   writel(val, &priv->regs->channel[priv->cs].chconf);
/* Flash post writes to make immediate effect */
-   readl(&ds->regs->channel[ds->slave.cs].chconf);
+   readl(&priv->regs->channel[priv->cs].chconf);
 }
 
-static void omap3_spi_set_enable(struct omap3_spi_slave *ds, int enable)
+static void omap3_spi_set_enable(struct omap3_spi_priv *priv, int enable)
 {
-   writel(enable, &ds->regs->channel[ds->slave.cs].chctrl);
+   writel(enable, &priv->regs->channel[priv->cs].chctrl);
/* Flash post writes to make immediate effect */
-   readl(&ds->regs->channel[ds->slave.cs].chctrl);
-}
-
-void spi_init()
-{
-   /* do nothing */
+   readl(&priv->regs->channel[priv->cs].chctrl);
 }
 
-struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
- unsigned int max_hz, unsigned int mode)
-{
-   struct omap3_spi_slave  *ds;
-   struct mcspi *regs;
-
-   /*
-* OMAP3 McSPI (MultiChannel SPI) has 4 busses (modules)
-* with different number of chip selects (CS, channels):
-* McSPI1 has 4 CS (bus 0, cs 0 - 3)
-* McSPI2 has 2 CS (bus 1, cs 0 - 1)
-* McSPI3 has 2 CS (bus 2, cs 0 - 1)
-* McSPI4 has 1 CS (bus 3, cs 0)
-*/
-
-   switch (bus) {
-   case 0:
-   regs = (struct mcspi *)OMAP3_MCSPI1_BASE;
-   break;
-#ifdef OMAP3_MCSPI2_BASE
-   case 1:
-   regs = (struct mcspi *)OMAP3_MCSPI2_BASE;
-   break;
-#endif
-#ifdef OMAP3_MCSPI3_BASE
-   case 2:
-   regs = (struct mcspi *)OMAP3_MCSPI3_BASE;
-   break;
-#endif
-#ifdef OMAP3_MCSPI4_BASE
-   case 3:
-   regs = (struct mcspi *)OMAP3_MCSPI4_BASE;
-   break;
-#endif
-   default:
-   printf("SPI error: unsupported bus %i. \
-   Supported busses 0 - 3\n", bus);
-   return NULL;
-   }
-
-   if (((bus == 0) && (cs > 3)) ||
-   ((bus == 1) && (cs > 1)) ||
-   ((bus == 2) && (cs > 1)) ||
-   ((bus == 3) && (cs > 0))) {
-   printf("SPI error: unsupported chip select %i \
-   on bus %i\n", cs, bus);
-   return NULL;
-   }
-
-   if (max_hz > OMAP3_MCSPI_MAX_FREQ) {
-   printf

Re: [U-Boot] test/py main_signon

2016-02-16 Thread Michal Simek
Hi Stephen,

2016-02-16 17:39 GMT+01:00 Stephen Warren :

> On 02/16/2016 09:04 AM, Michal Simek wrote:
>
>> Hi Heiko,
>>
>> On 16.2.2016 14:32, Heiko Schocher wrote:
>>
>>> Hello Michal,
>>>
>>> Am 16.02.2016 um 13:12 schrieb Michal Simek:
>>>
 Hi Stephen,

 trying to run the latest testing on zynq board and getting this
 main_signon error.

 This is what I am running
 ./test/py/test.py --bd zynq_zc702  --build --board-identity zc702
 and getting below.

>>>
>>> Does this board has SPL support without SPL serial output?
>>>
>>
>> I do load u-boot via jtag that's why SPL logs are not visible.
>>
>> If so, can you try my patch:
>>> http://patchwork.ozlabs.org/patch/583348/
>>>
>>
>> I have applied your patch but it is still not working.
>>
>> If I run full flow with SPL then I can't see any issue.
>>
>
> I assume this is resolved then?
>

Unfortunately both cases should work because SPL is not only one first
stage bootloader
which can be used. I didn't test zynqmp but there is no SPL and the same
problem is
probably there too. Or is there any dependency that if SPL is not build
than testing system
is not expecting it?

I will look tmr at jtag boot mode with SPL if I can get it work.

Thanks,
Michal

-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v7 09/76] mtd: spi-nor: Add dm spi-nor probing

2016-02-16 Thread Jagan Teki
This patch adds driver-model probe from cmd_sf through
MTD_DM_SPI_NOR which is depends on MTD and DM_SPI uclass.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR
- Fix proper kconfig select for CONFIG_MTD_DM_SPI_NOR

 cmd/sf.c|  4 ++--
 common/env_sf.c |  4 ++--
 drivers/mtd/spi-nor/Kconfig |  7 +++
 drivers/mtd/spi-nor/Makefile|  2 ++
 drivers/mtd/spi-nor/spi-nor-probe.c | 30 ++
 include/spi_flash.h | 11 ++-
 6 files changed, 53 insertions(+), 5 deletions(-)
 create mode 100644 drivers/mtd/spi-nor/spi-nor-probe.c

diff --git a/cmd/sf.c b/cmd/sf.c
index 42862d9..528fc4d 100644
--- a/cmd/sf.c
+++ b/cmd/sf.c
@@ -85,7 +85,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
unsigned int speed = CONFIG_SF_DEFAULT_SPEED;
unsigned int mode = CONFIG_SF_DEFAULT_MODE;
char *endp;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new, *bus_dev;
int ret;
 #else
@@ -118,7 +118,7 @@ static int do_spi_flash_probe(int argc, char * const argv[])
return -1;
}
 
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
/* Remove the old device, otherwise probe will just be a nop */
ret = spi_find_bus_and_cs(bus, cs, &bus_dev, &new);
if (!ret) {
diff --git a/common/env_sf.c b/common/env_sf.c
index 892e6cb..652ed0b 100644
--- a/common/env_sf.c
+++ b/common/env_sf.c
@@ -52,7 +52,7 @@ int saveenv(void)
char*saved_buffer = NULL, flag = OBSOLETE_FLAG;
u32 saved_size, saved_offset, sector = 1;
int ret;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new;
 
ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
@@ -242,7 +242,7 @@ int saveenv(void)
char*saved_buffer = NULL;
int ret = 1;
env_t   env_new;
-#ifdef CONFIG_DM_SPI_FLASH
+#if defined(CONFIG_DM_SPI_FLASH) || defined (CONFIG_DM_MTD_SPI_NOR)
struct udevice *new;
 
ret = spi_flash_probe_bus_cs(CONFIG_ENV_SPI_BUS, CONFIG_ENV_SPI_CS,
diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 374cdcb..342164d 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -1,5 +1,6 @@
 menuconfig MTD_SPI_NOR
tristate "SPI-NOR device support"
+   select DM_MTD_SPI_NOR if DM_SPI && MTD
help
  This is the core SPI NOR framework which can be used to interact 
SPI-NOR
  to SPI driver interface layer and the SPI-NOR controller driver.
@@ -12,6 +13,12 @@ menuconfig MTD_SPI_NOR
  SPI-NOR controller drivers for SPI-NOR device access. Note that from 
SPI-NOR
  core to SPI drivers there should be an interface layer.
 
+config DM_MTD_SPI_NOR
+   bool "MTD driver model for SPI-NOR"
+   help
+ This is enables MTD driver model support for SPI-NOR. Both MTD and SPI
+ driver models need to define for enabling this support.
+
 if MTD_SPI_NOR
 
 config MTD_M25P80
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 9ab6e3d..2f41630 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -6,6 +6,8 @@
 ifdef CONFIG_MTD_SPI_NOR
 obj-y += spi-nor.o
 obj-y += spi-nor-ids.o
+
+obj-$(CONFIG_DM_MTD_SPI_NOR)   += spi-nor-probe.o
 endif
 
 obj-$(CONFIG_MTD_M25P80)   += m25p80.o
diff --git a/drivers/mtd/spi-nor/spi-nor-probe.c 
b/drivers/mtd/spi-nor/spi-nor-probe.c
new file mode 100644
index 000..c808a7d
--- /dev/null
+++ b/drivers/mtd/spi-nor/spi-nor-probe.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
+  unsigned int max_hz, unsigned int spi_mode,
+  struct udevice **devp)
+{
+   struct spi_slave *slave;
+   struct udevice *bus;
+   char name[30], *str;
+   int ret;
+
+   snprintf(name, sizeof(name), "spi-nor@%d:%d", busnum, cs);
+   str = strdup(name);
+   ret = spi_get_bus_and_cs(busnum, cs, max_hz, spi_mode,
+"m25p80", str, &bus, &slave);
+   if (ret)
+   return ret;
+
+   *devp = slave->dev;
+   return 0;
+}
diff --git a/include/spi_flash.h b/include/spi_flash.h
index d0ce9e7..af9f89b 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -108,6 +108,14 @@ struct spi_flash {
 #endif
 };
 
+#if defined(CONFIG_MTD_SPI_NOR) && defined(CONFIG_DM_MTD_SPI_NOR)
+
+int spi

[U-Boot] [PATCH v7 12/76] mtd: spi-nor: m25p80: Add spi_nor support for non-dm

2016-02-16 Thread Jagan Teki
Like adding spi_nor support for dm-driven code in m25p80
add the same way for non-dm code as well.
- allocate spi_nor{}
- basic initilization
- install hooks
- call to spi-nor core, using spi_nor_scan
- register with mtd core

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR

 drivers/mtd/spi-nor/m25p80.c | 108 ++-
 include/spi_flash.h  |  18 +++-
 2 files changed, 112 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/spi-nor/m25p80.c b/drivers/mtd/spi-nor/m25p80.c
index 57e54d0..aba98b3 100644
--- a/drivers/mtd/spi-nor/m25p80.c
+++ b/drivers/mtd/spi-nor/m25p80.c
@@ -19,6 +19,9 @@
 struct m25p {
struct spi_slave*spi;
struct spi_nor  spi_nor;
+#ifndef CONFIG_DM_MTD_SPI_NOR
+   struct mtd_info mtd;
+#endif
 };
 
 static int spi_read_then_write(struct spi_slave *spi, const u8 *cmd,
@@ -179,16 +182,13 @@ static int m25p80_write(struct spi_nor *nor, const u8 
*cmd, size_t cmd_len,
return ret;
 }
 
-static int m25p_probe(struct udevice *dev)
+static int m25p80_spi_nor(struct spi_nor *nor)
 {
-   struct spi_slave *spi = dev_get_parent_priv(dev);
-   struct mtd_info *mtd = dev_get_uclass_priv(dev);
-   struct m25p *flash = dev_get_priv(dev);
-   struct spi_nor *nor;
+   struct mtd_info *mtd = nor->mtd;
+   struct m25p *flash = nor->priv;
+   struct spi_slave *spi = flash->spi;
int ret;
 
-   nor = &flash->spi_nor;
-
/* install hooks */
nor->read_mmap = m25p80_read_mmap;
nor->read = m25p80_read;
@@ -196,10 +196,6 @@ static int m25p_probe(struct udevice *dev)
nor->read_reg = m25p80_read_reg;
nor->write_reg = m25p80_write_reg;
 
-   nor->mtd = mtd;
-   nor->priv = flash;
-   flash->spi = spi;
-
/* claim spi bus */
ret = spi_claim_bus(spi);
if (ret) {
@@ -251,10 +247,33 @@ err_scan:
spi_release_bus(spi);
 err_mtd:
spi_free_slave(spi);
-   device_remove(dev);
return ret;
 }
 
+#ifdef CONFIG_DM_MTD_SPI_NOR
+static int m25p_probe(struct udevice *dev)
+{
+   struct spi_slave *spi = dev_get_parent_priv(dev);
+   struct mtd_info *mtd = dev_get_uclass_priv(dev);
+   struct m25p *flash = dev_get_priv(dev);
+   struct spi_nor *nor;
+   int ret;
+
+   nor = &flash->spi_nor;
+
+   nor->mtd = mtd;
+   nor->priv = flash;
+   flash->spi = spi;
+
+   ret = m25p80_spi_nor(nor);
+   if (ret) {
+   device_remove(dev);
+   return ret;
+   }
+
+   return 0;
+}
+
 static const struct udevice_id m25p_ids[] = {
/*
 * Generic compatibility for SPI NOR that can be identified by the
@@ -271,3 +290,68 @@ U_BOOT_DRIVER(m25p80) = {
.probe  = m25p_probe,
.priv_auto_alloc_size = sizeof(struct m25p),
 };
+
+#else
+
+static struct mtd_info *m25p80_probe_tail(struct spi_slave *bus)
+{
+   struct m25p *flash;
+   struct spi_nor *nor;
+   int ret;
+
+   flash = calloc(1, sizeof(*flash));
+   if (!flash) {
+   debug("mp25p80: failed to allocate m25p\n");
+   return NULL;
+   }
+
+   nor = &flash->spi_nor;
+   nor->mtd = &flash->mtd;
+
+   nor->priv = flash;
+   flash->spi = bus;
+
+   ret = m25p80_spi_nor(nor);
+   if (ret) {
+   free(flash);
+   return NULL;
+   }
+
+   return nor->mtd;
+}
+
+struct mtd_info *spi_flash_probe(unsigned int busnum, unsigned int cs,
+unsigned int max_hz, unsigned int spi_mode)
+{
+   struct spi_slave *bus;
+
+   bus = spi_setup_slave(busnum, cs, max_hz, spi_mode);
+   if (!bus)
+   return NULL;
+   return m25p80_probe_tail(bus);
+}
+
+#ifdef CONFIG_OF_SPI_FLASH
+struct mtd_info *spi_flash_probe_fdt(const void *blob, int slave_node,
+int spi_node)
+{
+   struct spi_slave *bus;
+
+   bus = spi_setup_slave_fdt(blob, slave_node, spi_node);
+   if (!bus)
+   return NULL;
+   return m25p80_probe_tail(bus);
+}
+#endif
+
+void spi_flash_free(struct mtd_info *info)
+{
+   struct spi_nor *nor = info->priv;
+   struct m25p *flash = nor->priv;
+
+   del_mtd_device(info);
+   spi_free_slave(flash->spi);
+   free(flash);
+}
+
+#endif /* CONFIG_DM_MTD_SPI_NOR */
diff --git a/include/spi_flash.h b/include/spi_flash.h
index 3bf6c17..ea04c3a 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -108,10 +108,12 @@ struct spi_flash {
 #endif
 };
 
-#if defined(CONFIG_MTD_SPI_NOR) && defined(CONFIG_DM_MTD_SPI_NOR)
+#ifdef CONFIG_MTD_SPI_NOR
 
 typedef struct mtd_info spi_flash_t;
 
+#ifdef CONFIG_DM_MTD_SPI_NOR
+
 int spi_flash_probe_bus_cs(unsigned int busnum, unsigned 

[U-Boot] [PATCH v7 16/76] spi_flash: Use mtd_info operation for SPI-NOR

2016-02-16 Thread Jagan Teki
Since spi-nor is using mtd layer for flash operations
this patch used mtd ops from user commands instead of
legacy spi_flash{} ops.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes for v7:
- Rename CONFIG_MTD_DM_SPI_NOR to CONFIG_DM_MTD_SPI_NOR

 include/spi_flash.h | 60 ++---
 1 file changed, 48 insertions(+), 12 deletions(-)

diff --git a/include/spi_flash.h b/include/spi_flash.h
index 181b31e..09a7ce6 100644
--- a/include/spi_flash.h
+++ b/include/spi_flash.h
@@ -12,6 +12,7 @@
 
 #include /* Because we dereference struct udevice here */
 #include 
+#include 
 
 #ifndef CONFIG_SF_DEFAULT_SPEED
 # define CONFIG_SF_DEFAULT_SPEED   100
@@ -112,6 +113,39 @@ struct spi_flash {
 
 typedef struct mtd_info spi_flash_t;
 
+static inline int spi_flash_read(spi_flash_t *info, u32 offset,
+size_t len, void *buf)
+{
+   return mtd_read(info, offset, len, &len, (u_char *)buf);
+}
+
+static inline int spi_flash_write(spi_flash_t *info, u32 offset,
+ size_t len, const void *buf)
+{
+   return mtd_write(info, offset, len, &len, (u_char *)buf);
+}
+
+static inline int spi_flash_erase(spi_flash_t *info, u32 offset, size_t len)
+{
+   struct erase_info instr;
+
+   instr.mtd = info;
+   instr.addr = offset;
+   instr.len = len;
+   instr.callback = 0;
+
+   return mtd_erase(info, &instr);
+}
+
+static inline int spi_flash_protect(spi_flash_t *info, u32 ofs,
+   u32 len, bool prot)
+{
+   if (prot)
+   return mtd_lock(info, ofs, len);
+   else
+   return mtd_unlock(info, ofs, len);
+}
+
 #ifdef CONFIG_DM_MTD_SPI_NOR
 
 int spi_flash_probe_bus_cs(unsigned int busnum, unsigned int cs,
@@ -137,6 +171,20 @@ void spi_flash_free(spi_flash_t *flash);
 
 #endif /* CONFIG_DM_MTD_SPI_NOR */
 
+#else
+
+static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
+   bool prot)
+{
+   if (!flash->flash_lock || !flash->flash_unlock)
+   return -EOPNOTSUPP;
+
+   if (prot)
+   return flash->flash_lock(flash, ofs, len);
+   else
+   return flash->flash_unlock(flash, ofs, len);
+}
+
 #endif /* CONFIG_MTD_SPI_NOR */
 
 struct dm_spi_flash_ops {
@@ -259,18 +307,6 @@ static inline int spi_flash_erase(struct spi_flash *flash, 
u32 offset,
 }
 #endif
 
-static inline int spi_flash_protect(struct spi_flash *flash, u32 ofs, u32 len,
-   bool prot)
-{
-   if (!flash->flash_lock || !flash->flash_unlock)
-   return -EOPNOTSUPP;
-
-   if (prot)
-   return flash->flash_lock(flash, ofs, len);
-   else
-   return flash->flash_unlock(flash, ofs, len);
-}
-
 void spi_boot(void) __noreturn;
 void spi_spl_load_image(uint32_t offs, unsigned int size, void *vdst);
 
-- 
1.9.1

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


[U-Boot] [PATCH v7 73/76] configs: Enable CONFIG_SPL_MTD_SUPPORT

2016-02-16 Thread Jagan Teki
Since SPI-NOR is driven by MTD core, so the SPL
need to use the MTD as well.

Cc: Simon Glass 
Cc: Bin Meng 
Cc: Mugunthan V N 
Cc: Michal Simek 
Cc: Siva Durga Prasad Paladugu 
Signed-off-by: Jagan Teki 
---
Changes v7:
- Remove duplicate define on CONFIG_SPL_MTD_SUPPORT for zynq

 include/configs/P1010RDB.h | 1 +
 include/configs/P1022DS.h  | 1 +
 include/configs/T102xQDS.h | 1 +
 include/configs/T102xRDB.h | 1 +
 include/configs/T104xRDB.h | 1 +
 include/configs/T208xQDS.h | 1 +
 include/configs/T208xRDB.h | 1 +
 include/configs/am335x_evm.h   | 1 +
 include/configs/at91sam9n12ek.h| 1 +
 include/configs/at91sam9x5ek.h | 1 +
 include/configs/bav335x.h  | 1 +
 include/configs/cgtqmx6eval.h  | 1 +
 include/configs/chromebook_jerry.h | 1 +
 include/configs/clearfog.h | 1 +
 include/configs/cm_fx6.h   | 1 +
 include/configs/cm_t43.h   | 1 +
 include/configs/da850evm.h | 2 ++
 include/configs/db-88f6820-gp.h| 1 +
 include/configs/db-mv784mp-gp.h| 1 +
 include/configs/dra7xx_evm.h   | 1 +
 include/configs/ds414.h| 1 +
 include/configs/maxbcm.h   | 1 +
 include/configs/omapl138_lcdk.h| 1 +
 include/configs/ot1200.h   | 1 +
 include/configs/p1_p2_rdb_pc.h | 1 +
 include/configs/pcm051.h   | 1 +
 include/configs/sama5d2_xplained.h | 1 +
 include/configs/sama5d3xek.h   | 1 +
 include/configs/sama5d4_xplained.h | 1 +
 include/configs/sama5d4ek.h| 1 +
 include/configs/siemens-am33x-common.h | 1 +
 include/configs/socfpga_common.h   | 1 +
 include/configs/taurus.h   | 1 +
 include/configs/theadorable.h  | 1 +
 include/configs/ti_armv7_keystone2.h   | 1 +
 include/configs/tseries.h  | 1 +
 36 files changed, 37 insertions(+)

diff --git a/include/configs/P1010RDB.h b/include/configs/P1010RDB.h
index a76630a..ec311fc 100644
--- a/include/configs/P1010RDB.h
+++ b/include/configs/P1010RDB.h
@@ -62,6 +62,7 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SPL_FLUSH_IMAGE
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h
index c8e7524..d4c17f9 100644
--- a/include/configs/P1022DS.h
+++ b/include/configs/P1022DS.h
@@ -51,6 +51,7 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SPL_FLUSH_IMAGE
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
diff --git a/include/configs/T102xQDS.h b/include/configs/T102xQDS.h
index 999fce2..569af49 100644
--- a/include/configs/T102xQDS.h
+++ b/include/configs/T102xQDS.h
@@ -81,6 +81,7 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0x200FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x0020)
diff --git a/include/configs/T102xRDB.h b/include/configs/T102xRDB.h
index 0ad1ce7..643eae0 100644
--- a/include/configs/T102xRDB.h
+++ b/include/configs/T102xRDB.h
@@ -88,6 +88,7 @@
 #define CONFIG_RESET_VECTOR_ADDRESS0x3FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x3000)
diff --git a/include/configs/T104xRDB.h b/include/configs/T104xRDB.h
index b81c194..4132814 100644
--- a/include/configs/T104xRDB.h
+++ b/include/configs/T104xRDB.h
@@ -74,6 +74,7 @@ $(SRCTREE)/board/freescale/t104xrdb/t1042d4_rcw.cfg
 #defineCONFIG_RESET_VECTOR_ADDRESS 0x3FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x3000)
diff --git a/include/configs/T208xQDS.h b/include/configs/T208xQDS.h
index 76a9f93..05c123c 100644
--- a/include/configs/T208xQDS.h
+++ b/include/configs/T208xQDS.h
@@ -91,6 +91,7 @@
 #defineCONFIG_RESET_VECTOR_ADDRESS 0x200FFC
 #define CONFIG_SPL_SPI_SUPPORT
 #define CONFIG_SPL_SPI_NOR_SUPPORT
+#define CONFIG_SPL_MTD_SUPPORT
 #define CONFIG_SPL_SPI_FLASH_MINIMAL
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_SIZE   (768 << 10)
 #define CONFIG_SYS_SPI_FLASH_U_BOOT_DST(0x0020)
diff --git a/inclu

Re: [U-Boot] [PATCH v6 00/76] mtd: Add SPI-NOR core support

2016-02-16 Thread Jagan Teki
On 15 February 2016 at 02:16, Jagan Teki  wrote:
> Compared to previous patch series this series adds spi-nor
> core with spi-nor controller drivers are of "mtd uclass"
>
> This is whole series for all spi-nor related changes, and while
> series tested on spansion spi-nor chip.
>
> Know issue:
> - arch/x86/lib/mrccache.c uses dm_spi_flash_ops, this need to fix.
>
> Why this framework:
>
> Some of the SPI device drivers at drivers/spi not a real
> spi controllers, Unlike normal/generic SPI controllers they
> operates only with SPI-NOR flash devices. these were technically
> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
>
> The problem with these were resides at drivers/spi is entire
> SPI layer becomes SPI-NOR flash oriented which is absolutely
> a wrong indication where SPI layer getting effected more with
> flash operations - So this SPI-NOR core will resolve this issue
> by separating all SPI-NOR flash operations from spi layer and
> creats a generic layer called SPI-NOR core which can be used to
> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> controller driver. The idea is taken from Linux spi-nor framework.
>
> Before SPI-NOR:
>
> ---
> cmd/sf.c
> ---
> spi_flash.c
> ---
> sf_probe.c
> ---
> spi-uclass
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> After SPI-NOR:
>
> --
> cmd/sf.c
> --
> spi-nor.c
> ---
> m25p80.cspi nor drivers
> ---
> spi-uclass  SPI NOR chip
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> SPI-NOR with MTD:
>
> --
> cmd/sf.c
> --
> MTD core
> --
> spi-nor.c
> ---
> m25p80.cspi nor drivers
> ---
> spi-uclass  SPI NOR chip
> ---
> spi drivers
> ---
> SPI NOR chip
> ---
>
> drivers/mtd/spi-nor/spi-nor.c: spi-nor core
> drivers/mtd/spi-nor/m25p80.c: mtd uclass driver
> which is an interface layer b/w spi-nor core drivers/spi
> drivers/mtd/spi-nor/fsl_qspi.c: spi-nor controller driver(mtd uclass)

Tested both DM and non-DM models

Tested-by: Jagan Teki 

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


  1   2   >