[U-Boot] [PATCH v4 6/9] rockchip: Enable networking support on rock2 and firefly

[Simon Glass]

From: Sjoerd Simons 

Enable the various configuration option required to get the ethernet
interface up and running on Radxa Rock2 and Firefly.

Signed-off-by: Sjoerd Simons 
Reviewed-by: Simon Glass 
Acked-by: Joe Hershberger 
Signed-off-by: Simon Glass 
---

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

 configs/firefly-rk3288_defconfig | 4 
 configs/rock2_defconfig  | 4 
 2 files changed, 8 insertions(+)

diff --git a/configs/firefly-rk3288_defconfig b/configs/firefly-rk3288_defconfig
index 4910c80..82787dc 100644
--- a/configs/firefly-rk3288_defconfig
+++ b/configs/firefly-rk3288_defconfig
@@ -44,6 +44,10 @@ CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_LED=y
 CONFIG_LED_GPIO=y
 CONFIG_ROCKCHIP_DWMMC=y
+CONFIG_DM_ETH=y
+CONFIG_NETDEVICES=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_RK3288=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 # CONFIG_SPL_PINCTRL_FULL is not set
diff --git a/configs/rock2_defconfig b/configs/rock2_defconfig
index 1883f07..f8436d6 100644
--- a/configs/rock2_defconfig
+++ b/configs/rock2_defconfig
@@ -43,6 +43,10 @@ CONFIG_SPL_CLK=y
 CONFIG_ROCKCHIP_GPIO=y
 CONFIG_SYS_I2C_ROCKCHIP=y
 CONFIG_ROCKCHIP_DWMMC=y
+CONFIG_DM_ETH=y
+CONFIG_NETDEVICES=y
+CONFIG_ETH_DESIGNWARE=y
+CONFIG_GMAC_RK3288=y
 CONFIG_PINCTRL=y
 CONFIG_SPL_PINCTRL=y
 # CONFIG_SPL_PINCTRL_FULL is not set
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 5/9] net: gmac_rk3288: Add RK3288 GMAC driver

[Simon Glass]

From: Sjoerd Simons 

Add a new driver for the GMAC ethernet interface present in Rockchip
RK3288 SOCs. This driver subclasses the generic design-ware driver to
add the glue needed specifically for Rockchip.

Signed-off-by: Sjoerd Simons 
Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger 
---

Changes in v4: None
Changes in v3:
- Add comments for struct gmac_rk3288_platdata
- Adjust binding to use r/tx-delay instead of r/tx_delay
- Sort includes
- Use debug() instead of printf() for error
- Use function calls instead of fix_mac_speed() hook
- Use new clk interface

Changes in v2:
- Adjust to new hook name
- Fix various coding style nits

 drivers/net/Kconfig   |   7 +++
 drivers/net/Makefile  |   1 +
 drivers/net/gmac_rk3288.c | 154 ++
 3 files changed, 162 insertions(+)
 create mode 100644 drivers/net/gmac_rk3288.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f25d3ff..0027a2e 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -215,4 +215,11 @@ config PIC32_ETH
  This driver implements 10/100 Mbps Ethernet and MAC layer for
  Microchip PIC32 microcontrollers.
 
+config GMAC_RK3288
+   bool "Rockchip RK3288 Synopsys Designware Ethernet MAC"
+   depends on DM_ETH && ETH_DESIGNWARE
+   help
+ This driver provides Rockchip RK3288 network support based on the
+ Synopsys Designware driver.
+
 endif # NETDEVICES
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 9a7bfc6..348e98b 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_FTGMAC100) += ftgmac100.o
 obj-$(CONFIG_FTMAC110) += ftmac110.o
 obj-$(CONFIG_FTMAC100) += ftmac100.o
 obj-$(CONFIG_GRETH) += greth.o
+obj-$(CONFIG_GMAC_RK3288) += gmac_rk3288.o
 obj-$(CONFIG_DRIVER_TI_KEYSTONE_NET) += keystone_net.o
 obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
 obj-$(CONFIG_LAN91C96) += lan91c96.o
diff --git a/drivers/net/gmac_rk3288.c b/drivers/net/gmac_rk3288.c
new file mode 100644
index 000..0c22756
--- /dev/null
+++ b/drivers/net/gmac_rk3288.c
@@ -0,0 +1,154 @@
+/*
+ * (C) Copyright 2015 Sjoerd Simons 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ *
+ * Rockchip GMAC ethernet IP driver for U-Boot
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "designware.h"
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/*
+ * Platform data for the gmac
+ *
+ * dw_eth_pdata: Required platform data for designware driver (must be first)
+ */
+struct gmac_rk3288_platdata {
+   struct dw_eth_pdata dw_eth_pdata;
+   int tx_delay;
+   int rx_delay;
+};
+
+static int gmac_rk3288_ofdata_to_platdata(struct udevice *dev)
+{
+   struct gmac_rk3288_platdata *pdata = dev_get_platdata(dev);
+
+   pdata->tx_delay = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"tx-delay", 0x30);
+   pdata->rx_delay = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"rx-delay", 0x10);
+
+   return designware_eth_ofdata_to_platdata(dev);
+}
+
+static int gmac_rk3288_fix_mac_speed(struct dw_eth_dev *priv)
+{
+   struct rk3288_grf *grf;
+   int clk;
+
+   switch (priv->phydev->speed) {
+   case 10:
+   clk = GMAC_CLK_SEL_2_5M;
+   break;
+   case 100:
+   clk = GMAC_CLK_SEL_25M;
+   break;
+   case 1000:
+   clk = GMAC_CLK_SEL_125M;
+   break;
+   default:
+   debug("Unknown phy speed: %d\n", priv->phydev->speed);
+   return -EINVAL;
+   }
+
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>soc_con1,
+GMAC_CLK_SEL_MASK << GMAC_CLK_SEL_SHIFT,
+clk << GMAC_CLK_SEL_SHIFT);
+
+   return 0;
+}
+
+static int gmac_rk3288_probe(struct udevice *dev)
+{
+   struct gmac_rk3288_platdata *pdata = dev_get_platdata(dev);
+   struct rk3288_grf *grf;
+   struct clk clk;
+   int ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret)
+   return ret;
+
+   /* Since mac_clk is fed by an external clock we can use 0 here */
+   ret = clk_set_rate(, 0);
+   if (ret)
+   return ret;
+
+   /* Set to RGMII mode */
+   grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   rk_clrsetreg(>soc_con1,
+RMII_MODE_MASK << RMII_MODE_SHIFT |
+GMAC_PHY_INTF_SEL_MASK << GMAC_PHY_INTF_SEL_SHIFT,
+GMAC_PHY_INTF_SEL_RGMII << GMAC_PHY_INTF_SEL_SHIFT);
+
+   rk_clrsetreg(>soc_con3,
+RXCLK_DLY_ENA_GMAC_MASK <<  RXCLK_DLY_ENA_GMAC_SHIFT |
+TXCLK_DLY_ENA_GMAC_MASK <<  TXCLK_DLY_ENA_GMAC_SHIFT |
+ 

[U-Boot] [PATCH v4 4/9] net: designware: Export the operation functions

[Simon Glass]

Export all functions so that drivers can use them, or not, as the need
arises.

Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger 
---

Changes in v4: None
Changes in v3:
- Add new patch to export the operation functions

Changes in v2: None

 drivers/net/designware.c | 19 +--
 drivers/net/designware.h |  9 +
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 0c596a7..f242fc6 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -271,7 +271,7 @@ static void _dw_eth_halt(struct dw_eth_dev *priv)
phy_shutdown(priv->phydev);
 }
 
-static int _dw_eth_init(struct dw_eth_dev *priv, u8 *enetaddr)
+int designware_eth_init(struct dw_eth_dev *priv, u8 *enetaddr)
 {
struct eth_mac_regs *mac_p = priv->mac_regs_p;
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -330,7 +330,7 @@ static int _dw_eth_init(struct dw_eth_dev *priv, u8 
*enetaddr)
return 0;
 }
 
-static int designware_eth_enable(struct dw_eth_dev *priv)
+int designware_eth_enable(struct dw_eth_dev *priv)
 {
struct eth_mac_regs *mac_p = priv->mac_regs_p;
 
@@ -493,7 +493,7 @@ static int dw_eth_init(struct eth_device *dev, bd_t *bis)
 {
int ret;
 
-   ret = _dw_eth_init(dev->priv, dev->enetaddr);
+   ret = designware_eth_init(dev->priv, dev->enetaddr);
if (!ret)
ret = designware_eth_enable(dev->priv);
 
@@ -591,7 +591,7 @@ static int designware_eth_start(struct udevice *dev)
struct dw_eth_dev *priv = dev_get_priv(dev);
int ret;
 
-   ret = _dw_eth_init(priv, pdata->enetaddr);
+   ret = designware_eth_init(priv, pdata->enetaddr);
if (ret)
return ret;
ret = designware_eth_enable(priv);
@@ -601,36 +601,35 @@ static int designware_eth_start(struct udevice *dev)
return 0;
 }
 
-static int designware_eth_send(struct udevice *dev, void *packet, int length)
+int designware_eth_send(struct udevice *dev, void *packet, int length)
 {
struct dw_eth_dev *priv = dev_get_priv(dev);
 
return _dw_eth_send(priv, packet, length);
 }
 
-static int designware_eth_recv(struct udevice *dev, int flags, uchar **packetp)
+int designware_eth_recv(struct udevice *dev, int flags, uchar **packetp)
 {
struct dw_eth_dev *priv = dev_get_priv(dev);
 
return _dw_eth_recv(priv, packetp);
 }
 
-static int designware_eth_free_pkt(struct udevice *dev, uchar *packet,
-  int length)
+int designware_eth_free_pkt(struct udevice *dev, uchar *packet, int length)
 {
struct dw_eth_dev *priv = dev_get_priv(dev);
 
return _dw_free_pkt(priv);
 }
 
-static void designware_eth_stop(struct udevice *dev)
+void designware_eth_stop(struct udevice *dev)
 {
struct dw_eth_dev *priv = dev_get_priv(dev);
 
return _dw_eth_halt(priv);
 }
 
-static int designware_eth_write_hwaddr(struct udevice *dev)
+int designware_eth_write_hwaddr(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct dw_eth_dev *priv = dev_get_priv(dev);
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index 087ebef..7992d0e 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -253,6 +253,15 @@ struct dw_eth_pdata {
struct eth_pdata eth_pdata;
u32 reset_delays[3];
 };
+
+int designware_eth_init(struct dw_eth_dev *priv, u8 *enetaddr);
+int designware_eth_enable(struct dw_eth_dev *priv);
+int designware_eth_send(struct udevice *dev, void *packet, int length);
+int designware_eth_recv(struct udevice *dev, int flags, uchar **packetp);
+int designware_eth_free_pkt(struct udevice *dev, uchar *packet,
+  int length);
+void designware_eth_stop(struct udevice *dev);
+int designware_eth_write_hwaddr(struct udevice *dev);
 #endif
 
 #endif
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 3/9] net: designware: Split the link init into a separate function

[Simon Glass]

With rockchip we need to make adjustments after the link speed is set but
before enabling received/transmit. In preparation for this, split these
two pieces into separate functions.

Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger 
---

Changes in v4: None
Changes in v3:
- Add new patch to split the link init into a separate function

Changes in v2: None

 drivers/net/designware.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index ebcef8b..0c596a7 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -327,6 +327,13 @@ static int _dw_eth_init(struct dw_eth_dev *priv, u8 
*enetaddr)
if (ret)
return ret;
 
+   return 0;
+}
+
+static int designware_eth_enable(struct dw_eth_dev *priv)
+{
+   struct eth_mac_regs *mac_p = priv->mac_regs_p;
+
if (!priv->phydev->link)
return -EIO;
 
@@ -484,7 +491,13 @@ static int dw_phy_init(struct dw_eth_dev *priv, void *dev)
 #ifndef CONFIG_DM_ETH
 static int dw_eth_init(struct eth_device *dev, bd_t *bis)
 {
-   return _dw_eth_init(dev->priv, dev->enetaddr);
+   int ret;
+
+   ret = _dw_eth_init(dev->priv, dev->enetaddr);
+   if (!ret)
+   ret = designware_eth_enable(dev->priv);
+
+   return ret;
 }
 
 static int dw_eth_send(struct eth_device *dev, void *packet, int length)
@@ -575,8 +588,17 @@ int designware_initialize(ulong base_addr, u32 interface)
 static int designware_eth_start(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
+   struct dw_eth_dev *priv = dev_get_priv(dev);
+   int ret;
 
-   return _dw_eth_init(dev->priv, pdata->enetaddr);
+   ret = _dw_eth_init(priv, pdata->enetaddr);
+   if (ret)
+   return ret;
+   ret = designware_eth_enable(priv);
+   if (ret)
+   return ret;
+
+   return 0;
 }
 
 static int designware_eth_send(struct udevice *dev, void *packet, int length)
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 0/9] rockchip: Add gmac Ethernet support

[Simon Glass]

>From Simon:
This v3 patch is an update on Sjoerd's original v2 series from Feburary.
I have dealt with the changes requested at the time, and adjusted the way
that the speed change is handled.

Tested on firefly-rk3288, rock2.

Original cover letter:
To add support I've taken a slightly different approach then some of the
other boards with a designware IP block, by creating a new driver to
take care of the platfrom glue which subclasses the main designware driver
instead of adding the compatibility string the designware driver
directly and doing the SoC specific setup in the board files. This seems
quite a bit more elegant in a device model based world.

I've only tested this series on a Radxa Rock 2 board, it would be great
if someone could test this on other boards with the designware IP
especially for those with the reset GPIO in devicetree (e.g. some of the
Allwinner boards).

Compared to the first one round the pinctrl related bits were dropped as
RK3288 now has a full pinctrl driver. Furthermore the started hook in the
designware driver was renamed to fix_mac_speed in line with what linux
uses and moved to the dw_link_adjust function.

Changes in v4:
- Fix commit message to say 'rk3399'

Changes in v3:
- Add a few new patches
- Add comments for struct gmac_rk3288_platdata
- Add new patch to adjust dw_adjust_link() to return an error
- Add new patch to enable networking on evb-rk3399
- Add new patch to export the operation functions
- Add new patch to split the link init into a separate function
- Adjust binding to use r/tx-delay instead of r/tx_delay
- Drop the 'net: designware: Add a fix_mac_speed hook' patch
- Sort includes
- Use debug() instead of printf() for error
- Use function calls instead of fix_mac_speed() hook
- Use new clk interface

Changes in v2:
- Adjust to new hook name
- Fix various coding style nits

Simon Glass (4):
  net: designware: Adjust dw_adjust_link() to return an error
  net: designware: Split the link init into a separate function
  net: designware: Export the operation functions
  rockchip: evb-rk3339: Enable DHCP

Sjoerd Simons (5):
  net: designware: Export various functions/struct to allow subclassing
  net: gmac_rk3288: Add RK3288 GMAC driver
  rockchip: Enable networking support on rock2 and firefly
  rockchip: Add PXE and DHCP to the default boot targets
  rockchip: Drop Ethernet from the TODO

 configs/evb-rk3399_defconfig  |   3 +
 configs/firefly-rk3288_defconfig  |   4 +
 configs/rock2_defconfig   |   4 +
 doc/README.rockchip   |   1 -
 drivers/net/Kconfig   |   7 ++
 drivers/net/Makefile  |   1 +
 drivers/net/designware.c  |  57 ++
 drivers/net/designware.h  |  13 
 drivers/net/gmac_rk3288.c | 154 ++
 include/configs/rockchip-common.h |   4 +-
 10 files changed, 230 insertions(+), 18 deletions(-)
 create mode 100644 drivers/net/gmac_rk3288.c

-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 2/9] net: designware: Adjust dw_adjust_link() to return an error

[Simon Glass]

This function can fail, so return the error if there is one.

Signed-off-by: Simon Glass 
Acked-by: Joe Hershberger 
---

Changes in v4: None
Changes in v3:
- Add new patch to adjust dw_adjust_link() to return an error

Changes in v2: None

 drivers/net/designware.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 6ef36bc..ebcef8b 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -230,14 +230,14 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, u8 
*mac_id)
return 0;
 }
 
-static void dw_adjust_link(struct eth_mac_regs *mac_p,
-  struct phy_device *phydev)
+static int dw_adjust_link(struct dw_eth_dev *priv, struct eth_mac_regs *mac_p,
+ struct phy_device *phydev)
 {
u32 conf = readl(_p->conf) | FRAMEBURSTENABLE | DISABLERXOWN;
 
if (!phydev->link) {
printf("%s: No link.\n", phydev->dev->name);
-   return;
+   return 0;
}
 
if (phydev->speed != 1000)
@@ -256,6 +256,8 @@ static void dw_adjust_link(struct eth_mac_regs *mac_p,
printf("Speed: %d, %s duplex%s\n", phydev->speed,
   (phydev->duplex) ? "full" : "half",
   (phydev->port == PORT_FIBRE) ? ", fiber mode" : "");
+
+   return 0;
 }
 
 static void _dw_eth_halt(struct dw_eth_dev *priv)
@@ -321,7 +323,9 @@ static int _dw_eth_init(struct dw_eth_dev *priv, u8 
*enetaddr)
return ret;
}
 
-   dw_adjust_link(mac_p, priv->phydev);
+   ret = dw_adjust_link(priv, mac_p, priv->phydev);
+   if (ret)
+   return ret;
 
if (!priv->phydev->link)
return -EIO;
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 1/9] net: designware: Export various functions/struct to allow subclassing

[Simon Glass]

From: Sjoerd Simons 

To allow other DM drivers to subclass the designware driver various
functions and structures need to be exported. Export these.

Signed-off-by: Sjoerd Simons 
Reviewed-by: Bin Meng 
Acked-by: Simon Glass 
Acked-by: Joe Hershberger 
Signed-off-by: Simon Glass 
---

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

 drivers/net/designware.c | 6 +++---
 drivers/net/designware.h | 4 
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 9e6d726..6ef36bc 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -628,7 +628,7 @@ static int designware_eth_bind(struct udevice *dev)
return 0;
 }
 
-static int designware_eth_probe(struct udevice *dev)
+int designware_eth_probe(struct udevice *dev)
 {
struct eth_pdata *pdata = dev_get_platdata(dev);
struct dw_eth_dev *priv = dev_get_priv(dev);
@@ -678,7 +678,7 @@ static int designware_eth_remove(struct udevice *dev)
return 0;
 }
 
-static const struct eth_ops designware_eth_ops = {
+const struct eth_ops designware_eth_ops = {
.start  = designware_eth_start,
.send   = designware_eth_send,
.recv   = designware_eth_recv,
@@ -687,7 +687,7 @@ static const struct eth_ops designware_eth_ops = {
.write_hwaddr   = designware_eth_write_hwaddr,
 };
 
-static int designware_eth_ofdata_to_platdata(struct udevice *dev)
+int designware_eth_ofdata_to_platdata(struct udevice *dev)
 {
struct dw_eth_pdata *dw_pdata = dev_get_platdata(dev);
 #ifdef CONFIG_DM_GPIO
diff --git a/drivers/net/designware.h b/drivers/net/designware.h
index d345c5b..087ebef 100644
--- a/drivers/net/designware.h
+++ b/drivers/net/designware.h
@@ -245,6 +245,10 @@ struct dw_eth_dev {
 };
 
 #ifdef CONFIG_DM_ETH
+int designware_eth_ofdata_to_platdata(struct udevice *dev);
+int designware_eth_probe(struct udevice *dev);
+extern const struct eth_ops designware_eth_ops;
+
 struct dw_eth_pdata {
struct eth_pdata eth_pdata;
u32 reset_delays[3];
-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] [PATCH v2 3/4] config: popmetal: enable the USB host controller and function

[Simon Glass]

On 24 November 2016 at 00:29, Kever Yang  wrote:
> RK3288 using the dwc2 USB host controller, enable it and other usb host
> funtion like storage and ether.
>
> Signed-off-by: Kever Yang 
> Acked-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  configs/popmetal-rk3288_defconfig | 3 +++
>  include/configs/rk3288_common.h   | 7 +++
>  2 files changed, 10 insertions(+)
>

Added 'rockchip' tag,

Applied to u-boot-rockchip, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] rockchip: configs: make rk3036 env config same as rk3288

[Simon Glass]

On 19 November 2016 at 06:48, Simon Glass  wrote:
> Hi Jacob,
>
> On 18 November 2016 at 00:52, Jacob Chen  wrote:
>> To make rockchip soc keep the same partition map
>>
>>
>> Signed-off-by: Jacob Chen 
>> ---
>>
>> Changes in v2:
>> - add a commit message
>>
>>  include/configs/kylin_rk3036.h | 17 ++---
>>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> Can this happen in the common file?
>
> Regards,
> Simon

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Peter Robinson]

>> >> I've been working with Soby Mathew to get U-Boot booting on ARM's
>> >> AEMv8 FVP model in Aarch32 mode.
>> >>
>> >> Soby worked out what needed to be changed and I'm refining the changes
>> >> into patches that can be built for both Aarch64 and Aarch32 mode.
>> >>
>> >> There are two patches for discussion:
>> >>
>> >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
>> >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
>> >>
>> >> I expect the first patch to be controversial.  I also don't expect it to
>> >> be accepted, but to demonstrate what changes we needed to make to get an
>> >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
>> >> ARM64 as the CPU type.  This in itself may be the wrong approach.
>> >>
>> >> It adds an ARMV8_AARCH32 config option and some checks in generic code
>> >> for that option to allow the code to differentiate between the two
>> >> modes.
>> >>
>> >> The second patch should be less controversial.  It adds support for a
>> >> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
>> >> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
>> >> change based on feedback from patch 1/2.
>> >>
>> >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
>> >> takes an extra per-core model launch parameter to switch the cores into
>> >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
>> >
>> > So my first and slightly ignorant question is, why isn't this just a new
>> > regular ARMv7 board being added rather than a special cased ARMv8?
>> >
>>
>> That's a valid question.
>>
>> I guess it could be either.  At the moment, it's a bit of both.
>> arch/arm/Kconfig says it's an ARMv7, but then it's added to
>> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
>>
>> But there's no reason it couldn't be added to
>> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
>> isn't special cased at all.  That approach seems more copy/paste-y
>> than what I've done in this series, though.
>>
>> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
>> confused.  Really, all of these armlt boards are the same with minor
>> variations, even if the minor variation could be ARMv7 vs ARMv8.
>
> Maybe this gets to the heart of the problem then, and we should
> re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
> support rpi1 2 and 3, and that includes rpi3 in 64bit mode.  So if we
> want to re-work board/armlt/vexpress/ to support the various ways the
> base hardware can be (/ has been over the years), lets.  Does that sound
> like a plan?

That sounds great to me, I would like to be able to use the vexpress
u-boot through qemu but be able to pass through the qemu generated DT
so as to get the HW passed through correctly. I'm interested as it
makes for a nice means of automation for some of my testing but also
for virt based build systems too.

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

Re: [U-Boot] [PATCH v2 1/3] rockchip: configs: correct env offset when enable CONFIG_ROCKCHIP_SPL_BACK_TO_BROM

[Simon Glass]

On 19 November 2016 at 06:48, Simon Glass  wrote:
> Hi Jacob,
>
> On 18 November 2016 at 00:52, Jacob Chen  wrote:
>> With CONFIG_ROCKCHIP_SPL_BACK_TO_BROM enabled,
>> the environment is inside u-boot.
>> So solve it by moving environment after u-boot.
>
> Can this not happen in the rk3288_common.h file?
>
>>
>> Signed-off-by: Jacob Chen 
>> ---
>>
>> Changes in v2:
>> - add a commit message
>>
>>  include/configs/evb_rk3288.h  | 9 +
>>  include/configs/fennec_rk3288.h   | 9 +
>>  include/configs/miniarm_rk3288.h  | 9 +
>>  include/configs/popmetal_rk3288.h | 9 +
>>  4 files changed, 36 insertions(+)
>>
>
> Regards,
> Simon

Applied to u-boot-rockchip, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/4] board: popmetal: de-assert the host rst pin in board init

[Simon Glass]

On 29 November 2016 at 17:34, Simon Glass  wrote:
> On 29 November 2016 at 01:49, Kever Yang  wrote:
>> Hi Simon,
>>
>>
>> On 11/26/2016 03:39 AM, Simon Glass wrote:
>>>
>>> Hi Kever,
>>>
>>> On 24 November 2016 at 00:29, Kever Yang 
>>> wrote:

 The PopMetal board have a on board FE1.1 usb 2.0 hub which connect to
 the usb host port, we need to de-assert its reset pin to enable it.

 Signed-off-by: Kever Yang 
 ---

 Changes in v2:
 - move the vbus power enable into dwc2 driver

   board/chipspark/popmetal_rk3288/popmetal-rk3288.c | 17
 +
   1 file changed, 17 insertions(+)

 diff --git a/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
 b/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
 index aad74ef..ed82b2b 100644
 --- a/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
 +++ b/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
 @@ -6,6 +6,7 @@

   #include 
   #include 
 +#include 

   void board_boot_order(u32 *spl_boot_list)
   {
 @@ -13,3 +14,19 @@ void board_boot_order(u32 *spl_boot_list)
  spl_boot_list[0] = BOOT_DEVICE_MMC2;
  spl_boot_list[1] = BOOT_DEVICE_MMC1;
   }
 +
 +#define GPIO7A3_HUB_RST227
 +
 +int rk_board_late_init(void)
 +{
 +   int ret;
 +
 +   ret = gpio_request(GPIO7A3_HUB_RST, "hub_rst");
 +   if (ret)
 +   return ret;
 +   ret = gpio_direction_output(GPIO7A3_HUB_RST, 1);
 +   if (ret)
>>>
>>> Can we get this from the device tree instead of hard-coding it? Then
>>> it can go in generic code.
>>
>>
>> I don't understand how to get this from device tree, this board is the
>> only one based on rk3288 with a USB hub on board and need the de-assert
>> its reset pin. I think it is reasonable to hard coding it in its board file.
>
> OK, since it's just one board.
>
> Acked-by: Simon Glass 
>
> In general we can support this sort of thing by adding a driver for
> UCLASS_USB_HUB, but I suspect it would need refactoring of
> common/usb.c.

Added 'rockchip' tag,

Applied to u-boot-rockchip, thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 7/9] rockchip: evb-rk3339: Enable DHCP

[Simon Glass]

This is the only RK3399 device without DHCP. Enable it so that we
can use a common BOOT_TARGET_DEVICES setting. It is likely useful to be
able to use USB networking, at least. Full networking can be enabled when
a suitable platform needs it.

Signed-off-by: Simon Glass 
---

Changes in v4:
- Fix commit message to say 'rk3399'

Changes in v3:
- Add new patch to enable networking on evb-rk3399

Changes in v2: None

 configs/evb-rk3399_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 40a8295..be522fb 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -11,6 +11,9 @@ CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
 CONFIG_CMD_TIME=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_EXT4=y
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 9/9] rockchip: Drop Ethernet from the TODO

[Simon Glass]

From: Sjoerd Simons 

Now that ethernet support works, it can be dropped from the rockchip
TODO

Signed-off-by: Sjoerd Simons 
Acked-by: Simon Glass 
Acked-by: Joe Hershberger 
Signed-off-by: Simon Glass 
---

Changes in v4: None
Changes in v3:
- Add a few new patches
- Drop the 'net: designware: Add a fix_mac_speed hook' patch

Changes in v2: None

 doc/README.rockchip | 1 -
 1 file changed, 1 deletion(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index 06ec80e..43cafc7 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -219,7 +219,6 @@ Immediate priorities are:
 - USB host
 - USB device
 - Run CPU at full speed (code exists but we only see ~60 DMIPS maximum)
-- Ethernet
 - NAND flash
 - Support for other Rockchip parts
 - Boot U-Boot proper over USB OTG (at present only SPL works)
-- 
2.8.0.rc3.226.g39d4020

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

[U-Boot] [PATCH v4 8/9] rockchip: Add PXE and DHCP to the default boot targets

[Simon Glass]

From: Sjoerd Simons 

Now that at least on the firefly board we have network support, enable
PXE and DHCP boot targets by default.

Signed-off-by: Sjoerd Simons 
Acked-by: Simon Glass 
Acked-by: Joe Hershberger 
Signed-off-by: Simon Glass 
---

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

 include/configs/rockchip-common.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/configs/rockchip-common.h 
b/include/configs/rockchip-common.h
index 9ec71c4..be53e65 100644
--- a/include/configs/rockchip-common.h
+++ b/include/configs/rockchip-common.h
@@ -14,7 +14,9 @@
 /* First try to boot from SD (index 0), then eMMC (index 1 */
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
-   func(MMC, mmc, 1)
+   func(MMC, mmc, 1) \
+   func(PXE, pxe, na) \
+   func(DHCP, dchp, na)
 
  /* Enable gpt partition table */
 #define CONFIG_CMD_GPT
-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] [PATCH v2] disk: convert to Kconfig

[Tom Rini]

On Fri, Dec 02, 2016 at 09:24:54AM +0100, Patrick Delaunay wrote:

> This converts the following to Kconfig:
>CONFIG_PARTITIONS
>CONFIG_MAC_PARTITION
>CONFIG_DOS_PARTITION
>CONFIG_ISO_PARTITION
>CONFIG_AMIGA_PARTITION
>CONFIG_EFI_PARTITION
>CONFIG_PARTITION_UUIDS
>CONFIG_PARTITION_TYPE_GUID
[snip]
>  606 files changed, 996 insertions(+), 583 deletions(-)

The insertions to deletions ratio is still high, and I think we can do a
little better.  Some of this is due to platforms that I fix with
https://patchwork.ozlabs.org/patch/700546/ and will have the various
types selected now.  But I think we can still do a little better with
defaults too:

[snip]
> +config ISO_PARTITION
> + bool "Enable ISO partition table"
> + depends on PARTITIONS

This should be default y for x86, along with DOS and MAC.

> +config SPL_ISO_PARTITION
> + bool "Enable ISO partition table for SPL"
> + depends on SPL && PARTITIONS

Here and elsewhere, SPL_xxx_PARTITION should be default y if
xxx_PARTITION

> +config PARTITION_UUIDS
> + bool "Enable support of UUID for partition"
> + help
> +   Activate the configuration of UUID for partition

I think a lot of these will go away once CMD_GPT and CMD_PART are
converted to Kconfig, but I don't want to chicken-and-egg this nor have
too many things in flight at once, so lets put that off until after this
series.  Thanks!

-- 
Tom


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

[U-Boot] [GIT PULL] Xilinx and SCSI changes

[Michal Simek]

Hi Tom,

here are some patches I have collected for Xilinx devices, one miiphy
patch and SCSI changes I have made.

Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
should go through your tree because you have applied
"dm: blk: Fix get_desc to return block device descriptor"
which is required. They are based on this branch.

Tom: I have tested also travis with zynq qemu but it looks like a
problem with qemu timing for zynq model. The rest of python tests look
good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
Anyway I will talk to Qemu guys what I can do with it and when this
timing issue was solved and which mainline qemu version this requires.
Is there arm64 qemu available too?

Thanks,
Michal


 The following changes since commit
9ae0e14350758e6447c90615ff4df530549a45e2:

   Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)

 are available in the git repository at:


   git://www.denx.de/git/u-boot-microblaze.git master

 for you to fetch changes up to 861fe6503e205622202a61d3ca86cd4ccb80bf03:

   cmd: scsi: Make private functions static (2016-12-02 14:37:32 +0100)

 
 Masahiro Yamada (1):
   ARM: zynq(mp): remove unneeded CONFIG_USB_MAX_CONTROLLER_COUNT
defines

 Michal Simek (14):
   ARM64: zynqmp: Force certain bootmode for SPL
   ARM64: zynqmp: Use DTS name for different psu_init_gpl* files in SPL
   ARM64: zynqmp: List secondary software boot modes
   common: miiphyutil: Work and report phy address in hex in mdio cmd
   scsi: Extract block device initialization
   scsi: Extract device detection algorithm
   scsi: Take lun from device block description
   scsi: Move pccb buffer initalization directly to scsi_detect_dev
   scsi: Simplify scsi_read/scsi_write()
   scsi: Remove completely unused functions
   scsi: Make private functions static
   scsi: Change scsi_scan() to be able to return value
   scsi: Separate SCSI private block description initialization
   cmd: scsi: Make private functions static

 Siva Durga Prasad Paladugu (1):
   ARM: zynq: Enable SD1 and qspi for picozed board

  arch/arm/cpu/armv8/zynqmp/Kconfig   |  10 +-
  arch/arm/cpu/armv8/zynqmp/spl.c |   4 +
  arch/arm/dts/zynq-picozed.dts   |  12 +++
  arch/arm/include/asm/arch-zynqmp/hardware.h |   3 +
  board/xilinx/zynqmp/Makefile|   2 +-
  cmd/mdio.c  |   6 +-
  cmd/scsi.c  |  18 ++--
  common/miiphyutil.c |   2 +-
  common/scsi.c   | 288
+---
  drivers/net/zynq_gem.c  |   2 +-
  include/configs/xilinx_zynqmp.h |   1 -
  include/configs/zynq-common.h   |   1 -
  include/scsi.h  |   5 +-
  13 files changed, 194 insertions(+), 160 deletions(-)

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

Re: [U-Boot] [PATCH v3 09/11] spi: cadence_qspi: Move DT prop code to match layout

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Move the code to read the "sram-size" property into the other code
> that reads properties from the node, rather than the SF subnode.
>
> Signed-off-by: Phil Edworthy 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 03/11] spi: cadence_qspi: Better debug information on the SPI clock rate

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Show what the output clock rate actually is.
>
> Signed-off-by: Phil Edworthy 
> Acked-by: Marek Vasut 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] mmc: spear: remove the entire spear_sdhci.c file

[Tom Rini]

On Fri, Dec 02, 2016 at 05:46:10PM +0900, Jaehoon Chung wrote:

> Remove the entire spear_sdhci.c file.
> There is no use case. This is dead codes.
> Also there is no place to call "spear_sdhci_init()" anywhere.
> 
> If some people use this file, let me know, plz.
> 
> Signed-off-by: Jaehoon Chung 

It looks like it was added as dead code so:

Reviewed-by: Tom Rini 

-- 
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 v3 02/11] spi: cadence_qspi: Fix baud rate calculation

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> With the existing code, when the requested SPI clock rate is near
> to the lowest that can be achieved by the hardware (max divider
> of the ref clock is 32), the generated clock rate is wrong.
> For example, with a 50MHz ref clock, when asked for anything less
> than a 1.5MHz SPI clock, the code sets up the divider to generate
> 25MHz.
>
> This change fixes the calculation.
>
> Signed-off-by: Phil Edworthy 

Perhaps you missed, Marek Acked-by tag on previous version, don't
worry will add while applying if any.

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 04/11] spi: cadence_qspi: Use #define for bits instead of bit shifts

[Jagan Teki]

On Wed, Nov 30, 2016 at 1:02 PM, Phil Edworthy
 wrote:
> Hi Jagan,
>
> On 30 November 2016 04:59, Jagan Teki wrote:
>> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
>>  wrote:
>> > Most of the code already uses #defines for the bit value, rather
>> > than the shift required to get the value. This changes the remaining
>> > code over.
>> >
>> > Whislt at it, fix the names of the "Rd Data Capture" register defs.
>> >
>> > Signed-off-by: Phil Edworthy 
>> > Acked-by: Marek Vasut 



>>
>> I've commented about this change [1]?
>>
>> [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg232120.html
> Yes, I fixed that in a separate patch, see
> https://www.mail-archive.com/u-boot@lists.denx.de/msg232489.html
>
> I did it in a separate patch because this patch is purely about replacing the
> definitions of bit shifts with BIT(x).

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs

[Ryan Harkin]

This patch hacks some generic code used to allow the ARMv8 platform to
specify if it is booting in Aarch32 mode.

Some ARMv8 CPUs can be run in Aarch32 mode as well as Aarch64.  A good
example of this is ARM's AEMv8 FVP model which models the ARMv8
architecture rather than a specific CPU core.

This patch is co-authored with Soby Mathew .

Signed-off-by: Ryan Harkin 
---
 Makefile  | 5 +
 arch/arm/Kconfig  | 6 ++
 arch/arm/cpu/armv7/virt-v7.c  | 2 ++
 arch/arm/cpu/armv8/u-boot-spl.lds | 5 +
 arch/arm/cpu/armv8/u-boot.lds | 5 +
 arch/arm/include/asm/armv8/mmu.h  | 5 +
 6 files changed, 28 insertions(+)

diff --git a/Makefile b/Makefile
index 37cbcb2..b923ef7 100644
--- a/Makefile
+++ b/Makefile
@@ -1182,8 +1182,13 @@ u-boot-img-spl-at-end.bin: u-boot.img spl/u-boot-spl.bin 
FORCE
 # relocation).
 # FIXME refactor dts/Makefile to share target/arch detection
 u-boot.elf: u-boot.bin
+ifeq ($(CONFIG_ARMV8_AARCH32),y)
+   @$(OBJCOPY)  -B arm -I binary -O elf32-littlearm \
+   $< u-boot-elf.o
+else
@$(OBJCOPY)  -B aarch64 -I binary -O elf64-littleaarch64 \
$< u-boot-elf.o
+endif
@$(LD) u-boot-elf.o -o $@ \
--defsym=_start=$(CONFIG_SYS_TEXT_BASE) \
-Ttext=$(CONFIG_SYS_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..6475a21 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -44,6 +44,12 @@ config CPU_ARM1176
select HAS_VBAR
select SYS_CACHE_SHIFT_5
 
+
+config ARMV8_AARCH32
+   bool "some help"
+   help
+ some better help
+
 config CPU_V7
bool
select HAS_VBAR
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index d33e5c6..b0f54e3 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -131,12 +131,14 @@ int armv7_init_nonsec(void)
 * ram, so need to relocate secure section before enabling other
 * cores.
 */
+#ifndef CONFIG_ARMV8_AARCH32
relocate_secure_section();
 
 #ifndef CONFIG_ARMV7_PSCI
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
smp_kick_all_cpus();
 #endif
+#endif
 
/* call the non-sec switching code on this CPU also */
secure_ram_addr(_nonsec_init)();
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index cc427c3..bddfbe6 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -17,8 +17,13 @@ MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
 MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
"elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fd15ad5..0543458 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,8 +8,13 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
"elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index aa0f3c4..755c517 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -77,8 +77,13 @@
 #define PTE_BLOCK_INNER_SHARE  (3 << 8)
 #define PTE_BLOCK_AF   (1 << 10)
 #define PTE_BLOCK_NG   (1 << 11)
+#ifdef CONFIG_ARMV8_AARCH32
+#define PTE_BLOCK_PXN  ((1ULL) << 53)
+#define PTE_BLOCK_UXN  ((1ULL) << 54)
+#else
 #define PTE_BLOCK_PXN  (UL(1) << 53)
 #define PTE_BLOCK_UXN  (UL(1) << 54)
+#endif
 
 /*
  * AttrIndx[2:0]
-- 
1.9.1

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

[U-Boot] [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant

[Ryan Harkin]

The ARM AEMv8 FVP model can be run in Aarch64 or Aarch32 mode. Aarch32
support is enable per-CPU when launching the model, eg:

-C cluster0.cpu0.CONFIG64=0

This patch adds a new defconfig and some variant specific selections in
vexpress_armv8a.h.

This patch is co-authored with Soby Mathew .

Signed-off-by: Ryan Harkin 
---
 arch/arm/Kconfig  | 10 ++
 board/armltd/vexpress64/Kconfig   |  2 +-
 configs/vexpress_aemv8a_aarch32_defconfig | 30 ++
 include/configs/vexpress_aemv8a.h | 28 ++--
 4 files changed, 67 insertions(+), 3 deletions(-)
 create mode 100644 configs/vexpress_aemv8a_aarch32_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6475a21..59e22aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -647,6 +647,16 @@ config TARGET_VEXPRESS64_BASE_FVP
select ARM64
select SEMIHOSTING
 
+config TARGET_VEXPRESS_AEMV8_AARCH32
+   bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting 
from DRAM"
+   select CPU_V7
+   select ARMV8_AARCH32
+   help
+ This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides
+ the default config to allow the user to load the images directly into
+ DRAM using model parameters rather than by using semi-hosting to load
+ the files from the host filesystem.
+
 config TARGET_VEXPRESS64_BASE_FVP_DRAM
bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM"
select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index e05f353..06c1ce1 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM
+if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM || TARGET_VEXPRESS_AEMV8_AARCH32
 
 config SYS_BOARD
default "vexpress64"
diff --git a/configs/vexpress_aemv8a_aarch32_defconfig 
b/configs/vexpress_aemv8a_aarch32_defconfig
new file mode 100644
index 000..109bae5
--- /dev/null
+++ b/configs/vexpress_aemv8a_aarch32_defconfig
@@ -0,0 +1,30 @@
+CONFIG_ARM=y
+CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_IDENT_STRING=" vexpress_aemv8a"
+CONFIG_BOOTDELAY=1
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="VExpress32# "
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_ARMFLASH=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+# CONFIG_CMD_MISC is not set
+CONFIG_CMD_FAT=y
+CONFIG_DM=y
+CONFIG_DM_SERIAL=y
+CONFIG_OF_LIBFDT=y
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index c9841cd..5cab39a 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -16,12 +16,17 @@
 #endif
 
 #define CONFIG_REMAKE_ELF
-
 #define CONFIG_SUPPORT_RAW_INITRD
+#ifdef CONFIG_ARMV8_AARCH32
+#define CONFIG_SYS_HZ_CLOCK2400
+#define CONFIG_SYS_ARCH_TIMER
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#endif
 
 /* Link Definitions */
 #if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \
-   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM)
+   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM) || \
+   defined(CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32)
 /* ATF loads u-boot here for BASE_FVP model */
 #define CONFIG_SYS_TEXT_BASE   0x8800
 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0)
@@ -259,6 +264,25 @@
 #define CONFIG_BOOTCOMMAND "booti $kernel_addr $initrd_addr $fdt_addr"
 
 
+#elif CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "kernel_addr=0x8008\0"  \
+   "initrd_addr=0x8400\0"  \
+   "fdt_addr=0x8200\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0"
+
+#define CONFIG_BOOTARGS"console=ttyAMA0 earlycon=pl011,"\
+   "0x1c09 debug user_debug=31 "\
+   "systemd.log_target=null "\
+   "androidboot.hardware=fvpbase "\
+   "root=/dev/vda2 rw "\
+   "rootwait "\
+   "loglevel=9"
+
+#define CONFIG_BOOTCOMMAND "bootm $kernel_addr $initrd_addr $fdt_addr"
+
+
 #endif
 
 /* Monitor 

[U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

I've been working with Soby Mathew to get U-Boot booting on ARM's
AEMv8 FVP model in Aarch32 mode.

Soby worked out what needed to be changed and I'm refining the changes
into patches that can be built for both Aarch64 and Aarch32 mode.

There are two patches for discussion:

[RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
[RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant

I expect the first patch to be controversial.  I also don't expect it to 
be accepted, but to demonstrate what changes we needed to make to get an 
ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
ARM64 as the CPU type.  This in itself may be the wrong approach.

It adds an ARMV8_AARCH32 config option and some checks in generic code 
for that option to allow the code to differentiate between the two
modes.

The second patch should be less controversial.  It adds support for a
new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
that it defines itself not as ARM64, but as CPU_V7.  I expect this to
change based on feedback from patch 1/2.

The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but 
takes an extra per-core model launch parameter to switch the cores into
Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/7] video: Kconfig: Add VIDEO_IPV3 entry

[Jagan Teki]

Hi Stefano,

On Tue, Nov 29, 2016 at 11:22 PM, Stefano Babic  wrote:
> Hi Jagan,
>
> On 28/10/2016 15:57, Jagan Teki wrote:
>> From: Jagan Teki 
>>
>> Added kconfig entry for CONFIG_VIDEO_IPV3 driver.
>>
>> Cc: Anatolij Gustschin 
>> Cc: Stefano Babic 
>> Cc: Matteo Lisi 
>> Cc: Michael Trimarchi 
>> Signed-off-by: Jagan Teki 
>> ---
>>  drivers/video/Kconfig | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>> index 577e6d7..134f1c8 100644
>> --- a/drivers/video/Kconfig
>> +++ b/drivers/video/Kconfig
>> @@ -443,6 +443,14 @@ config VIDEO
>> model. Video drivers typically provide a colour text console and
>> cursor.
>>
>> +config VIDEO_IPUV3
>> + bool "i.MX IPUv3 Core video support"
>> + depends on MX6
>> + default y if VIDEO
>> + help
>> +   This enables framebuffer driver for i.MX processors working
>> +   on the IPUv3(Image Processing Unit) internal graphic processor.
>> +
>>  config CFB_CONSOLE
>>   bool "Enable colour frame buffer console"
>>   depends on VIDEO
>>
>
> I have difficulties with your patches. They have updated and moved
> configuration to Kconfig, but they do not care of the existing boards.
>
> This series breaks a lot of boards except yours - I cannot merge it.
>
> The same thing happens to the series I have already merged (but not
> pushed to the server) with "Use CONFIG_DM_ETH support". I have merged it
> and pushed to u-boot-imx, -next, so you can easier see what happens.
> Both series break existing board and I cannot take them, and even if
> they are improving i.MX code with new features.
>
> Can you take a look at fix them in the order:
>
> - first the FEC series ==> see -next branch

Found the issue and made a changes according to previous version
patches which eventually works on all targets.

> - then the IPU (this series).

Fixed and will send the

And also I've one more series with engicam boards [1], shall I send
all these 3 series into one on top of u-boot-imx/master?

[1] [PATCH v3 00/11] imx6: Add Engicam GEAM6UL/i.CoreM6 RQS board support

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 06/11] spi: cadence_qspi: Use spi mode at the point it is needed

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Instead of extracting mode settings and passing them as separate
> args to another function, just pass the SPI mode as an arg.
>
> Signed-off-by: Phil Edworthy 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Tom Rini]

On Fri, Dec 02, 2016 at 09:54:39AM +0200, Jyri Sarha wrote:

> Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
> and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
> the default values LCDC suffers from DMA FIFO underflows and frame
> synchronization lost errors. The initialization values are the highest
> that work flawlessly when heavy memory load is generated by CPU. 32bpp
> colors were used in the test. On BBB the video mode used 110MHz pixel
> clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
> clock.
> 
> Signed-off-by: Jyri Sarha 
[snip]
> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> index 43e122e..c71cfd0 100644
> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> @@ -25,6 +25,14 @@
>  #endif
>  #define PHY_EN_DYN_PWRDN (0x1 << 20)
>  
> +/**
> + * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
> + * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
> + * Synchronization Lost errors.
> + */
> +#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK 0x00141414
> +#define EMIF_OCP_CONFIG_AM335X_EVM   0x003d3d3d

OK, but the problems I see are that first we don't explain what these
values are tied to physically.  Is it the display? The DDR memory?
Second, since these are board specific they should be in
board/ti/am335x/board.h.  Thanks!

-- 
Tom


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

[U-Boot] [PATCH v3 1/4] mmc: sdhci: Distinguish between base clock and maximum peripheral frequency

[stefan.herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The sdhci controller assumes that the base clock frequency is fully supported by
the peripheral and doesn't support hardware limitations. The Linux kernel
distinguishes between base clock (max_clk) of the host controller and maximum
frequency (f_max) of the card interface. Use the same differentiation and allow
the platform to constrain the peripheral interface.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v3:
- Rename arguments of sdhci_setup_cfg function from max_clk/min_clk to 
f_max/f_min

Changes in v2: None

 drivers/mmc/atmel_sdhci.c|  7 +--
 drivers/mmc/bcm2835_sdhci.c  |  3 ++-
 drivers/mmc/ftsdc021_sdhci.c |  3 ++-
 drivers/mmc/kona_sdhci.c |  3 ++-
 drivers/mmc/msm_sdhci.c  |  2 ++
 drivers/mmc/mv_sdhci.c   |  3 ++-
 drivers/mmc/pci_mmc.c|  1 +
 drivers/mmc/pic32_sdhci.c|  4 +++-
 drivers/mmc/rockchip_sdhci.c |  4 ++--
 drivers/mmc/s5p_sdhci.c  |  5 +++--
 drivers/mmc/sdhci.c  | 34 ++
 drivers/mmc/spear_sdhci.c|  3 ++-
 drivers/mmc/zynq_sdhci.c |  4 +++-
 include/sdhci.h  | 13 +++--
 14 files changed, 54 insertions(+), 35 deletions(-)

diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 6654b54..62cb242 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -35,8 +35,9 @@ int atmel_sdhci_init(void *regbase, u32 id)
free(host);
return -ENODEV;
}
+   host->max_clk = max_clk;
 
-   add_sdhci(host, max_clk, min_clk);
+   add_sdhci(host, 0, min_clk);
 
return 0;
 }
@@ -95,7 +96,9 @@ static int atmel_sdhci_probe(struct udevice *dev)
if (!max_clk)
return -EINVAL;
 
-   ret = sdhci_setup_cfg(>cfg, host, max_clk, ATMEL_SDHC_MIN_FREQ);
+   host->max_clk = max_clk;
+
+   ret = sdhci_setup_cfg(>cfg, host, 0, ATMEL_SDHC_MIN_FREQ);
if (ret)
return ret;
 
diff --git a/drivers/mmc/bcm2835_sdhci.c b/drivers/mmc/bcm2835_sdhci.c
index cb2bd40..29c2a85 100644
--- a/drivers/mmc/bcm2835_sdhci.c
+++ b/drivers/mmc/bcm2835_sdhci.c
@@ -181,10 +181,11 @@ int bcm2835_sdhci_init(u32 regbase, u32 emmc_freq)
host->ioaddr = (void *)(unsigned long)regbase;
host->quirks = SDHCI_QUIRK_BROKEN_VOLTAGE | SDHCI_QUIRK_BROKEN_R1B |
SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_NO_HISPD_BIT;
+   host->max_clk = emmc_freq;
host->voltages = MMC_VDD_32_33 | MMC_VDD_33_34 | MMC_VDD_165_195;
host->ops = _ops;
 
-   add_sdhci(host, emmc_freq, MIN_FREQ);
+   add_sdhci(host, 0, MIN_FREQ);
 
return 0;
 }
diff --git a/drivers/mmc/ftsdc021_sdhci.c b/drivers/mmc/ftsdc021_sdhci.c
index 6e9fefa..4940ccb 100644
--- a/drivers/mmc/ftsdc021_sdhci.c
+++ b/drivers/mmc/ftsdc021_sdhci.c
@@ -27,7 +27,8 @@ int ftsdc021_sdhci_init(u32 regbase)
host->name = "FTSDC021";
host->ioaddr = (void __iomem *)regbase;
host->quirks = 0;
-   add_sdhci(host, freq, 0);
+   host->max_clk = freq;
+   add_sdhci(host, 0, 0);
 
return 0;
 }
diff --git a/drivers/mmc/kona_sdhci.c b/drivers/mmc/kona_sdhci.c
index 549f6bc..ddd821b 100644
--- a/drivers/mmc/kona_sdhci.c
+++ b/drivers/mmc/kona_sdhci.c
@@ -121,12 +121,13 @@ int kona_sdhci_init(int dev_index, u32 min_clk, u32 
quirks)
host->name = "kona-sdhci";
host->ioaddr = reg_base;
host->quirks = quirks;
+   host->max_clk = max_clk;
 
if (init_kona_mmc_core(host)) {
free(host);
return -EINVAL;
}
 
-   add_sdhci(host, max_clk, min_clk);
+   add_sdhci(host, 0, min_clk);
return ret;
 }
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index f33714b..1db683d 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -96,6 +96,8 @@ static int msm_sdc_probe(struct udevice *dev)
 
host->quirks = SDHCI_QUIRK_WAIT_SEND_CMD | SDHCI_QUIRK_BROKEN_R1B;
 
+   host->max_clk = 0;
+
/* Init clocks */
ret = msm_sdc_clk_init(dev);
if (ret)
diff --git a/drivers/mmc/mv_sdhci.c b/drivers/mmc/mv_sdhci.c
index e388ad1..69aa87b 100644
--- a/drivers/mmc/mv_sdhci.c
+++ b/drivers/mmc/mv_sdhci.c
@@ -77,6 +77,7 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 
min_clk, u32 quirks)
host->name = MVSDH_NAME;
host->ioaddr = (void *)regbase;
host->quirks = quirks;
+   host->max_clk = max_clk;
 #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
memset(_ops, 0, sizeof(struct sdhci_ops));
mv_ops.write_b = mv_sdhci_writeb;
@@ -88,5 +89,5 @@ int mv_sdh_init(unsigned long regbase, u32 max_clk, u32 
min_clk, u32 quirks)
sdhci_mvebu_mbus_config((void __iomem *)regbase);
}
 
-   return add_sdhci(host, max_clk, min_clk);
+   return add_sdhci(host, 0, min_clk);
 }
diff --git 

[U-Boot] [PATCH v3 2/4] serial: zynq: Remove unused index from get uart clock function

[stefan.herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The index of the zynq serial driver is always zero and could be removed.

Signed-off-by: Stefan Herbrechtsmeier 
Acked-by: Michal Simek 

---

Changes in v3: None
Changes in v2:
- Remove unused index from get uart clock function

 arch/arm/mach-zynq/clk.c  | 3 +--
 arch/arm/mach-zynq/include/mach/clk.h | 2 +-
 drivers/serial/serial_zynq.c  | 2 +-
 3 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-zynq/clk.c b/arch/arm/mach-zynq/clk.c
index 40383c1..e256b58 100644
--- a/arch/arm/mach-zynq/clk.c
+++ b/arch/arm/mach-zynq/clk.c
@@ -551,13 +551,12 @@ void zynq_clk_early_init(void)
 
 /**
  * get_uart_clk() - Get UART input frequency
- * @dev_index: UART ID
  * Returns UART input clock frequency in Hz.
  *
  * Compared to zynq_clk_get_rate() this function is designed to work before
  * relocation and can be called when the serial UART is set up.
  */
-unsigned long get_uart_clk(int dev_index)
+unsigned long get_uart_clk(void)
 {
u32 reg = readl(_base->uart_clk_ctrl);
u32 div = (reg & CLK_CTRL_DIV0_MASK) >> CLK_CTRL_DIV0_SHIFT;
diff --git a/arch/arm/mach-zynq/include/mach/clk.h 
b/arch/arm/mach-zynq/include/mach/clk.h
index 250c5bc..ba2210d 100644
--- a/arch/arm/mach-zynq/include/mach/clk.h
+++ b/arch/arm/mach-zynq/include/mach/clk.h
@@ -24,6 +24,6 @@ void zynq_clk_early_init(void);
 int zynq_clk_set_rate(enum zynq_clk clk, unsigned long rate);
 unsigned long zynq_clk_get_rate(enum zynq_clk clk);
 const char *zynq_clk_get_name(enum zynq_clk clk);
-unsigned long get_uart_clk(int dev_id);
+unsigned long get_uart_clk(void);
 
 #endif
diff --git a/drivers/serial/serial_zynq.c b/drivers/serial/serial_zynq.c
index 4f6e7e4..461ba86 100644
--- a/drivers/serial/serial_zynq.c
+++ b/drivers/serial/serial_zynq.c
@@ -134,7 +134,7 @@ int zynq_serial_setbrg(struct udevice *dev, int baudrate)
return ret;
}
 #else
-   clock = get_uart_clk(0);
+   clock = get_uart_clk();
 #endif
_uart_zynq_serial_setbrg(priv->regs, clock, baudrate);
 
-- 
2.7.4



Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 - 
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH - 
Sitz: Detmold - Amtsgericht Lemgo HRB 3924; 
Geschäftsführer: José Carlos Álvarez Tobar, Elke Eckstein, Dr. Peter Köhler, 
Jörg Timmermann;
USt-ID-Nr. DE124599660
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 0/4] mmc: sdhci: Add support for frequency constrained peripheral interfaces

[stefan.herbrechtsmeier]

From: Stefan Herbrechtsmeier 


The sdhci controller assumes that the base clock frequency is fully
supported by the peripheral and doesn't support hardware limitations.
Distinguish between base clock of the host controller and maximal
supported peripheral clock frequency of the peripheral interface.
This is needed for the zynq platform to support two sdhci ports with
different IO routings.

Changes in v3:
- Rename arguments of sdhci_setup_cfg function from max_clk/min_clk to 
f_max/f_min

Changes in v2:
- Remove unused index from get uart clock function
- Remove unused index from get sdio clock function
- Introduce common get clock function

Stefan Herbrechtsmeier (4):
  mmc: sdhci: Distinguish between base clock and maximum peripheral
frequency
  serial: zynq: Remove unused index from get uart clock function
  mmc: zynq: Determine base clock frequency via clock framework
  mmc: zynq: Add fdt max-frequency support

 arch/arm/mach-zynq/clk.c  | 51 +++
 arch/arm/mach-zynq/include/mach/clk.h |  3 ++-
 drivers/mmc/atmel_sdhci.c |  7 +++--
 drivers/mmc/bcm2835_sdhci.c   |  3 ++-
 drivers/mmc/ftsdc021_sdhci.c  |  3 ++-
 drivers/mmc/kona_sdhci.c  |  3 ++-
 drivers/mmc/msm_sdhci.c   |  2 ++
 drivers/mmc/mv_sdhci.c|  3 ++-
 drivers/mmc/pci_mmc.c |  1 +
 drivers/mmc/pic32_sdhci.c |  4 ++-
 drivers/mmc/rockchip_sdhci.c  |  4 +--
 drivers/mmc/s5p_sdhci.c   |  5 ++--
 drivers/mmc/sdhci.c   | 34 ---
 drivers/mmc/spear_sdhci.c |  3 ++-
 drivers/mmc/zynq_sdhci.c  | 40 ++-
 drivers/serial/serial_zynq.c  |  2 +-
 include/sdhci.h   | 13 -
 17 files changed, 133 insertions(+), 48 deletions(-)

-- 
2.7.4



Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 - 
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH - 
Sitz: Detmold - Amtsgericht Lemgo HRB 3924; 
Geschäftsführer: José Carlos Álvarez Tobar, Elke Eckstein, Dr. Peter Köhler, 
Jörg Timmermann;
USt-ID-Nr. DE124599660
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 05/11] spi: cadence_qspi: Clean up the #define names

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> A lot of the #defines are for single bits in a register, where the
> name has _MASK on the end. Since this can be used for both a mask
> and the value, remove _MASK from them.
>
> Whilst doing so, also remove the unnecessary brackets around the
> constants.
>
> Signed-off-by: Phil Edworthy 
> Acked-by: Marek Vasut 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [GIT PULL] Xilinx and SCSI changes

[Tom Rini]

On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:

> Hi Tom,
> 
> here are some patches I have collected for Xilinx devices, one miiphy
> patch and SCSI changes I have made.
> 
> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
> should go through your tree because you have applied
> "dm: blk: Fix get_desc to return block device descriptor"
> which is required. They are based on this branch.
> 
> Tom: I have tested also travis with zynq qemu but it looks like a
> problem with qemu timing for zynq model. The rest of python tests look
> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
> Anyway I will talk to Qemu guys what I can do with it and when this
> timing issue was solved and which mainline qemu version this requires.
> Is there arm64 qemu available too?

We have to disable the 'sleep' test on a number of other platforms, you
just need to add TEST_PY_TEST_SPEC="not sleep"

For the zynq model, can we not use the -dtb argument to qemu?  Or, how
does the device tree get passed along on the real platform?

And, the PPA we currently use only has qemu-2.5 available but I get
tempted to either do a PPA myself or just throw things up on dropbox of
a more current release of QEMU, especially if it enabled more platforms
for us to test.

-- 
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] net: zynq_gem: Return 0 on success, not -ENOSYS

[Olliver Schinagl]

Hey Joe,


On 01-12-16 00:38, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:41 AM, Olliver Schinagl  wrote:

The .read_rom_hwaddr net_ops hook does not check the return value, which
is why it was never caught that we are currently returning 0 if the
read_rom_hwaddr function return -ENOSYS and -ENOSYS otherwise.

In this case we can simplify this by just returning the result of the
function.

Signed-off-by: Olliver Schinagl 
---
  drivers/net/zynq_gem.c | 8 +++-
  1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
index 8b7c1be..04a3fd4 100644
--- a/drivers/net/zynq_gem.c
+++ b/drivers/net/zynq_gem.c
@@ -593,14 +593,12 @@ __weak int zynq_board_read_rom_ethaddr(unsigned char 
*ethaddr)

  static int zynq_gem_read_rom_mac(struct udevice *dev)
  {
-   int retval;
 struct eth_pdata *pdata = dev_get_platdata(dev);

-   retval = zynq_board_read_rom_ethaddr(pdata->enetaddr);
-   if (retval == -ENOSYS)
-   retval = 0;
+   if (!dev)
+   return -ENOSYS;

-   return retval;
+   return zynq_board_read_rom_ethaddr(pdata->enetaddr);

You should check the pdata ptr for NULL before dereferencing.
Actually, is this not violating the whole point subclassed drivers? (I 
admit I have not checked into more details of the zynq_gem to see if it 
is not allready a subclassed driver).


Even so, I can send an updated patch for this to fix this issue separate 
of the rest so atleast this function behaves properly.



  }

  static int zynq_gem_miiphy_read(struct mii_dev *bus, int addr,
--
2.10.2

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


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

[U-Boot] [PATCH v3 4/4] mmc: zynq: Add fdt max-frequency support

[stefan.herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The maximum supported peripheral clock frequency of the zynq depends on
the IO routing. The MIO and EMIO support a maximum frequency of 50 MHz
respectively 25 MHz. Use the max-frequency value of the device tree to
determine the maximal supported peripheral clock frequency.

Signed-off-by: Stefan Herbrechtsmeier 
Acked-by: Michal Simek 

---

Changes in v3: None
Changes in v2: None

 drivers/mmc/zynq_sdhci.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 26bd1be..4d2f0b5 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -16,6 +16,8 @@
 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
 #ifndef CONFIG_ZYNQ_SDHCI_MIN_FREQ
 # define CONFIG_ZYNQ_SDHCI_MIN_FREQ0
 #endif
@@ -23,6 +25,7 @@
 struct arasan_sdhci_plat {
struct mmc_config cfg;
struct mmc mmc;
+   unsigned int f_max;
 };
 
 static int arasan_sdhci_probe(struct udevice *dev)
@@ -67,7 +70,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
 
host->max_clk = clock;
 
-   ret = sdhci_setup_cfg(>cfg, host, CONFIG_ZYNQ_SDHCI_MAX_FREQ,
+   ret = sdhci_setup_cfg(>cfg, host, plat->f_max,
  CONFIG_ZYNQ_SDHCI_MIN_FREQ);
host->mmc = >mmc;
if (ret)
@@ -81,11 +84,15 @@ static int arasan_sdhci_probe(struct udevice *dev)
 
 static int arasan_sdhci_ofdata_to_platdata(struct udevice *dev)
 {
+   struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
struct sdhci_host *host = dev_get_priv(dev);
 
host->name = dev->name;
host->ioaddr = (void *)dev_get_addr(dev);
 
+   plat->f_max = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+   "max-frequency", CONFIG_ZYNQ_SDHCI_MAX_FREQ);
+
return 0;
 }
 
-- 
2.7.4



Kommanditgesellschaft - Sitz: Detmold - Amtsgericht Lemgo HRA 2790 - 
Komplementärin: Weidmüller Interface Führungsgesellschaft mbH - 
Sitz: Detmold - Amtsgericht Lemgo HRB 3924; 
Geschäftsführer: José Carlos Álvarez Tobar, Elke Eckstein, Dr. Peter Köhler, 
Jörg Timmermann;
USt-ID-Nr. DE124599660
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3 3/4] mmc: zynq: Determine base clock frequency via clock framework

[stefan.herbrechtsmeier]

From: Stefan Herbrechtsmeier 

The zynq_sdhci controller driver use CONFIG_ZYNQ_SDHCI_MAX_FREQ as base
clock frequency but this clock is not fixed and depends on the hardware
configuration. Additionally the value of CONFIG_ZYNQ_SDHCI_MAX_FREQ
doesn't match the real base clock frequency of SDIO_FREQ. Use the clock
framework to determine the frequency at run time.

Signed-off-by: Stefan Herbrechtsmeier 

---

Changes in v3: None
Changes in v2:
- Remove unused index from get sdio clock function
- Introduce common get clock function

 arch/arm/mach-zynq/clk.c  | 50 ---
 arch/arm/mach-zynq/include/mach/clk.h |  1 +
 drivers/mmc/zynq_sdhci.c  | 33 +--
 3 files changed, 72 insertions(+), 12 deletions(-)

diff --git a/arch/arm/mach-zynq/clk.c b/arch/arm/mach-zynq/clk.c
index e256b58..8df2de2 100644
--- a/arch/arm/mach-zynq/clk.c
+++ b/arch/arm/mach-zynq/clk.c
@@ -550,20 +550,26 @@ void zynq_clk_early_init(void)
 }
 
 /**
- * get_uart_clk() - Get UART input frequency
- * Returns UART input clock frequency in Hz.
+ * zynq_clk_get_early() - Get zynq clock frequency early
+ * Returns clock frequency in Hz.
  *
  * Compared to zynq_clk_get_rate() this function is designed to work before
- * relocation and can be called when the serial UART is set up.
+ * relocation and can be called when the peripheral is set up.
  */
-unsigned long get_uart_clk(void)
+unsigned long zynq_clk_get_early(u32 *addr)
 {
-   u32 reg = readl(_base->uart_clk_ctrl);
-   u32 div = (reg & CLK_CTRL_DIV0_MASK) >> CLK_CTRL_DIV0_SHIFT;
-   u32 srcsel = (reg & CLK_CTRL_SRCSEL_MASK) >> CLK_CTRL_SRCSEL_SHIFT;
-   enum zynq_clk parent = __zynq_clk_periph_get_parent(srcsel);
-   u32 *pllreg = clkid_2_register(parent);
-   unsigned long prate = __zynq_clk_pll_get_rate(pllreg);
+   u32 reg, div, srcsel;
+   enum zynq_clk parent;
+   u32 *pllreg;
+   unsigned long prate;
+
+   reg = readl(addr);
+   div = (reg & CLK_CTRL_DIV0_MASK) >> CLK_CTRL_DIV0_SHIFT;
+   srcsel = (reg & CLK_CTRL_SRCSEL_MASK) >> CLK_CTRL_SRCSEL_SHIFT;
+
+   parent = __zynq_clk_periph_get_parent(srcsel);
+   pllreg = clkid_2_register(parent);
+   prate = __zynq_clk_pll_get_rate(pllreg);
 
if (!div)
div = 1;
@@ -572,6 +578,30 @@ unsigned long get_uart_clk(void)
 }
 
 /**
+ * get_uart_clk() - Get UART input frequency
+ * Returns UART input clock frequency in Hz.
+ *
+ * Compared to zynq_clk_get_rate() this function is designed to work before
+ * relocation and can be called when the serial UART is set up.
+ */
+unsigned long get_uart_clk(void)
+{
+   return zynq_clk_get_early(_base->uart_clk_ctrl);
+}
+
+/**
+ * get_sdio_clk() - Get SDIO input frequency
+ * Returns SDIO input clock frequency in Hz.
+ *
+ * Compared to zynq_clk_get_rate() this function is designed to work before
+ * relocation and can be called when the SDIO is set up.
+ */
+unsigned long get_sdio_clk(void)
+{
+   return zynq_clk_get_early(_base->sdio_clk_ctrl);
+}
+
+/**
  * set_cpu_clk_info() - Initialize clock framework
  * Always returns zero.
  *
diff --git a/arch/arm/mach-zynq/include/mach/clk.h 
b/arch/arm/mach-zynq/include/mach/clk.h
index ba2210d..bed4903 100644
--- a/arch/arm/mach-zynq/include/mach/clk.h
+++ b/arch/arm/mach-zynq/include/mach/clk.h
@@ -25,5 +25,6 @@ int zynq_clk_set_rate(enum zynq_clk clk, unsigned long rate);
 unsigned long zynq_clk_get_rate(enum zynq_clk clk);
 const char *zynq_clk_get_name(enum zynq_clk clk);
 unsigned long get_uart_clk(void);
+unsigned long get_sdio_clk(void);
 
 #endif
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 69efa38..26bd1be 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -6,6 +6,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -13,6 +14,8 @@
 #include 
 #include 
 
+#include 
+
 #ifndef CONFIG_ZYNQ_SDHCI_MIN_FREQ
 # define CONFIG_ZYNQ_SDHCI_MIN_FREQ0
 #endif
@@ -27,8 +30,34 @@ static int arasan_sdhci_probe(struct udevice *dev)
struct arasan_sdhci_plat *plat = dev_get_platdata(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
struct sdhci_host *host = dev_get_priv(dev);
+   unsigned long clock;
int ret;
 
+#if defined(CONFIG_CLK) || defined(CONFIG_SPL_CLK)
+   struct clk clk;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0) {
+   dev_err(dev, "failed to get clock\n");
+   return ret;
+   }
+
+   clock = clk_get_rate();
+   if (IS_ERR_VALUE(clock)) {
+   dev_err(dev, "failed to get rate\n");
+   return clock;
+   }
+   debug("%s: CLK %ld\n", __func__, clock);
+
+   ret = clk_enable();
+   if (ret && ret != -ENOSYS) {
+   dev_err(dev, "failed to enable clock\n");
+   

[U-Boot] [PATCH v4 1/2] dm: Add support for scsi/sata based devices

[Michal Simek]

All sata based drivers are bind and corresponding block
device is created. Based on this find_scsi_device() is able
to get back block device based on scsi_curr_dev pointer.

intr_scsi() is commented now but it can be replaced by calling
find_scsi_device() and scsi_scan().

scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
is reassigned to a block description allocated by uclass.
There is only one block description by device now but it doesn't need to
be correct when more devices are present.

scsi_bind() ensures corresponding block device creation.
uclass post_probe (scsi_post_probe()) is doing low level init.

SCSI/SATA DM based drivers requires to have 64bit base address as
the first entry in platform data structure to setup mmio_base.

Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

Changes in v4:
- Fix Kconfig entry
- Remove SPL ifdef around SCSI uclass
- Clean ahci_print_info() ifdef logic

Changes in v3:
- Fix scsi_scan return path
- Fix header location uclass-internal.h
- Add scsi_max_devs under !DM_SCSI
- Add new header device-internal because of device_probe()
- Redesign block device creation algorithm
- Use device_unbind in error path
- Create block device with id and lun numbers (lun was there in v2)
- Cleanup dev_num initialization in block device description
  with fixing parameters in blk_create_devicef
- Create new Kconfig menu for SATA/SCSI drivers
- Extend description for DM_SCSI
- Fix Kconfig dependencies
- Fix kernel doc format in scsi_platdata
- Fix ahci_init_one - vendor variable

Changes in v2:
- Use CONFIG_DM_SCSI instead of mix of DM_SCSI and DM_SATA
  Ceva sata has never used sata commands that's why keep it in
  SCSI part only.
- Separate scsi_scan() for DM_SCSI and do not change cmd/scsi.c
- Extend platdata

 common/board_r.c|  4 +--
 common/scsi.c   | 76 +
 drivers/block/Kconfig   | 13 
 drivers/block/Makefile  |  1 +
 drivers/block/ahci.c| 30 +-
 drivers/block/blk-uclass.c  |  2 +-
 drivers/block/scsi-uclass.c | 27 
 include/ahci.h  |  2 +-
 include/dm/uclass-id.h  |  1 +
 include/sata.h  |  2 ++
 include/scsi.h  | 20 +++-
 11 files changed, 165 insertions(+), 13 deletions(-)
 create mode 100644 drivers/block/scsi-uclass.c

diff --git a/common/board_r.c b/common/board_r.c
index 5496f45cbd94..a3733526c699 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -620,7 +620,7 @@ static int initr_ambapp_print(void)
 }
 #endif
 
-#if defined(CONFIG_SCSI)
+#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SCSI)
 static int initr_scsi(void)
 {
puts("SCSI:  ");
@@ -923,7 +923,7 @@ init_fnc_t init_sequence_r[] = {
initr_ambapp_print,
 #endif
 #endif
-#ifdef CONFIG_SCSI
+#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SCSI)
INIT_FUNC_WATCHDOG_RESET
initr_scsi,
 #endif
diff --git a/common/scsi.c b/common/scsi.c
index 04add624958f..e7efa5ae797c 100644
--- a/common/scsi.c
+++ b/common/scsi.c
@@ -10,7 +10,10 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
+#if !defined(CONFIG_DM_SCSI)
 #ifdef CONFIG_SCSI_DEV_LIST
 #define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
 #else
@@ -31,6 +34,7 @@
 #endif
 #define SCSI_DEV_LIST {SCSI_VEND_ID, SCSI_DEV_ID}
 #endif
+#endif
 
 #if defined(CONFIG_PCI) && !defined(CONFIG_SCSI_AHCI_PLAT)
 const struct pci_device_id scsi_device_list[] = { SCSI_DEV_LIST };
@@ -39,11 +43,13 @@ static ccb tempccb; /* temporary scsi command buffer */
 
 static unsigned char tempbuff[512]; /* temporary data buffer */
 
+#if !defined(CONFIG_DM_SCSI)
 static int scsi_max_devs; /* number of highest available scsi device */
 
 static int scsi_curr_dev; /* current device */
 
 static struct blk_desc scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
+#endif
 
 /* almost the maximum amount of the scsi_ext command.. */
 #define SCSI_MAX_READ_BLK 0x
@@ -444,6 +450,7 @@ static void scsi_init_dev_desc_priv(struct blk_desc 
*dev_desc)
 #endif
 }
 
+#if !defined(CONFIG_DM_SCSI)
 /**
  * scsi_init_dev_desc - initialize all SCSI specific blk_desc properties
  *
@@ -460,6 +467,7 @@ static void scsi_init_dev_desc(struct blk_desc *dev_desc, 
int devnum)
 
scsi_init_dev_desc_priv(dev_desc);
 }
+#endif
 
 /**
  * scsi_detect_dev - Detect scsi device
@@ -540,6 +548,73 @@ removable:
  * (re)-scan the scsi bus and reports scsi device info
  * to the user if mode = 1
  */
+#if defined(CONFIG_DM_SCSI)
+int scsi_scan(int mode)
+{
+   unsigned char i, lun;
+   struct uclass *uc;
+   struct udevice *dev; /* SCSI controller */
+   int ret;
+
+   if (mode == 1)
+   printf("scanning bus for devices...\n");
+
+   ret = uclass_get(UCLASS_SCSI, );
+   if (ret)
+   return ret;
+
+   uclass_foreach_dev(dev, 

[U-Boot] [PATCH v4 2/2] block: Move ceva driver to DM

[Michal Simek]

This patch also includes ARM64 zynqmp changes:
- Remove platform non DM initialization
- Remove hardcoded sata base address

Signed-off-by: Michal Simek 
Reviewed-by: Simon Glass 
---

Changes in v4: None
Changes in v3:
- Extend Kconfig help description
- sort dm.h
- Remove SPL undefinition from board file
- Fix Kconfig dependecies

Changes in v2:
- make ceva_init_sata static
- Move SATA_CEVA to defconfig
- Initalized max_lun and max_id platdata

 arch/arm/include/asm/arch-zynqmp/hardware.h |  2 --
 board/xilinx/zynqmp/zynqmp.c| 11 
 configs/xilinx_zynqmp_ep_defconfig  |  2 ++
 configs/xilinx_zynqmp_zcu102_defconfig  |  2 ++
 configs/xilinx_zynqmp_zcu102_revB_defconfig |  2 ++
 drivers/block/Kconfig   |  9 +++
 drivers/block/sata_ceva.c   | 41 +++--
 include/configs/xilinx_zynqmp.h |  1 -
 include/configs/xilinx_zynqmp_ep.h  |  1 -
 include/configs/xilinx_zynqmp_zcu102.h  |  2 --
 10 files changed, 54 insertions(+), 19 deletions(-)

diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h 
b/arch/arm/include/asm/arch-zynqmp/hardware.h
index 5908c50d0946..041b43cfe044 100644
--- a/arch/arm/include/asm/arch-zynqmp/hardware.h
+++ b/arch/arm/include/asm/arch-zynqmp/hardware.h
@@ -18,8 +18,6 @@
 
 #define ARASAN_NAND_BASEADDR   0xFF10
 
-#define ZYNQMP_SATA_BASEADDR   0xFD0C
-
 #define ZYNQMP_USB0_XHCI_BASEADDR  0xFE20
 #define ZYNQMP_USB1_XHCI_BASEADDR  0xFE30
 
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index cef1f6a13aee..a23c38acd99d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -311,17 +311,6 @@ void reset_cpu(ulong addr)
 {
 }
 
-#ifdef CONFIG_SCSI_AHCI_PLAT
-void scsi_init(void)
-{
-#if defined(CONFIG_SATA_CEVA)
-   init_sata(0);
-#endif
-   ahci_init((void __iomem *)ZYNQMP_SATA_BASEADDR);
-   scsi_scan(1);
-}
-#endif
-
 int board_late_init(void)
 {
u32 reg = 0;
diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index f3cdf90c1f73..8d6a6cf5701e 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -49,6 +49,8 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_DM_SCSI=y
+CONFIG_SATA_CEVA=y
 CONFIG_DFU_RAM=y
 CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_ZYNQMPPL=y
diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
b/configs/xilinx_zynqmp_zcu102_defconfig
index fa6d6692040e..7e5e83fdc043 100644
--- a/configs/xilinx_zynqmp_zcu102_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_defconfig
@@ -41,6 +41,8 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_DM_SCSI=y
+CONFIG_SATA_CEVA=y
 CONFIG_DFU_RAM=y
 CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_ZYNQMPPL=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index a4af8024e454..f57705b2cba9 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -41,6 +41,8 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_DM_SCSI=y
+CONFIG_SATA_CEVA=y
 CONFIG_DFU_RAM=y
 CONFIG_FPGA_XILINX=y
 CONFIG_FPGA_ZYNQMPPL=y
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 7b82ba67eadb..88e66e2377a9 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -39,4 +39,13 @@ config BLOCK_CACHE
 
 menu "SATA/SCSI device support"
 
+config SATA_CEVA
+   bool "Ceva Sata controller"
+   depends on AHCI
+   depends on DM_SCSI
+   help
+ This option enables Ceva Sata controller hard IP available on Xilinx
+ ZynqMP. Support up to 2 external devices. Complient with SATA 3.1 and
+ AHCI 1.3 specifications with hot-plug detect feature.
+
 endmenu
diff --git a/drivers/block/sata_ceva.c b/drivers/block/sata_ceva.c
index dcc3b90b17f1..9b5466483aa4 100644
--- a/drivers/block/sata_ceva.c
+++ b/drivers/block/sata_ceva.c
@@ -5,6 +5,7 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -73,10 +74,9 @@
 #define DRV_NAME   "ahci-ceva"
 #define CEVA_FLAG_BROKEN_GEN2  1
 
-int init_sata(int dev)
+static int ceva_init_sata(ulong mmio)
 {
ulong tmp;
-   ulong mmio = ZYNQMP_SATA_BASEADDR;
int i;
 
/*
@@ -111,3 +111,40 @@ int init_sata(int dev)
}
return 0;
 }
+
+static int sata_ceva_probe(struct udevice *dev)
+{
+   struct scsi_platdata *plat = dev_get_platdata(dev);
+
+   ceva_init_sata(plat->base);
+   return 0;
+}
+
+static const struct udevice_id sata_ceva_ids[] = {
+   { .compatible = "ceva,ahci-1v84" },
+   { }
+};
+
+static int sata_ceva_ofdata_to_platdata(struct udevice *dev)
+{
+   struct scsi_platdata *plat = dev_get_platdata(dev);
+
+   

Re: [U-Boot] [PATCH v3 01/11] spi: cadence_qspi: Fix clearing of pol/pha bits

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Or'ing together bit positions is clearly wrong.
>
> Signed-off-by: Phil Edworthy 
> Acked-by: Marek Vasut 


Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 07/11] spi: cadence_qspi: Remove returns from end of void functions

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Signed-off-by: Phil Edworthy 
> Acked-by: Marek Vasut 

Reviewed-by: Jagan Teki 

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 10/11] spi: cadence_qspi: Change readdata_capture() arg to bool

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> This is in preparation for adding another arg.

?? proper reason for changing arg to bool.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, 1/9] ARM: dts: am57xx: sync DT with latest Linux

[Tom Rini]

On Fri, Nov 25, 2016 at 11:14:18AM +0530, Lokesh Vutla wrote:

> Sync all am57xx based dts files with latest Linux
> 
> Signed-off-by: Lokesh Vutla 
> Reviewed-by: Tom Rini 

This breaks building of am57xx_evm for me:
https://travis-ci.org/trini/u-boot/jobs/180810977

-- 
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] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Tom Rini]

On Fri, Dec 02, 2016 at 09:40:28PM +, Ryan Harkin wrote:
> On 2 Dec 2016 19:20, "Tom Rini"  wrote:
> >
> > On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote:
> > > On 2 December 2016 at 15:41, Tom Rini  wrote:
> > > > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:
> > > >
> > > >> I've been working with Soby Mathew to get U-Boot booting on ARM's
> > > >> AEMv8 FVP model in Aarch32 mode.
> > > >>
> > > >> Soby worked out what needed to be changed and I'm refining the
> changes
> > > >> into patches that can be built for both Aarch64 and Aarch32 mode.
> > > >>
> > > >> There are two patches for discussion:
> > > >>
> > > >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
> > > >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
> > > >>
> > > >> I expect the first patch to be controversial.  I also don't expect
> it to
> > > >> be accepted, but to demonstrate what changes we needed to make to
> get an
> > > >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead
> of
> > > >> ARM64 as the CPU type.  This in itself may be the wrong approach.
> > > >>
> > > >> It adds an ARMV8_AARCH32 config option and some checks in generic
> code
> > > >> for that option to allow the code to differentiate between the two
> > > >> modes.
> > > >>
> > > >> The second patch should be less controversial.  It adds support for a
> > > >> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
> > > >> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
> > > >> change based on feedback from patch 1/2.
> > > >>
> > > >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code,
> but
> > > >> takes an extra per-core model launch parameter to switch the cores
> into
> > > >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
> > > >
> > > > So my first and slightly ignorant question is, why isn't this just a
> new
> > > > regular ARMv7 board being added rather than a special cased ARMv8?
> > > >
> > >
> > > That's a valid question.
> > >
> > > I guess it could be either.  At the moment, it's a bit of both.
> > > arch/arm/Kconfig says it's an ARMv7, but then it's added to
> > > board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
> > >
> > > But there's no reason it couldn't be added to
> > > board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
> > > isn't special cased at all.  That approach seems more copy/paste-y
> > > than what I've done in this series, though.
> > >
> > > I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
> > > confused.  Really, all of these armlt boards are the same with minor
> > > variations, even if the minor variation could be ARMv7 vs ARMv8.
> >
> > Maybe this gets to the heart of the problem then, and we should
> > re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
> > support rpi1 2 and 3, and that includes rpi3 in 64bit mode.  So if we
> > want to re-work board/armlt/vexpress/ to support the various ways the
> > base hardware can be (/ has been over the years), lets.  Does that sound
> > like a plan?
> >
> 
> Thanks, yes, it sounds like a great idea.  I haven't looked at the rpi
> stuff yes, but I'll check it out next week.
> 
> I believe that would only resolve the issues in my 2nd patch, though.
> Wouldn't the generic part of using an ARMv8 CPU with the ARMv7 code still
> need addressing?  I guess reviewing the rpi3 code will tell me more.

I think everything you need is in there somewhere as there's also a
rpi3-as-32bit option.

-- 
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 16/17] arm: mvebu: Add gdsys ControlCenter-Compact board

[Mario Six]

Hi Stefan,

On Thu, Dec 1, 2016 at 10:57 AM, Stefan Roese  wrote:
> On 23.11.2016 16:12, Mario Six wrote:
>> From: Dirk Eibach 
>>
>> The gdsys ControlCenter Digital board is based on a Marvell Armada 38x
>> SOC.
>>
>> It boots from SPI-Flash but can be configured to boot from SD-card for
>> factory programming and testing.
>>
>> On board peripherals include:
>> - 2 x GbE
>> - Xilinx Kintex-7 FPGA connected via PCIe
>> - mSATA
>> - USB3 host
>> - Atmel TPM
>>
>> Signed-off-by: Dirk Eibach 
>> Signed-off-by: Mario Six 
>> ---
>>  arch/arm/Kconfig  |   1 +
>>  arch/arm/dts/Makefile |   3 +-
>>  arch/arm/dts/controlcenterdc.dts  | 629 +
>
> Could you perhaps rename this file (and board name as well?) to
> something like "armada-38x-controlcenterdc*" instead? Its much easier
> to match the files to the architecture this way. And until now, all
> Armada XP / 38x (etc) files match this rule.
>

Sure, I'll rename that file in v2.

>>  arch/arm/mach-mvebu/Kconfig   |   4 +
>>  board/gdsys/38x/.gitignore|   1 +
>
> Perhaps better s/38x/a38x for "Armada"?
>

OK, will be fixed in v2.

>>  board/gdsys/38x/Kconfig   |  42 +++
>>  board/gdsys/38x/MAINTAINERS   |   7 +
>>  board/gdsys/38x/Makefile  |  30 ++
>>  board/gdsys/38x/README|  18 +
>>  board/gdsys/38x/controlcenterdc.c | 717 
>> ++
>>  board/gdsys/38x/dt_helpers.c  |  60 
>>  board/gdsys/38x/dt_helpers.h  |  16 +
>>  board/gdsys/38x/hre.c | 517 +++
>>  board/gdsys/38x/hre.h |  38 ++
>>  board/gdsys/38x/keyprogram.c  | 158 +
>>  board/gdsys/38x/keyprogram.h  |  14 +
>>  board/gdsys/38x/kwbimage.cfg.in   |  12 +
>>  board/gdsys/38x/spl.c |  21 ++
>>  configs/controlcenterdc_defconfig |  54 +++
>>  include/configs/controlcenterdc.h | 244 +
>>  20 files changed, 2585 insertions(+), 1 deletion(-)
>>  create mode 100644 arch/arm/dts/controlcenterdc.dts
>>  create mode 100644 board/gdsys/38x/.gitignore
>>  create mode 100644 board/gdsys/38x/Kconfig
>>  create mode 100644 board/gdsys/38x/MAINTAINERS
>>  create mode 100644 board/gdsys/38x/Makefile
>>  create mode 100644 board/gdsys/38x/README
>>  create mode 100644 board/gdsys/38x/controlcenterdc.c
>>  create mode 100644 board/gdsys/38x/dt_helpers.c
>>  create mode 100644 board/gdsys/38x/dt_helpers.h
>>  create mode 100644 board/gdsys/38x/hre.c
>>  create mode 100644 board/gdsys/38x/hre.h
>>  create mode 100644 board/gdsys/38x/keyprogram.c
>>  create mode 100644 board/gdsys/38x/keyprogram.h
>>  create mode 100644 board/gdsys/38x/kwbimage.cfg.in
>>  create mode 100644 board/gdsys/38x/spl.c
>>  create mode 100644 configs/controlcenterdc_defconfig
>>  create mode 100644 include/configs/controlcenterdc.h
>>
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index acd689b..f4c236b 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -970,6 +970,7 @@ source "board/freescale/mx53loco/Kconfig"
>>  source "board/freescale/mx53smd/Kconfig"
>>  source "board/freescale/s32v234evb/Kconfig"
>>  source "board/freescale/vf610twr/Kconfig"
>> +source "board/gdsys/38x/Kconfig"
>>  source "board/gumstix/pepper/Kconfig"
>>  source "board/h2200/Kconfig"
>>  source "board/hisilicon/hikey/Kconfig"
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index 2c5b2f2..b0bd507 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -76,7 +76,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
>>   armada-xp-gp.dtb\
>>   armada-xp-maxbcm.dtb\
>>   armada-xp-synology-ds414.dtb\
>> - armada-xp-theadorable.dtb
>> + armada-xp-theadorable.dtb   \
>> + controlcenterdc.dtb
>>
>>  dtb-$(CONFIG_ARCH_UNIPHIER) += \
>>   uniphier-ld11-ref.dtb \
>> diff --git a/arch/arm/dts/controlcenterdc.dts 
>> b/arch/arm/dts/controlcenterdc.dts
>> new file mode 100644
>> index 000..baf0171
>> --- /dev/null
>> +++ b/arch/arm/dts/controlcenterdc.dts
>> @@ -0,0 +1,629 @@
>> +/*
>> + * Device Tree file for the Guntermann & Drunck ControlCenter-Compact board
>> + *
>> + * Copyright (C) 2016 Mario Six 
>> + *
>> + * based on the Device Tree file for Marvell Armada 388 evaluation board
>> + * (DB-88F6820), which is
>> + *
>> + * Copyright (C) 2014 Marvell
>> + *
>> + * Thomas Petazzoni 
>> + *
>> + * SPDX-License-Identifier: GPL-2.0+
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "armada-388.dtsi"
>> +
>> + {
>> + u-boot,dm-pre-reloc;
>> +};
>> +
>> + {
>> + u-boot,dm-pre-reloc;
>> +};
>> +
>> +/ {
>> + model = "Controlcenter Digital Compact";
>> + compatible = "marvell,a385-db", "marvell,armada388",
>> + "marvell,armada385", 

[U-Boot] eeprom - spi collides with i2c

[Ran Shalit]

Hello,

I'm trying to use eeprom with u-boot.
I've added CONFIG_CMD_EEPROM,
But then I see that the file uses spi epprom (bacause config use
CONFIG_SPI for other devices - not eeprom).
Does it mean I just need to
#undef CONFIG_SPI
at the start of cmd_eeprom.c file ?

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

Re: [U-Boot] [PATCH 06/14] net: core: Using an ethernet address from ROM is not bad

[Olliver Schinagl]

Hey Joe,


On 30-11-16 20:23, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

Currently we print a warning if the MAC address is read from
ROM/Hardware. This should not be concidered a bad or erronous thing. A
MAC address should come either from the hardware (ROM) or may be
set/overriden in the environment. Neither is a warning or error case.

Worthy of a warning is the case where both are set, so the user is
atleast aware something special is happening.

Signed-off-by: Olliver Schinagl 
---
  net/eth-uclass.c | 2 --
  1 file changed, 2 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 9703bea..aca3f6d 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -510,8 +510,6 @@ static int eth_post_probe(struct udevice *dev)
 memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
 } else if (is_valid_ethaddr(pdata->enetaddr)) {
 eth_setenv_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
-   printf("\nWarning: %s using MAC address from ROM\n",
-  dev->name);

I would prefer to see this go away in the same patch that adds the
source to other prints.
Great minds! in v2 (which I'm testing right now) this has been turned 
into one patch.

 } else if (is_zero_ethaddr(pdata->enetaddr)) {
  #ifdef CONFIG_NET_RANDOM_ETHADDR
 net_random_ethaddr(pdata->enetaddr);
--
2.10.2

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


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

Re: [U-Boot] [PATCH 09/14] net: Add ability to set MAC address via EEPROM

[Olliver Schinagl]

Hey Joe,


On 30-11-16 21:00, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

This patch allows Kconfig to enable and set parameters to make it
possible to read the MAC address from an EEPROM. The net core layer then
uses this information to read MAC addresses from this EEPROM.

Besides the various tuneables as to how to access the eeprom (bus,
address, addressing mode/length, 2 configurable that are EEPROM generic
(e.g. SPI or some other form of access) which are:

NET_ETHADDR_EEPROM_OFFSET, indicating where in the EEPROM the start of
the MAC address is. The default is 8 allowing for 8 bytes before the MAC
for other purposes (header MAGIC for example).

NET_ETHADDR_EEPROM_CRC8, indicating the MAC is appended with a CRC8-CCIT
checksum that should be verified.

Currently only I2C eeproms have been tested and thus only those options
are available, but shouldn't be a limit. NET_ETHADDR_EEPROM_SPI can be
just as created and added.

The code currently first checks if there is a non-zero MAC address in
the eeprom. If that fails to be the case, the read_rom_hwaddr can be
used by a board to supply the MAC in other ways.

If both these fails, the other code is still in place to query the
environent, which then can be used to override the hardware supplied
data.

Signed-off-by: Olliver Schinagl 
---
  doc/README.enetaddr | 99 +
  include/net.h   | 14 
  net/Kconfig | 59 +++
  net/eth-uclass.c|  9 +++--
  net/eth_common.c| 34 ++
  net/eth_legacy.c|  2 ++
  6 files changed, 214 insertions(+), 3 deletions(-)

diff --git a/doc/README.enetaddr b/doc/README.enetaddr
index 50e4899..89c1f7d 100644
--- a/doc/README.enetaddr
+++ b/doc/README.enetaddr
@@ -47,6 +47,105 @@ Correct flow of setting up the MAC address (summarized):
  Previous behavior had the MAC address always being programmed into hardware
  in the device's init() function.

+
+ EEPROM
+
+
+Boards may come with an EEPROM specifically to store configuration bits, such
+as a MAC address. Using CONFIG_NET_ETHADDR_EEPROM enables this feature.
+Depending on the board, the EEPROM may be connected on various methods, but
+currently, only the I2C bus can be used via CONFIG_NET_ETHADDR_EEPROM_I2C.
+
+The following config options are available,
+CONFIG_NET_ETHADDR_EEPROM_I2C_BUS is the I2C bus on which the eeprom is 
present.
+CONFIG_NET_ETHADDR_EEPROM_I2C_ADDR sets the address of the EEPROM, which
+defaults to the very common 0x50. Small size EEPROM's generally use single byte
+addressing but larger EEPROM's may use double byte addressing, which can be
+configured using CONFIG_NET_ETHADDR_EEPROM_ADDRLEN.
+
+Within the EEPROM, the MAC address can be stored on any arbitrary offset,
+CONFIG_NET_ETHADDR_EEPROM_OFFSET sets this to 8 as a default however, allowing
+the first 8 bytes to be used for an optional data, for example a configuration
+struct where the mac address is part of.
+
+Appending the 6 (ARP_HLEN) bytes is a CRC8 byte over the previous ARP_HLEN
+bytes. Whether to check this CRC8 or not is dependent on
+CONFIG_NET_ETHADDR_EEPROM_CRC8.
+
+To keep things nicely aligned, a final 'reserved' byte is added to the mac
+address + crc8 combo.
+
+A board may want to store more information in its eeprom, using the following
+example layout, this can be achieved.
+
+struct mac_addr {
+   uint8_t mac[ARP_HLEN];
+   uint8_t crc8;
+   uint8_t reserved;
+};
+
+struct config_eeprom {
+   uint32_t magic;
+   uint8_t version;
+   uint8_t reserved[2];
+   uint8_t mac_cnt;
+   struct mac_addr[mac_cnt];
+};
+
+Filling this in:
+struct config_eeprom eeprom = {
+   .magic = { 'M', 'g', 'i', 'c' },
+   .reserved = { 0x00, 0x00 },
+   .mac_cnt = 2,
+   .mac_addr = {
+   {
+   .mac = {
+   0x01, 0x23, 0x45,
+   0x67, 0x89, 0xab,
+   },
+   .crc8 = 0xbe,
+   .reserved = 0x00,
+   }, {
+   .mac = {
+   0xba, 0x98, 0x76,
+   0x54, 0x32, 0x10,
+   },
+   .crc8 = 0x82,
+   .reserved = 0x00,
+   },
+   },
+};
+
+The eeprom content would look like this.
+
+  4d 67 69 63 01 00 00 02  01 23 45 67 89 ab be 00 |Mgic.#Eg|
+0010  ba 98 76 54 32 10 82 00  |..vT2...|
+
+This can be done from linux using the i2c-tools:
+
+i2cset I2CBUS 0x50 0x08 0x01
+i2cset I2CBUS 0x50 0x09 0x23
+i2cset I2CBUS 0x50 0x0a 0x45
+i2cset I2CBUS 0x50 0x0b 0x67
+i2cset I2CBUS 0x50 0x0c 0x89
+i2cset I2CBUS 0x50 0x0d 0xab
+i2cset I2CBUS 0x50 0x0e 0xbe
+
+Alternativly this can be done from the u-boot console as:
+

[U-Boot] Uboot send pull request

[uboot]

 Hi Tom,

 Please pull the following patch from u-boot-nds32 into your tree.
 Thanks!

The following changes since commit 9ae0e14350758e6447c90615ff4df530549a45e2:

  Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)

are available in the git repository at:


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

for you to fetch changes up to 07ce9147e919be25d8928e54b4cd23460ff44a7f:

  nds32: Support eth DM. (2016-12-02 14:46:15 +0800)


rick (6):
  nds32: Support serial DM.
  nds32: Support timer DM.
  nds32: mmc: Support mmc DM.
  nds32: mmc: Support mmc DM.
  nds32: mmc: Support mmc DM.
  nds32: Support eth DM.

 arch/Kconfig|1 +
 arch/nds32/cpu/n1213/ag101/timer.c  |3 +-
 arch/nds32/cpu/n1213/start.S|   13 +-
 arch/nds32/dts/Makefile |   14 ++
 arch/nds32/dts/ag101p.dts   |   71 
 arch/nds32/include/asm/config.h |1 +
 board/AndesTech/adp-ag101p/adp-ag101p.c |7 +-
 configs/adp-ag101p_defconfig|   14 ++
 drivers/mmc/Kconfig |7 +
 drivers/mmc/Makefile|1 +
 drivers/mmc/ftsdc010_mci.c  |  106 +---
 drivers/mmc/nds32_mmc.c |  140 +++
 drivers/net/Kconfig |5 +
 drivers/net/ftmac100.c  |  281 +--
 drivers/timer/Kconfig   |6 +
 drivers/timer/Makefile  |1 +
 drivers/timer/ag101p_timer.c|  122 ++
 include/configs/adp-ag101p.h|   14 +-
 include/faraday/ftsdc010.h  |   41 +
 19 files changed, 752 insertions(+), 96 deletions(-)
 create mode 100644 arch/nds32/dts/Makefile
 create mode 100644 arch/nds32/dts/ag101p.dts
 create mode 100644 drivers/mmc/nds32_mmc.c
 create mode 100644 drivers/timer/ag101p_timer.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] powerpc: Retain compatible property for L2 cache

[Chris Packham]

When setting the compatible property for the L2 cache ensure that we
follow the documented binding by setting both
"-l2-cache-controller" and "cache" as values.

Signed-off-by: Chris Packham 
---

Changes in v2:
- extract a helper function to set the compatible property and use it in
  both the CONFIG_L2_CACHE and CONFIG_BACKSIDE_L2_CACHE cases.

 arch/powerpc/cpu/mpc85xx/fdt.c | 61 +-
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 047c972ac78e..8aaf53a65458 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -180,6 +180,39 @@ static inline void ft_fixup_l3cache(void *blob, int off)
 #define ft_fixup_l3cache(x, y)
 #endif
 
+#if defined(CONFIG_L2_CACHE) || \
+   defined(CONFIG_BACKSIDE_L2_CACHE) || \
+   defined(CONFIG_SYS_FSL_QORIQ_CHASSIS2)
+static inline void ft_fixup_l2cache_compatible(void *blob, int off)
+{
+   int len;
+   struct cpu_type *cpu = identify_cpu(SVR_SOC_VER(get_svr()));
+
+   if (cpu) {
+   char buf[40];
+
+   if (isdigit(cpu->name[0])) {
+   /* MPC, where  == 4-digit number */
+   len = sprintf(buf, "fsl,mpc%s-l2-cache-controller",
+   cpu->name) + 1;
+   } else {
+   /* P or T, where  == 4-digit number */
+   len = sprintf(buf, "fsl,%c%s-l2-cache-controller",
+   tolower(cpu->name[0]), cpu->name + 1) + 1;
+   }
+
+   /*
+* append "cache" after the NULL character that the previous
+* sprintf wrote.  This is how a device tree stores multiple
+* strings in a property.
+*/
+   len += sprintf(buf + len, "cache") + 1;
+
+   fdt_setprop(blob, off, "compatible", buf, len);
+   }
+}
+#endif
+
 #if defined(CONFIG_L2_CACHE)
 /* return size in kilobytes */
 static inline u32 l2cache_size(void)
@@ -215,9 +248,8 @@ static inline u32 l2cache_size(void)
 
 static inline void ft_fixup_l2cache(void *blob)
 {
-   int len, off;
+   int off;
u32 *ph;
-   struct cpu_type *cpu = identify_cpu(SVR_SOC_VER(get_svr()));
 
const u32 line_size = 32;
const u32 num_ways = 8;
@@ -243,28 +275,7 @@ static inline void ft_fixup_l2cache(void *blob)
return ;
}
 
-   if (cpu) {
-   char buf[40];
-
-   if (isdigit(cpu->name[0])) {
-   /* MPC, where  == 4-digit number */
-   len = sprintf(buf, "fsl,mpc%s-l2-cache-controller",
-   cpu->name) + 1;
-   } else {
-   /* P or T, where  == 4-digit number */
-   len = sprintf(buf, "fsl,%c%s-l2-cache-controller",
-   tolower(cpu->name[0]), cpu->name + 1) + 1;
-   }
-
-   /*
-* append "cache" after the NULL character that the previous
-* sprintf wrote.  This is how a device tree stores multiple
-* strings in a property.
-*/
-   len += sprintf(buf + len, "cache") + 1;
-
-   fdt_setprop(blob, off, "compatible", buf, len);
-   }
+   ft_fixup_l2cache_compatible(blob, off);
fdt_setprop(blob, off, "cache-unified", NULL, 0);
fdt_setprop_cell(blob, off, "cache-block-size", line_size);
fdt_setprop_cell(blob, off, "cache-size", size);
@@ -337,7 +348,7 @@ static inline void ft_fixup_l2cache(void *blob)
fdt_setprop_cell(blob, l2_off, "cache-size", size);
fdt_setprop_cell(blob, l2_off, "cache-sets", num_sets);
fdt_setprop_cell(blob, l2_off, "cache-level", 2);
-   fdt_setprop(blob, l2_off, "compatible", "cache", 6);
+   ft_fixup_l2cache_compatible(blob, l2_off);
}
 
if (l3_off < 0) {
-- 
2.10.2

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

Re: [U-Boot] Uboot send pull request

[Jaehoon Chung]

On 12/02/2016 04:44 PM, ub...@andestech.com wrote:
>  Hi Tom,
> 
>  Please pull the following patch from u-boot-nds32 into your tree.
>  Thanks!
> 
> The following changes since commit 9ae0e14350758e6447c90615ff4df530549a45e2:
> 
>   Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-nds32.git master
> 
> for you to fetch changes up to 07ce9147e919be25d8928e54b4cd23460ff44a7f:
> 
>   nds32: Support eth DM. (2016-12-02 14:46:15 +0800)
> 
> 
> rick (6):
>   nds32: Support serial DM.
>   nds32: Support timer DM.
>   nds32: mmc: Support mmc DM.
>   nds32: mmc: Support mmc DM.
>   nds32: mmc: Support mmc DM.
>   nds32: Support eth DM.

Even though I don't know how Tom thinks about this PR, I don't agree this PR.
There are no review and ack about your patches.

Best Regards,
Jaehoon Chung

> 
>  arch/Kconfig|1 +
>  arch/nds32/cpu/n1213/ag101/timer.c  |3 +-
>  arch/nds32/cpu/n1213/start.S|   13 +-
>  arch/nds32/dts/Makefile |   14 ++
>  arch/nds32/dts/ag101p.dts   |   71 
>  arch/nds32/include/asm/config.h |1 +
>  board/AndesTech/adp-ag101p/adp-ag101p.c |7 +-
>  configs/adp-ag101p_defconfig|   14 ++
>  drivers/mmc/Kconfig |7 +
>  drivers/mmc/Makefile|1 +
>  drivers/mmc/ftsdc010_mci.c  |  106 +---
>  drivers/mmc/nds32_mmc.c |  140 +++
>  drivers/net/Kconfig |5 +
>  drivers/net/ftmac100.c  |  281 
> +--
>  drivers/timer/Kconfig   |6 +
>  drivers/timer/Makefile  |1 +
>  drivers/timer/ag101p_timer.c|  122 ++
>  include/configs/adp-ag101p.h|   14 +-
>  include/faraday/ftsdc010.h  |   41 +
>  19 files changed, 752 insertions(+), 96 deletions(-)
>  create mode 100644 arch/nds32/dts/Makefile
>  create mode 100644 arch/nds32/dts/ag101p.dts
>  create mode 100644 drivers/mmc/nds32_mmc.c
>  create mode 100644 drivers/timer/ag101p_timer.c
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
> 

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

[U-Boot] [PATCH] configs: colibri_vf: Add fdt_fixup environment variable

[Sanchayan Maity]

u-boot allows modifying a device tree after it is loaded into
memory. Add fdt_fixup hook in u-boot environment which can
facilitate such modifications.

Signed-off-by: Sanchayan Maity 
---
 include/configs/colibri_vf.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
index d58145e..be28324 100644
--- a/include/configs/colibri_vf.h
+++ b/include/configs/colibri_vf.h
@@ -99,7 +99,7 @@
"${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
"load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
"load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb && " \
-   "bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
+   "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #define NFS_BOOTCMD \
"nfsargs=ip=:eth0: root=/dev/nfs\0" \
@@ -108,7 +108,7 @@
"${setupargs} ${vidargs}; echo Booting from NFS...;" \
"dhcp ${kernel_addr_r} && " \
"tftp ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
-   "bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
+   "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #define UBI_BOOTCMD\
"ubiargs=ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs " \
@@ -119,7 +119,7 @@
"ubi part ubi && " \
"ubi read ${kernel_addr_r} kernel && " \
"ubi read ${fdt_addr_r} dtb && " \
-   "bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
+   "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
 
 #define CONFIG_BOOTCOMMAND "run ubiboot; run sdboot; run nfsboot"
 
@@ -131,6 +131,7 @@
"kernel_file=zImage\0" \
"fdt_file=${soc}-colibri-${fdt_board}.dtb\0" \
"fdt_board=eval-v3\0" \
+   "fdt_fixup=;\0" \
"defargs=\0" \
"console=ttyLP0\0" \
"setup=setenv setupargs " \
-- 
2.10.2

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

Re: [U-Boot] [PATCH 12/14] fdt: eth_fixup: Add hook for board to override MAC

[Olliver Schinagl]

Hey Joe,


On 30-11-16 21:40, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

This patch adds a method for the board to set the MAC address if the
environment is not yet set. The environment based MAC addresses are not
touched, but if the fdt has an alias set, it is parsed and put into the
environment.

E.g. The environment contains ethaddr and eth1addr, and the fdt contains
an ethernet1 nothing happens. If the fdt contains ethernet2 however, it
is parsed and inserted into the environment as eth2addr.

Signed-off-by: Olliver Schinagl 
---
  common/fdt_support.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index c34a13c..f127392 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -465,6 +465,11 @@ int fdt_fixup_memory(void *blob, u64 start, u64 size)
 return fdt_fixup_memory_banks(blob, , , 1);
  }

+__weak int board_get_enetaddr(const int i, unsigned char *mac_addr)

Ugh. This collides with a function in board/v38b/ethaddr.c and in
board/intercontrol/digsy_mtc/digsy_mtc.c

Also, it's so generic, and only gets called by the fdt fixup stuff...
This function should probably be named in such a way that its
association with fdt is clear.

I did not notice that, sorry! But naming suggestions are welcome :)

Right now, I use it in two unrelated spots however.

from the fdt as seen above and in a subclass driver (which will come up 
for review) as suggested by Simon.


There I do:

+static int sunxi_gmac_eth_read_rom_hwaddr(struct udevice *dev)
+{
+   struct eth_pdata *pdata = dev_get_platdata(dev);
+
+   return board_get_enetaddr(dev->seq, pdata->enetaddr);
+}
+
 const struct eth_ops sunxi_gmac_eth_ops = {
.start  = designware_eth_start,
.send   = designware_eth_send,
@@ -102,6 +110,7 @@ const struct eth_ops sunxi_gmac_eth_ops = {
.free_pkt   = designware_eth_free_pkt,
.stop   = designware_eth_stop,
.write_hwaddr   = designware_eth_write_hwaddr,
+   .read_rom_hwaddr= sunxi_gmac_eth_read_rom_hwaddr,
 };

which is completly unrelated to the fdt.

So naming suggestion or overal suggestion how to handle this nice and 
generically?


Based from the name however I would think that all board_get_enetaddr's 
work the same however so should have been interchangeable? Or was that 
silly thinking?


Olliver




+{
+   return -ENOSYS;
+}
+
  void fdt_fixup_ethernet(void *fdt)
  {
 int i, prop;
@@ -507,7 +512,8 @@ void fdt_fixup_ethernet(void *fdt)
 if (fdt_eth_addr)
 eth_parse_enetaddr(fdt_eth_addr, mac_addr);
 else
-   continue;
+   if (board_get_enetaddr(i, mac_addr) < 0)
+   continue;

 do_fixup_by_path(fdt, path, "mac-address",
  _addr, 6, 0);
--
2.10.2

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


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

Re: [U-Boot] flash the images to NAND automatically with SD Boot in uboot?

[Jaehoon Chung]

On 12/02/2016 12:24 AM, grbesd1 wrote:
> Actually i need to know how to add the functionality. has anyone done before
> because i tried to look more information on these i didn't find much help.
> 
> I have to add a function in uboot source code, which perform all the listed
> operation step by step.

Well, you need to implement this in your local..I think it can use the 
magic-number as some hex value.
When you make the u-boot.bin, add the hex magic number at fixed offest.

Then when read that offest, bootloader can know that it's which image is.
It's for only local testing.

And auto flashing function might call when boot from SD..
(I'm not sure but you know how to distinguish with SD and NAND. e.g some 
register bit or OM Pin)

Best Regards,
Jaehoon Chung

> 
> regards,
> grbesd1 
> 
> 
> Jaehoon Chung wrote
>> Hi, 
>>
>> On 12/01/2016 05:30 PM, grbesd1 wrote:
>>> Hi Guys,
>>>
>>> i need little help, i have to auto update nand every time i put my sd
>>> card.
>>>
>>> i can get which register[pin mux] decides NAND or SD boot. I'm using 2010
>>> uboot code.
>>>
>>> what i'm looking is
>>>
>>> 1. This should run only when the SD boot is happening
>>> 2. I have to create auto upgrade function in uboot source code.
>>> 3. In this function, check whether ‘u-boot.min.nand’, ‘u-boot.bin’ files
>>> are
>>> available in the SD Card[FAT partition][fatls mmc 0]
>>> If available:
>>> Do the flashing u-boot.min.nand to nand flash.
>>> Flash u-boot.bin to NAND.
>>> 4. then exit.
>>
>> Sorry, i don't know exactly what is your question.
>> Your question is those sequences is right or not?
>>
>> Best Regards,
>> Jaehoon Chung
>>
>>>
>>> uboot source code
>>>
>>> http://arago-project.org/git/projects/?p=u-boot-ipnc-rdk-dm81xx.git;a=tree
>>>
>>> regards,
>>> grbesd1
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://u-boot.10912.n7.nabble.com/flash-the-images-to-NAND-automatically-with-SD-Boot-in-uboot-tp275350.html
>>> Sent from the U-Boot mailing list archive at Nabble.com.
>>> ___
>>> U-Boot mailing list
>>>
> 
>> U-Boot@.denx
> 
>>> http://lists.denx.de/mailman/listinfo/u-boot
>>>
>>
>> ___
>> U-Boot mailing list
> 
>> U-Boot@.denx
> 
>> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://u-boot.10912.n7.nabble.com/flash-the-images-to-NAND-automatically-with-SD-Boot-in-uboot-tp275350p275405.html
> Sent from the U-Boot mailing list archive at Nabble.com.
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

Re: [U-Boot] [PATCH 07/14] net: core: Inform the user of the device MAC address

[Olliver Schinagl]

Hey Joe,


On 30-11-16 20:29, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

In certain conditions we currently print the MAC address. For example a
warning when a random mac address is in use or a missmatch between HW
and ENV.

If all things went well however (but even if there is a miss-match) we
do not inform the user what the final MAC address of the device is.

Lets print the final MAC address of the device with which it has been
setup.

Signed-off-by: Olliver Schinagl 
---
  net/eth-uclass.c | 9 ++---
  net/eth_legacy.c | 3 +++
  2 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index aca3f6d..5c888b8 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -413,11 +413,12 @@ int eth_initialize(void)
 }

 bootstage_mark(BOOTSTAGE_ID_NET_ETH_INIT);
+   putc('\n');
 do {
-   if (num_devices)
-   printf(", ");
+   struct eth_pdata *pdata = dev->platdata;

-   printf("eth%d: %s", dev->seq, dev->name);
+   printf("eth%d:  %s [%pM]\n", dev->seq, dev->name,
+pdata->enetaddr);

 if (ethprime && dev == prime_dev)
 printf(" [PRIME]");
@@ -522,6 +523,8 @@ static int eth_post_probe(struct udevice *dev)
  #endif
 }

+   printf("%s ", dev->name);
+

Why this?

Can you send to the list what an example output looks like?


Absolutly. Right now I have this, with the v2 work I'm doing to print 
the mac source.


Net:   ethernet@01c5 
eth0:  ethernet@01c5 [cc:bd:d3:00:01:c6] (EEPROM)
eth1:  [] ()


If there is an error or warning from the net layer (during probe, during 
init etc)

we get something like

Net:   CRC error on MAC address from EEPROM on device: ethernet@01c5 
 on device: 

eth0:  ethernet@01c5 [02:4b:04:42:12:31] (driver)

(where driver is the read_rom_hwaddr hook a driver supplies).

I did not go over all error messages to print it as pretty. So in that 
case it will be

Net:   Some error. ethernet@01c5

Olliver


Thanks,
-Joe


 return 0;
  }

diff --git a/net/eth_legacy.c b/net/eth_legacy.c
index 2b2c2de..bf4de37 100644
--- a/net/eth_legacy.c
+++ b/net/eth_legacy.c
@@ -178,6 +178,9 @@ int eth_write_hwaddr(struct eth_device *dev, const char 
*base_name,
dev->name);
 }

+   printf("%s (eth%d) has MAC address: %pM\n",
+  dev->name, eth_number, dev->enetaddr);
+
 return ret;
  }

--
2.10.2

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


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

[U-Boot] [RFC PATCH] mmc: spear: remove the entire spear_sdhci.c file

[Jaehoon Chung]

Remove the entire spear_sdhci.c file.
There is no use case. This is dead codes.
Also there is no place to call "spear_sdhci_init()" anywhere.

If some people use this file, let me know, plz.

Signed-off-by: Jaehoon Chung 
---
 drivers/mmc/Makefile  |  1 -
 drivers/mmc/spear_sdhci.c | 27 ---
 2 files changed, 28 deletions(-)
 delete mode 100644 drivers/mmc/spear_sdhci.c

diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index d850758..94da954 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -52,7 +52,6 @@ obj-$(CONFIG_SDHCI) += sdhci.o
 obj-$(CONFIG_SH_MMCIF) += sh_mmcif.o
 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
diff --git a/drivers/mmc/spear_sdhci.c b/drivers/mmc/spear_sdhci.c
deleted file mode 100644
index 06179cd..000
--- a/drivers/mmc/spear_sdhci.c
+++ /dev/null
@@ -1,27 +0,0 @@
-/*
- * (C) Copyright 2012
- * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-
-int spear_sdhci_init(u32 regbase, u32 max_clk, u32 min_clk, u32 quirks)
-{
-   struct sdhci_host *host = NULL;
-   host = (struct sdhci_host *)malloc(sizeof(struct sdhci_host));
-   if (!host) {
-   printf("sdhci host malloc fail!\n");
-   return 1;
-   }
-
-   host->name = "sdhci";
-   host->ioaddr = (void *)regbase;
-   host->quirks = quirks;
-
-   add_sdhci(host, max_clk, min_clk);
-   return 0;
-}
-- 
2.10.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Jyri Sarha]

Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
the default values LCDC suffers from DMA FIFO underflows and frame
synchronization lost errors. The initialization values are the highest
that work flawlessly when heavy memory load is generated by CPU. 32bpp
colors were used in the test. On BBB the video mode used 110MHz pixel
clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
clock.

Signed-off-by: Jyri Sarha 
---
This patch have been part of TI's latest 2016LTS based release and
has gone trough our regular tesing as a part of that. There has been
no noticable side effects.

Cheers,
Jyri

 arch/arm/cpu/armv7/am33xx/ddr.c | 4 
 arch/arm/include/asm/arch-am33xx/ddr_defs.h | 8 
 arch/arm/include/asm/emif.h | 1 +
 board/ti/am335x/board.c | 2 ++
 4 files changed, 15 insertions(+)

diff --git a/arch/arm/cpu/armv7/am33xx/ddr.c b/arch/arm/cpu/armv7/am33xx/ddr.c
index 6acf30c..690487e 100644
--- a/arch/arm/cpu/armv7/am33xx/ddr.c
+++ b/arch/arm/cpu/armv7/am33xx/ddr.c
@@ -180,6 +180,10 @@ void config_sdram(const struct emif_regs *regs, int nr)
writel(regs->ref_ctrl, _reg[nr]->emif_sdram_ref_ctrl);
writel(regs->ref_ctrl, _reg[nr]->emif_sdram_ref_ctrl_shdw);
writel(regs->sdram_config, _reg[nr]->emif_sdram_config);
+
+   /* Write REG_COS_COUNT_1, REG_COS_COUNT_2, and REG_PR_OLD_COUNT. */
+   if (regs->ocp_config)
+   writel(regs->ocp_config, _reg[nr]->emif_l3_config);
 }
 
 /**
diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
index 43e122e..c71cfd0 100644
--- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
+++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
@@ -25,6 +25,14 @@
 #endif
 #define PHY_EN_DYN_PWRDN   (0x1 << 20)
 
+/**
+ * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
+ * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
+ * Synchronization Lost errors.
+ */
+#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK   0x00141414
+#define EMIF_OCP_CONFIG_AM335X_EVM 0x003d3d3d
+
 /* Micron MT47H128M16RT-25E */
 #define MT47H128M16RT25E_EMIF_READ_LATENCY 0x15
 #define MT47H128M16RT25E_EMIF_TIM1 0x0666B3C9
diff --git a/arch/arm/include/asm/emif.h b/arch/arm/include/asm/emif.h
index b00dece..9a46340 100644
--- a/arch/arm/include/asm/emif.h
+++ b/arch/arm/include/asm/emif.h
@@ -1171,6 +1171,7 @@ struct emif_regs {
u32 sdram_tim1;
u32 sdram_tim2;
u32 sdram_tim3;
+   u32 ocp_config;
u32 read_idle_ctrl;
u32 zq_config;
u32 temp_alert_config;
diff --git a/board/ti/am335x/board.c b/board/ti/am335x/board.c
index 16113b5..02e68a6 100644
--- a/board/ti/am335x/board.c
+++ b/board/ti/am335x/board.c
@@ -201,6 +201,7 @@ static struct emif_regs ddr3_beagleblack_emif_reg_data = {
.sdram_tim1 = MT41K256M16HA125E_EMIF_TIM1,
.sdram_tim2 = MT41K256M16HA125E_EMIF_TIM2,
.sdram_tim3 = MT41K256M16HA125E_EMIF_TIM3,
+   .ocp_config = EMIF_OCP_CONFIG_BEAGLEBONE_BLACK,
.zq_config = MT41K256M16HA125E_ZQ_CFG,
.emif_ddr_phy_ctlr_1 = MT41K256M16HA125E_EMIF_READ_LATENCY,
 };
@@ -211,6 +212,7 @@ static struct emif_regs ddr3_evm_emif_reg_data = {
.sdram_tim1 = MT41J512M8RH125_EMIF_TIM1,
.sdram_tim2 = MT41J512M8RH125_EMIF_TIM2,
.sdram_tim3 = MT41J512M8RH125_EMIF_TIM3,
+   .ocp_config = EMIF_OCP_CONFIG_AM335X_EVM,
.zq_config = MT41J512M8RH125_ZQ_CFG,
.emif_ddr_phy_ctlr_1 = MT41J512M8RH125_EMIF_READ_LATENCY |
PHY_EN_DYN_PWRDN,
-- 
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/4] usb: dwc2: add support for external vbus supply

[Simon Glass]

Hi Marek,

On 29 November 2016 at 19:00, Marek Vasut  wrote:
> On 11/29/2016 09:46 AM, Kever Yang wrote:
>> Hi Marek,
>>
>> On 11/26/2016 12:46 AM, Marek Vasut wrote:
>>> On 11/24/2016 08:29 AM, Kever Yang wrote:
 Some board do not use the dwc2 internal VBUS_DRV signal, but
 use a gpio pin to enable the 5.0V VBUS power, add interface to
 enable the power in dwc2 driver.

 Signed-off-by: Kever Yang 
 ---

 Changes in v2: None

   drivers/usb/host/dwc2.c | 29 +
   1 file changed, 29 insertions(+)

 diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
 index d08879d..8292aa8 100644
 --- a/drivers/usb/host/dwc2.c
 +++ b/drivers/usb/host/dwc2.c
 @@ -15,6 +15,7 @@
   #include 
   #include 
   #include 
 +#include 
 #include "dwc2.h"
   @@ -55,6 +56,8 @@ DEFINE_ALIGN_BUFFER(uint8_t, status_buffer_addr,
 DWC2_STATUS_BUF_SIZE,
   static struct dwc2_priv local;
   #endif
   +static struct udevice *g_dwc2_udev;
>>> Can we avoid the static global var ?
>>
>> I don't want to use this global var either, but I don't know how to get
>> this udev structure
>> without this var, do you have any good suggestion?
>> BTW, of_container() is not available to find the udevice structure with
>> dwc2_priv pointer.
>
> But you can ie. store the udevice in priv ? Simon , any hints ?
>

I think it can just be a parameter. I sent a v3 patch to show how to do it.

>>>
 +
   /*
* DWC2 IP interface
*/
 @@ -159,6 +162,29 @@ static void dwc_otg_core_reset(struct
 dwc2_core_regs *regs)
   mdelay(100);
   }
   +static int dwc_vbus_supply_init(void)
 +{
 +#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR) && \
 +!defined(CONFIG_SPL_BUILD)
>>> Why does this not work for SPL ?
>>
>> We do not enable the USB driver in SPL, in this case I can just drop the
>> CONFIG_SPL_BUILD
>> because the driver in not compiled in SPL.
>
> Correct
>
>>> btw, I'd rather see this as:
>>>
>>> #if FOO
>>> function bar()
>>> {
>>>   ...
>>> }
>>> #else
>>> static inline function bar()
>>> {
>>>   return 0;
>>> }
>>> #endif
>>>
 +struct udevice *vbus_supply;
 +int ret;
 +
 +ret = device_get_supply_regulator(g_dwc2_udev, "vbus-supply",
 +  _supply);
>>> Is this compatible with the Linux DWC2 DT bindings ?
>>
>> This compatible in kernel is in in phy dts node, the dwc2 driver and phy
>> driver
>> in U-Boot are both very different from kernel now, so I chose a place
>> which is
>> reasonable to enable the vbus.
>
> DT is driver and OS agnostic, so if there is already agreed-upon binding
> for specifying external VBUS to DWC2, we should use it.
> Why would that be a problem ?

You can bring in the DT node, then use special code to find it. But I
looked in the linux kernel and cannot find vbus-supply. Are you going
to send that patch to the kernel at some point?

>
 +if (ret) {
 +debug("%s: No vbus supply\n", g_dwc2_udev->name);
 +return 0;
 +}
 +
 +ret = regulator_set_enable(vbus_supply, true);
>>> Shouldn't the regulator be enabled when we enable VBUS for a port
>>> instead of here ? And where is it disabled ?
>>
>> I add this function just after the controller enable the port power bit,
>> isn't it?
>> I didn't found anywhere the driver disable the vbus power, we do not
>> need it
>> in U-Boot?
>
> So we leave it enabled and pass the hardware to kernel in some weird
> state ? That's a bit odd, isn't it. dwc2_lowlevel_stop() might be a
> good place to disable the regulator ...
>
> --
> Best regards,
> Marek Vasut

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

Re: [U-Boot] [PATCH resend v3 2/6] drivers: usb: gadget: ether: access network_started using local variable

[Simon Glass]

On 29 November 2016 at 16:20, Joe Hershberger  wrote:
> On Thu, Nov 17, 2016 at 11:19 PM, Mugunthan V N  wrote:
>> network_started of struct eth_dev can be accessed using local
>> variable dev and no reason to access it with the global struct.
>>
>> Signed-off-by: Mugunthan V N 
>> Reviewed-by: Simon Glass 
>
> Acked-by: Joe Hershberger 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend v3 1/6] drivers: usb: gadget: ether: adopt to usb driver model

[Simon Glass]

On 29 November 2016 at 16:55, Joe Hershberger  wrote:
> On Thu, Nov 17, 2016 at 11:19 PM, Mugunthan V N  wrote:
>> Convert usb ether gadget to adopt usb driver model
>>
>> Signed-off-by: Mugunthan V N 
>
> Acked-by: Joe Hershberger 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 12/15 v2] pci: mvebu: Add PCIe driver for Armada-8K

[Simon Glass]

On 28 November 2016 at 05:38, Stefan Roese  wrote:
> From: Shadi Ammouri 
>
> This patch adds a driver for the PCIe controller integrated in the
> Marvell Armada-8K SoC. This controller is based on the DesignWare
> IP core.
>
> The original version was written by Shadi and Yehuda. I ported this
> driver to the latest mainline U-Boot version with DM support.
>
> Tested on the Marvell DB-88F8040 Armada-8K eval board.
>
> Signed-off-by: Shadi Ammouri 
> Signed-off-by: Yehuda Yitschak 
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Nadav Haklai 
> Cc: Neta Zur Hershkovits 
> Cc: Kostya Porotchkin 
> Cc: Omri Itach 
> Cc: Igal Liberman 
> Cc: Haim Boot 
> Cc: Hanna Hawa 
> ---
> v2:
> - Removed host struct from private data struct
> - Added comments to structs and functions
> - Moved shift into the macro for PCIE_LINK_STATUS_SPEED_MASK
>   and PCIE_LINK_STATUS_WIDTH_MASK
> - Added Email addresses to ToDo statement
> - Used clrsetbits_le32(9 where applicable
> - Added const to register base pointer
> - Used new core function dev_get_addr_size_index() to retrieve
>   addr and size
> - Added code to configure the PCIe root complex device as PCI
>   bridge device
>
>  drivers/pci/Kconfig |  10 +
>  drivers/pci/Makefile|   1 +
>  drivers/pci/pcie_dw_mvebu.c | 535 
> 
>  3 files changed, 546 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 resend v3 3/6] drivers: usb: gadget: ether: consolidate global devices to single struct

[Simon Glass]

On 29 November 2016 at 16:55, Joe Hershberger  wrote:
> On Thu, Nov 17, 2016 at 11:36 PM, Mugunthan V N  wrote:
>> Consolidate the net device, usb eth device and gadget device
>> struct to single struct and a single global variable so that the
>> same can be passed as priv of ethernet driver.
>>
>> Signed-off-by: Mugunthan V N 
>> Reviewed-by: Simon Glass 
>
> Acked-by: Joe Hershberger 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/13] serial: 16550: Add getfcr accessor

[Simon Glass]

On 30 November 2016 at 18:06, Marek Vasut  wrote:
> Add function which allows fetching the default FCR register setting
> from platform data for DM , while retaining old behavior for non-DM
> by returning UART_FCRVAL.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
> V2: If CONFIG_DM_SERIAL and DEBUG_UART are enabled, the ns16550_getfcr()
> can be invoked with NULL plat data . Check for this case and return
> the default UART_FCRVAL then.
> V3: It turns out that if DEBUG_UART is defined, $port points directly to
> hardware registers. Add additional ifdef to handle the case where
> debug uart is enabled with DM_SERIAL correctly.
> V4: Use UART_FCRVAL in _debug_uart_init() directly
> ---
>  drivers/serial/ns16550.c | 18 --
>  include/ns16550.h|  1 +
>  2 files changed, 17 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

But I think you are missing the 'v4' tag in your email subject.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 03/13] serial: 16550: Add Ingenic JZ4780 support

[Simon Glass]

On 30 November 2016 at 18:06, Marek Vasut  wrote:
> Add compatibility string for the Ingenic JZ4780 SoC, the necessary
> UART enable bit into FCR and register shift. Neither are encoded
> in the DTS coming from Linux, so we need to support it this way.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> Cc: Daniel Schwierzeck 
> Cc: Paul Burton 
> ---
> V2: Drop the reg_shift and move it to OF
> ---
>  drivers/serial/ns16550.c | 5 +
>  include/ns16550.h| 3 +++
>  2 files changed, 8 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 resend v3 4/6] drivers: usb: gadget: ether: use net device priv to pass usb ether priv

[Simon Glass]

On 29 November 2016 at 16:55, Joe Hershberger  wrote:
> On Thu, Nov 17, 2016 at 11:37 PM, Mugunthan V N  wrote:
>> Use net device priv to pass usb ether priv and use it in
>> net device ops callback.
>>
>> Signed-off-by: Mugunthan V N 
>> Reviewed-by: Simon Glass 
>
> Acked-by: Joe Hershberger 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH resend v3 5/6] drivers: usb: gadget: ether: prepare driver for driver model migration

[Simon Glass]

On 29 November 2016 at 16:55, Joe Hershberger  wrote:
> On Thu, Nov 17, 2016 at 11:38 PM, Mugunthan V N  wrote:
>> prepare driver for driver model migration
>>
>> Signed-off-by: Mugunthan V N 
>
> Acked-by: Joe Hershberger 

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

Here are some buildman enhancements, a new TPM driver, the beginnings
of the USB gadget DM conversion along with a few fixes.


The following changes since commit 9ae0e14350758e6447c90615ff4df530549a45e2:

  Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to f7f191ee41c0590917f4a969b569af0a01106380:

  cmd/fdt: fix uncallable systemsetup command (2016-12-02 20:53:20 -0700)


Fabien Parent (1):
  cmd/fdt: fix uncallable systemsetup command

George McCollister (1):
  tpm: tpm_tis_lpc: Add support for AT97SC3204

Michal Simek (1):
  dm: blk: Fix get_desc to return block device descriptor

Mugunthan V N (5):
  drivers: usb: gadget: ether: access network_started using local variable
  drivers: usb: gadget: ether: adopt to usb driver model
  drivers: usb: gadget: ether: consolidate global devices to single struct
  drivers: usb: gadget: ether: use net device priv to pass usb ether priv
  drivers: usb: gadget: ether: prepare driver for driver model migration

Simon Glass (7):
  Makefile: Add a target to create the .cfg files
  buildman: Add an option to just create the config
  buildman: Add documentation for CONFIG checking
  buildman: Squash useless output from -K
  buildman: Clean up odd characters on the terminal
  buildman: Rename do_build to config_only
  dm: core: Handle global_data moving in SPL

Stefan Brüns (1):
  cmd/tpm_test: Fix misleading code indentation

Tom Rini (1):
  sandboxfs: Fix resource leak

 Makefile|   3 +
 cmd/fdt.c   |  22 ---
 cmd/tpm_test.c  |  12 ++--
 common/spl/spl.c|   3 +
 drivers/block/blk-uclass.c  |   2 +
 drivers/core/root.c |   7 +++
 drivers/tpm/tpm_tis_lpc.c   |  37 +---
 drivers/usb/gadget/ether.c  | 168
-
 fs/sandbox/sandboxfs.c  |   5 +-
 include/dm/root.h   |  10 
 tools/buildman/README   |  49 
 tools/buildman/builder.py   |  39 -
 tools/buildman/builderthread.py |  14 +++--
 tools/buildman/cmdline.py   |   4 ++
 tools/buildman/control.py   |   4 +-
 15 files changed, 278 insertions(+), 101 deletions(-)

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

[U-Boot] [PATCH v3] usb: dwc2: add support for external vbus supply

[Simon Glass]

From: Kever Yang 

Some board do not use the dwc2 internal VBUS_DRV signal, but
use a gpio pin to enable the 5.0V VBUS power, add interface to
enable the power in dwc2 driver.

Signed-off-by: Kever Yang 
Signed-off-by: Simon Glass 
---

Changes in v3:
- Drop use of static variable

 drivers/usb/host/dwc2.c | 39 ++-
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
index d08879d..fa11364 100644
--- a/drivers/usb/host/dwc2.c
+++ b/drivers/usb/host/dwc2.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "dwc2.h"
 
@@ -159,6 +160,28 @@ static void dwc_otg_core_reset(struct dwc2_core_regs *regs)
mdelay(100);
 }
 
+static int dwc_vbus_supply_init(struct udevice *dev)
+{
+#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR) && \
+   !defined(CONFIG_SPL_BUILD)
+   struct udevice *vbus_supply;
+   int ret;
+
+   ret = device_get_supply_regulator(dev, "vbus-supply", _supply);
+   if (ret) {
+   debug("%s: No vbus supply\n", dev->name);
+   return 0;
+   }
+
+   ret = regulator_set_enable(vbus_supply, true);
+   if (ret) {
+   error("Error enabling vbus supply\n");
+   return ret;
+   }
+#endif
+   return 0;
+}
+
 /*
  * This function initializes the DWC_otg controller registers for
  * host mode.
@@ -167,10 +190,12 @@ static void dwc_otg_core_reset(struct dwc2_core_regs 
*regs)
  * request queues. Host channels are reset to ensure that they are ready for
  * performing transfers.
  *
+ * @param dev USB Device (NULL if driver model is not being used)
  * @param regs Programming view of DWC_otg controller
  *
  */
-static void dwc_otg_core_host_init(struct dwc2_core_regs *regs)
+static void dwc_otg_core_host_init(struct udevice *dev,
+  struct dwc2_core_regs *regs)
 {
uint32_t nptxfifosize = 0;
uint32_t ptxfifosize = 0;
@@ -248,6 +273,9 @@ static void dwc_otg_core_host_init(struct dwc2_core_regs 
*regs)
writel(hprt0, >hprt0);
}
}
+
+   if (dev)
+   dwc_vbus_supply_init(dev);
 }
 
 /*
@@ -1048,7 +1076,7 @@ int _submit_int_msg(struct dwc2_priv *priv, struct 
usb_device *dev,
}
 }
 
-static int dwc2_init_common(struct dwc2_priv *priv)
+static int dwc2_init_common(struct udevice *dev, struct dwc2_priv *priv)
 {
struct dwc2_core_regs *regs = priv->regs;
uint32_t snpsid;
@@ -1070,7 +1098,7 @@ static int dwc2_init_common(struct dwc2_priv *priv)
 #endif
 
dwc_otg_core_init(priv);
-   dwc_otg_core_host_init(regs);
+   dwc_otg_core_host_init(dev, regs);
 
clrsetbits_le32(>hprt0, DWC2_HPRT0_PRTENA |
DWC2_HPRT0_PRTCONNDET | DWC2_HPRT0_PRTENCHNG |
@@ -1143,7 +1171,7 @@ int usb_lowlevel_init(int index, enum usb_init_type init, 
void **controller)
if (board_usb_init(index, USB_INIT_HOST))
return -1;
 
-   return dwc2_init_common(priv);
+   return dwc2_init_common(NULL, priv);
 }
 
 int usb_lowlevel_stop(int index)
@@ -1194,6 +1222,7 @@ static int dwc2_usb_ofdata_to_platdata(struct udevice 
*dev)
const void *prop;
fdt_addr_t addr;
 
+   g_dwc2_udev = dev;
addr = dev_get_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
@@ -1214,7 +1243,7 @@ static int dwc2_usb_probe(struct udevice *dev)
 
bus_priv->desc_before_addr = true;
 
-   return dwc2_init_common(priv);
+   return dwc2_init_common(dev, priv);
 }
 
 static int dwc2_usb_remove(struct udevice *dev)
-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] [PATCH 02/24] sun6i: Restrict some register initialization to Allwinner A31 SoC

[André Przywara]

On 24/11/16 10:18, Andre Przywara wrote:
> Hi,
> 
> On 24/11/16 03:01, Siarhei Siamashka wrote:
>> On Sun, 20 Nov 2016 14:56:56 +
>> Andre Przywara  wrote:
>>
>>> These days many Allwinner SoCs use clock_sun6i.c, although out of them
>>> only the (original sun6i) A31 has a second MBUS clock register.
>>> Also setting up the PRCM PLL_CTLR1 register to provide the proper voltage
>>> seems to be an A31-only feature as well.
>>> So restrict the initialization to this SoC only to avoid writing bogus
>>> values to (undefined) registers in other chips.
>>>
>>> Signed-off-by: Andre Przywara 
>>> Reviewed-by: Alexander Graf 
>>> Reviewed-by: Chen-Yu Tsai 
>>> ---
>>>  arch/arm/mach-sunxi/clock_sun6i.c | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-sunxi/clock_sun6i.c 
>>> b/arch/arm/mach-sunxi/clock_sun6i.c
>>> index ed8cd9b..382fa94 100644
>>> --- a/arch/arm/mach-sunxi/clock_sun6i.c
>>> +++ b/arch/arm/mach-sunxi/clock_sun6i.c
>>> @@ -21,6 +21,8 @@ void clock_init_safe(void)
>>>  {
>>> struct sunxi_ccm_reg * const ccm =
>>> (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
>>> +
>>> +#ifdef CONFIG_MACH_SUN6I
>>> struct sunxi_prcm_reg * const prcm =
>>> (struct sunxi_prcm_reg *)SUNXI_PRCM_BASE;
>>>  
>>> @@ -31,6 +33,7 @@ void clock_init_safe(void)
>>> PRCM_PLL_CTRL_LDO_DIGITAL_EN | PRCM_PLL_CTRL_LDO_ANALOG_EN |
>>> PRCM_PLL_CTRL_EXT_OSC_EN | PRCM_PLL_CTRL_LDO_OUT_L(1140));
>>> clrbits_le32(>pll_ctrl1, PRCM_PLL_CTRL_LDO_KEY_MASK);
>>> +#endif
>>
>> PRCM is generally poorly documented, with its description sometimes
>> entirely missing from the Allwinner manuals (while it exists in the
>> hardware). But many SoC variants are sharing the same features and need
>> the same code. I can confirm that this code chunk is needed on my A31s
>> tablet (otherwise the system does not boot), so it was not entirely
>> useless.
> 
> Sure, in fact I was hoping for people to holler if it breaks their board.
> 
>> What about the other SoC variants? For example, I can see that the
>> A23 manual documents this register in a roughly the same way as A31
>> (the PLLVDD voltage settings, etc.). But I don't have any A23 hardware
>> to test. Basically, are we sure that we will not break A23 support
>> with this commit?
>>
>> If I understand it correctly, you primarily wanted to disable this
>> code on A64. But disabling it everywhere other than A31 may be a
>> bit too broad.
> 
> Well, my impression was that this code was added for the A31, and just
> called clock_sun6i.c because it made sense at this time. Later on people
> just re-used the _clock_ code because the clocks are compatible, but
> missed this one - which cares about a regulator, really.
> So if people can come up with a list of Socs that need this, I am happy
> to add this to the #ifdef. I just had the impression that boards with
> AXPs or I2C regulators don't need this.

I now realized that this PLL voltage is obviously generated by an
internal regulator, based on the externally provided PLL-Vcc.
So in fact this register seems still be valid, even for newer SoCs.
But at least for the H2, A64 and H5 I tested this on, the reset value
(or the value set by BROM) is exactly 0x00070007, which is what we write
here.
I think U-Boot shouldn't care about writing those registers if that's
the reset value anyway, especially if that happens with a widely used
CONFIG symbol.
So I will change that #ifdef to just spare the H3 and A64 for now,
eventually extending this to more chips, with possibly ending at the A31
being the only user.
If any owner of one of those A23, A33, A80 and A83T systems could verify
that it works without this register setup (so with this very patch
applied), I'd be grateful.

The reset(?) value can be checked via FEL by:
$ ./sunxi-fel readl 0x01f01444

Cheers,
Andre.


> 
>>>  
>>> clock_set_pll1(40800);
>>>  
>>> @@ -41,7 +44,9 @@ void clock_init_safe(void)
>>> writel(AHB1_ABP1_DIV_DEFAULT, >ahb1_apb1_div);
>>>  
>>> writel(MBUS_CLK_DEFAULT, >mbus0_clk_cfg);
>>> +#ifdef CONFIG_MACH_SUN6I
>>> writel(MBUS_CLK_DEFAULT, >mbus1_clk_cfg);
>>> +#endif
>>
>> We can change this to:
>>
>>if (IS_ENABLED(CONFIG_MACH_SUN6I))
>>writel(MBUS_CLK_DEFAULT, >mbus1_clk_cfg);
>>
>> This saves one line of code and also looks a bit less ugly.
> 
> Is there some "official" rationale for using IS_ENABLED vs. #ifdef? As
> much as I dislike this massive usage of #ifdefs, at least it gives me
> clear heads up that this code may not be compiled in, which can more
> easily be missed with IS_ENABLED.
> But I don't have a strong opinion on this, so happy to change it.
> 
> Cheers,
> Andre.
> 

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

[U-Boot] [PATCH 08/11] powerpc: mpc85xx: Move CONFIG_FSL_LAW to Kconfig

[York Sun]

Some header files have this macro defined conditionally and
redefined unconditionally. Remove all existing definitions.

Signed-off-by: York Sun 
---

 arch/powerpc/cpu/mpc85xx/Kconfig| 42 +
 include/configs/B4860QDS.h  |  3 ---
 include/configs/BSC9131RDB.h|  1 -
 include/configs/BSC9132QDS.h|  1 -
 include/configs/C29XPCIE.h  |  1 -
 include/configs/MPC8536DS.h |  1 -
 include/configs/MPC8540ADS.h|  1 -
 include/configs/MPC8541CDS.h|  2 --
 include/configs/MPC8544DS.h |  2 --
 include/configs/MPC8548CDS.h|  1 -
 include/configs/MPC8555CDS.h|  1 -
 include/configs/MPC8560ADS.h|  1 -
 include/configs/MPC8568MDS.h|  1 -
 include/configs/MPC8569MDS.h|  1 -
 include/configs/MPC8572DS.h |  2 --
 include/configs/P1010RDB.h  |  3 ---
 include/configs/P1022DS.h   |  4 
 include/configs/P1023RDB.h  |  1 -
 include/configs/P2041RDB.h  |  2 --
 include/configs/T102xQDS.h  |  2 --
 include/configs/T102xRDB.h  |  2 --
 include/configs/T1040QDS.h  |  2 --
 include/configs/T104xRDB.h  |  3 ---
 include/configs/T208xQDS.h  |  2 --
 include/configs/T208xRDB.h  |  2 --
 include/configs/T4240QDS.h  |  1 -
 include/configs/T4240RDB.h  |  3 ---
 include/configs/UCP1020.h   |  2 --
 include/configs/controlcenterd.h|  1 -
 include/configs/corenet_ds.h|  2 --
 include/configs/cyrus.h |  2 --
 include/configs/km/kmp204x-common.h |  2 --
 include/configs/p1_p2_rdb_pc.h  |  3 ---
 include/configs/p1_twr.h|  1 -
 include/configs/sbc8548.h   |  2 --
 include/configs/socrates.h  |  2 --
 include/configs/t4qds.h |  2 --
 include/configs/xpedite520x.h   |  1 -
 include/configs/xpedite537x.h   |  1 -
 include/configs/xpedite550x.h   |  1 -
 40 files changed, 42 insertions(+), 68 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index f782695..ec58cd1 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -323,117 +323,159 @@ endchoice
 
 config ARCH_B4420
bool
+   select FSL_LAW
 
 config ARCH_B4860
bool
+   select FSL_LAW
 
 config ARCH_BSC9131
bool
+   select FSL_LAW
 
 config ARCH_BSC9132
bool
+   select FSL_LAW
 
 config ARCH_C29X
bool
+   select FSL_LAW
 
 config ARCH_MPC8536
bool
+   select FSL_LAW
 
 config ARCH_MPC8540
bool
+   select FSL_LAW
 
 config ARCH_MPC8541
bool
+   select FSL_LAW
 
 config ARCH_MPC8544
bool
+   select FSL_LAW
 
 config ARCH_MPC8548
bool
+   select FSL_LAW
 
 config ARCH_MPC8555
bool
+   select FSL_LAW
 
 config ARCH_MPC8560
bool
+   select FSL_LAW
 
 config ARCH_MPC8568
bool
+   select FSL_LAW
 
 config ARCH_MPC8569
bool
+   select FSL_LAW
 
 config ARCH_MPC8572
bool
+   select FSL_LAW
 
 config ARCH_P1010
bool
+   select FSL_LAW
 
 config ARCH_P1011
bool
+   select FSL_LAW
 
 config ARCH_P1020
bool
+   select FSL_LAW
 
 config ARCH_P1021
bool
+   select FSL_LAW
 
 config ARCH_P1022
bool
+   select FSL_LAW
 
 config ARCH_P1023
bool
+   select FSL_LAW
 
 config ARCH_P1024
bool
+   select FSL_LAW
 
 config ARCH_P1025
bool
+   select FSL_LAW
 
 config ARCH_P2020
bool
+   select FSL_LAW
 
 config ARCH_P2041
bool
+   select FSL_LAW
 
 config ARCH_P3041
bool
+   select FSL_LAW
 
 config ARCH_P4080
bool
+   select FSL_LAW
 
 config ARCH_P5020
bool
+   select FSL_LAW
 
 config ARCH_P5040
bool
+   select FSL_LAW
 
 config ARCH_QEMU_E500
bool
 
 config ARCH_T1023
bool
+   select FSL_LAW
 
 config ARCH_T1024
bool
+   select FSL_LAW
 
 config ARCH_T1040
bool
+   select FSL_LAW
 
 config ARCH_T1042
bool
+   select FSL_LAW
 
 config ARCH_T2080
bool
+   select FSL_LAW
 
 config ARCH_T2081
bool
+   select FSL_LAW
 
 config ARCH_T4160
bool
+   select FSL_LAW
 
 config ARCH_T4240
bool
+   select FSL_LAW
+
+config FSL_LAW
+   bool
+   help
+   Use Freescale common code for Local Access Window
 
 config SECURE_BOOT
bool"Secure Boot"
diff --git a/include/configs/B4860QDS.h b/include/configs/B4860QDS.h
index cd4333f..7d3ebf3 100644
--- a/include/configs/B4860QDS.h
+++ b/include/configs/B4860QDS.h
@@ -19,7 +19,6 @@
 #else
 #define CONFIG_SPL_FLUSH_IMAGE
 #define CONFIG_SPL_TARGET  "u-boot-with-spl.bin"
-#define CONFIG_FSL_LAW /* Use common FSL init code */
 #define CONFIG_SYS_TEXT_BASE   

[U-Boot] [PATCH 00/11] Convert several macros to Kconfig

[York Sun]

Convert the following macros for mpc85xx/mpc86xx to Kconfig options
CONFIG_SYS_CCSRBAR_DEFAULT
CONFIG_SECURE_BOOT
CONFIG_FSL_LAW
CONFIG_SYS_FSL_NUM_LAWS

For consistency, CONFIG_SECURE_BOOT for ls1021a/ls2080a/ls1043a is
also converted.

Related macros are dropped from white list.


York Sun (11):
  powerpc: cyrus: Separate P5020/P5040 config options
  powerpc: mpc85xx: Convert CONFIG_SYS_CCSRBAR_DEFAULT to Kconfig option
  powerpc: mpc86xx: Convert CONFIG_SYS_CCSRBAR_DEFAULT to Kconfig option
  script: remove CONFIG_SYS_CCSRBAR_DEFAULT from white list
  armv7: ls1021a: Move SECURE_BOOT option to Kconfig
  armv8: fsl-layerscape: Move SECURE_BOOT to Kconfig
  powerpc: mpc85xx: Move SECURE_BOOT to Kconfig
  powerpc: mpc85xx: Move CONFIG_FSL_LAW to Kconfig
  powerpc: mpc86xx: Move CONFIG_FSL_LAW to Kconfig
  powerpc: mpc85xx: Convert CONFIG_SYS_FSL_NUM_LAWS to Kconfig option
  powerpc: mpc86xx: Convert CONFIG_SYS_FSL_NUM_LAWS to Kconfig option

 arch/arm/cpu/armv7/ls102xa/Kconfig |   6 +
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |   5 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |   1 -
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   4 +-
 arch/powerpc/cpu/mpc85xx/Kconfig   | 156 -
 arch/powerpc/cpu/mpc86xx/Kconfig   |  22 +++
 arch/powerpc/include/asm/config_mpc85xx.h  |  73 --
 arch/powerpc/include/asm/config_mpc86xx.h  |  12 --
 board/varisys/cyrus/Kconfig|   2 +-
 configs/B4860QDS_SECURE_BOOT_defconfig |   2 +-
 configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig |   3 +-
 configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig |   3 +-
 configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig  |   3 +-
 configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig  |   3 +-
 .../BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig   |   3 +-
 .../BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig   |   3 +-
 .../BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig |   3 +-
 .../BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig |   3 +-
 configs/C29XPCIE_NOR_SECBOOT_defconfig |   2 +-
 configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig|   3 +-
 configs/Cyrus_P5020_defconfig  |   4 +-
 configs/Cyrus_P5040_defconfig  |   4 +-
 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig   |   3 +-
 configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig|   2 +-
 .../P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig   |   3 +-
 configs/P1010RDB-PA_NAND_SECBOOT_defconfig |   3 +-
 configs/P1010RDB-PA_NOR_SECBOOT_defconfig  |   2 +-
 configs/P1010RDB-PA_SPIFLASH_SECBOOT_defconfig |   3 +-
 configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig   |   3 +-
 configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig|   2 +-
 .../P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig   |   3 +-
 configs/P1010RDB-PB_NAND_SECBOOT_defconfig |   3 +-
 configs/P1010RDB-PB_NOR_SECBOOT_defconfig  |   2 +-
 configs/P1010RDB-PB_SPIFLASH_SECBOOT_defconfig |   3 +-
 configs/P2041RDB_SECURE_BOOT_defconfig |   2 +-
 configs/P3041DS_NAND_SECURE_BOOT_defconfig |   3 +-
 configs/P3041DS_SECURE_BOOT_defconfig  |   2 +-
 configs/P4080DS_SECURE_BOOT_defconfig  |   2 +-
 configs/P5020DS_NAND_SECURE_BOOT_defconfig |   3 +-
 configs/P5020DS_SECURE_BOOT_defconfig  |   2 +-
 configs/P5040DS_NAND_SECURE_BOOT_defconfig |   3 +-
 configs/P5040DS_SECURE_BOOT_defconfig  |   2 +-
 configs/T1023RDB_SECURE_BOOT_defconfig |   3 +-
 configs/T1024QDS_DDR4_SECURE_BOOT_defconfig|   3 +-
 configs/T1024QDS_SECURE_BOOT_defconfig |   2 +-
 configs/T1024RDB_SECURE_BOOT_defconfig |   3 +-
 configs/T1040D4RDB_SECURE_BOOT_defconfig   |   3 +-
 configs/T1040QDS_SECURE_BOOT_defconfig |   2 +-
 configs/T1040RDB_SECURE_BOOT_defconfig |   2 +-
 configs/T1042D4RDB_SECURE_BOOT_defconfig   |   3 +-
 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig |   3 +-
 configs/T1042RDB_SECURE_BOOT_defconfig |   2 +-
 configs/T2080QDS_SECURE_BOOT_defconfig |   2 +-
 configs/T2080RDB_SECURE_BOOT_defconfig |   2 +-
 configs/T4160QDS_SECURE_BOOT_defconfig |   2 +-
 configs/T4240QDS_SECURE_BOOT_defconfig |   2 +-
 configs/ls1021aqds_nor_SECURE_BOOT_defconfig   |   2 +-
 configs/ls1021atwr_nor_SECURE_BOOT_defconfig   |   2 +-
 .../ls1021atwr_sdcard_ifc_SECURE_BOOT_defconfig|   3 +-
 configs/ls1043ardb_SECURE_BOOT_defconfig   |   2 +-
 configs/ls2080aqds_SECURE_BOOT_defconfig   |   3 +-
 configs/ls2080ardb_SECURE_BOOT_defconfig   |   3 +-
 doc/README.ramboot-ppc85xx |   4 +-
 include/configs/B4860QDS.h |   3 -
 include/configs/BSC9131RDB.h   |   1 -
 include/configs/BSC9132QDS.h   |  

[U-Boot] build uboot error

[Wenming Feng]

Hi fellows,

When I build uboot for my imx6 wandboard.
I got toolchain error, please see detailed below. Previously I can build the 
uboot month ago.

arch/arm/imx-common/built-in.o: In function `print_cpuinfo':
/home/lucid/imx6dl/uboot-imx/arch/arm/imx-common/cpu.c:199: undefined reference 
to `uclass_get_device'
/home/lucid/imx6dl/uboot-imx/arch/arm/imx-common/cpu.c:201: undefined reference 
to `thermal_get_temp'
arch/arm/imx-common/built-in.o: In function `arch_preboot_os':
/home/lucid/imx6dl/uboot-imx/arch/arm/imx-common/cpu.c:270: undefined reference 
to `ldo_mode_set'
drivers/built-in.o: In function `read_cpu_temperature':
/home/lucid/imx6dl/uboot-imx/drivers/thermal/imx_thermal.c:43: undefined 
reference to `dev_get_platdata'
/home/lucid/imx6dl/uboot-imx/drivers/thermal/imx_thermal.c:45: undefined 
reference to `dev_get_priv'
drivers/built-in.o: In function `imx_thermal_probe':
/home/lucid/imx6dl/uboot-imx/drivers/thermal/imx_thermal.c:226: undefined 
reference to `dev_get_platdata'
/home/lucid/imx6dl/uboot-imx/drivers/thermal/imx_thermal.c:227: undefined 
reference to `dev_get_priv'
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: BFD (GNU Binutils for Ubuntu) 2.24 assertion fail 
../../bfd/elf32-arm.c:7696
arm-linux-gnueabihf-ld.bfd: error: required section '.rel.plt' not found in the 
linker script
arm-linux-gnueabihf-ld.bfd: final link failed: Invalid operation
make: *** [u-boot] Error 1

Thanks!
Wenming



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

Re: [U-Boot] Please assign custodian for: u-boot-pmic / maintainers for: Samsung boards

[Simon Glass]

Hi,

On 1 December 2016 at 01:43, Lukasz Majewski  wrote:
> Hi Jaehoon, Simon,
>
>> On 12/01/2016 11:19 AM, Simon Glass wrote:
>> > Hi Przemyslaw,
>> >
>> > On 30 November 2016 at 06:27, Przemyslaw Marczak
>> >  wrote:
>> >>
>> >> Hello,
>> >>
>> >> During the last year I was assigned to an internal project, and I
>> >> haven't time for an Open Source activity, so I was quite inactive
>> >> on U-Boot list.
>> >
>> > I wondered where you went!
>> >
>> >>
>> >> I finish work today at Samsung, so my e-mail address will become
>> >> inactive. My new work is not related with Open Source activity.
>> >>
>> >> I was maintaining three boards:
>> >> ./board/samsung/smdk5420/MAINTAINERS
>> >> ./board/samsung/universal_c210/MAINTAINERS
>> >> ./board/samsung/odroid/MAINTAINERS
>> >>
>> >> Lukasz Majewski will maintain Odroid-XU3 (smdk5420), Lukasz please
>> >> send the patch with this change.
>> >>
>> >> Yaehoon, I thing that you are the right person for the C210/Odroid
>> >> U3 boards, since you put a lot of work in Samsung's boards code at
>> >> all.
>>
>> You means Yaehoon is me? :) Yes, i can maintain the C210/Odroid U3
>> board..also XU3, all Samsung boards.
>
> Then we are done here :-)
>
>>
>> >>
>> >> I also had PMIC tree in U-Boot, but I haven't time to maintain it.
>> >>
>> >> Simon, you put a big effort into PMIC framework, and also last
>> >> year, you reviewed a lot of code for PMIC drivers. Are you
>> >> interested to take the PMIC tree as one of your working sub-tree?
>> >>
>> >> Tom, if Simon accept this proposition, then can you please remove
>> >> the PMIC tree from the git server?
>> >
>> > That is OK with me for the moment - it can be done as part of DM.
>> > Your PMIC framework has proven to work well and they have not been
>> > any major changes, so I think it is a fairly light load.
>> >
>> > Tom if you know anyone interested in this please let me know.
>>
>> Well, if it's possible, i have interesting for pmic..(Even though i
>> didn't contribute anything for pmic. :/ ) Because i have also worked
>> on pmic for Samsung project with my colleague.
>
> I think that you would be a perfect match.

Sounds good to me, thanks.

>
>>
>> >
>> >>
>> >> Thank you all for cooperation!
>> >
>> > Thank you, and best wishes for your new role.
>>
>> Wishes you all the best in new role. Przemyslaw!
>
> It's a pity that you are leaving the community. Best wishes.
>
> Best regards,
> Łukasz Majewski
>
>>
>> Best Regards,
>> Jaehoon Chung
>>
>> >>
>> >> Best regards,
>> >> --
>> >> Przemyslaw Marczak
>> >> Samsung R Institute Poland
>> >> Samsung Electronics
>> >> p.marc...@samsung.com

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

Re: [U-Boot] [PATCH v3] rtc: Add RTC chip pcf2127 support

[Simon Glass]

On 30 November 2016 at 20:57, Meng Yi  wrote:
> This driver just implemented rtc_get and rtc_set function for
> the compatibility of pcf2127 and pcf2129, and didn't make use
> of pcf2127's 512 bytes of general-purpose static RAM since
> pcf2129 don't have any static RAM.
>
> Signed-off-by: Meng Yi 
> ---
> change in V3:
> -fix coding style and return value check
> change in V2:
> -convert to using u-boot driver module
> ---
>  drivers/rtc/Kconfig   |  10 +
>  drivers/rtc/Makefile  |   1 +
>  drivers/rtc/pcf2127.c | 109 
> ++
>  3 files changed, 120 insertions(+)
>  create mode 100644 drivers/rtc/pcf2127.c

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 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

On 2 December 2016 at 15:41, Tom Rini  wrote:
> On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:
>
>> I've been working with Soby Mathew to get U-Boot booting on ARM's
>> AEMv8 FVP model in Aarch32 mode.
>>
>> Soby worked out what needed to be changed and I'm refining the changes
>> into patches that can be built for both Aarch64 and Aarch32 mode.
>>
>> There are two patches for discussion:
>>
>> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
>> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
>>
>> I expect the first patch to be controversial.  I also don't expect it to
>> be accepted, but to demonstrate what changes we needed to make to get an
>> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
>> ARM64 as the CPU type.  This in itself may be the wrong approach.
>>
>> It adds an ARMV8_AARCH32 config option and some checks in generic code
>> for that option to allow the code to differentiate between the two
>> modes.
>>
>> The second patch should be less controversial.  It adds support for a
>> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
>> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
>> change based on feedback from patch 1/2.
>>
>> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
>> takes an extra per-core model launch parameter to switch the cores into
>> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
>
> So my first and slightly ignorant question is, why isn't this just a new
> regular ARMv7 board being added rather than a special cased ARMv8?
>

That's a valid question.

I guess it could be either.  At the moment, it's a bit of both.
arch/arm/Kconfig says it's an ARMv7, but then it's added to
board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.

But there's no reason it couldn't be added to
board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
isn't special cased at all.  That approach seems more copy/paste-y
than what I've done in this series, though.

I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
confused.  Really, all of these armlt boards are the same with minor
variations, even if the minor variation could be ARMv7 vs ARMv8.

I'd quite like to address that, but I'm unsure how to approach the
problem in the most flexible way.


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

Re: [U-Boot] [PATCH] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Jyri Sarha]

On 12/02/16 15:06, Jyri Sarha wrote:
>>> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
>>> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>>> >> index 43e122e..c71cfd0 100644
>>> >> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>>> >> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>>> >> @@ -25,6 +25,14 @@
>>> >>  #endif
>>> >>  #define PHY_EN_DYN_PWRDN(0x1 << 20)
>>> >>  
>>> >> +/**
>>> >> + * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
>>> >> + * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
>>> >> + * Synchronization Lost errors.
>>> >> + */
>>> >> +#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK0x00141414
>>> >> +#define EMIF_OCP_CONFIG_AM335X_EVM  0x003d3d3d
>> > 
>> > OK, but the problems I see are that first we don't explain what these
>> > values are tied to physically.  Is it the display? The DDR memory?
> It is a combination of both. I'll add that to the comment.
> 
>> > Second, since these are board specific they should be in
>> > board/ti/am335x/board.h.  Thanks!
>> > 
> Ok, I'll move the defines there.

H, there there are no defined constants in board/ti/am335x/board.h.
Should I just put the constants above, with improved comment, somewhere
in that file?

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

Re: [U-Boot] [GIT PULL] Xilinx and SCSI changes

[Michal Simek]

Hi,

On 2.12.2016 15:12, Tom Rini wrote:
> On Fri, Dec 02, 2016 at 02:55:00PM +0100, Michal Simek wrote:
> 
>> Hi Tom,
>>
>> here are some patches I have collected for Xilinx devices, one miiphy
>> patch and SCSI changes I have made.
>>
>> Simon: I have sent v4 of DM_SCSI + ceva sata driver moved to DM which
>> should go through your tree because you have applied
>> "dm: blk: Fix get_desc to return block device descriptor"
>> which is required. They are based on this branch.
>>
>> Tom: I have tested also travis with zynq qemu but it looks like a
>> problem with qemu timing for zynq model. The rest of python tests look
>> good. https://travis-ci.org/michalsimek-test/u-boot/jobs/180384185
>> Also for running this I had to use CONFIG_OF_EMBED=y to handle dtb.
>> Anyway I will talk to Qemu guys what I can do with it and when this
>> timing issue was solved and which mainline qemu version this requires.
>> Is there arm64 qemu available too?
> 
> We have to disable the 'sleep' test on a number of other platforms, you
> just need to add TEST_PY_TEST_SPEC="not sleep"

ok. Will try.

> 
> For the zynq model, can we not use the -dtb argument to qemu?  Or, how
> does the device tree get passed along on the real platform?

I was trying it but it didn't work. Will try again next week and will
refresh my mind on Zynq.

> 
> And, the PPA we currently use only has qemu-2.5 available but I get
> tempted to either do a PPA myself or just throw things up on dropbox of
> a more current release of QEMU, especially if it enabled more platforms
> for us to test.

That will be great. In the latest qemu our guys told me that they have
added loader property that we can load more sw to memory which is one of
the thing which I need for arm64.
Then we can wire zynqmp stuff at least for platform which is supported
in qemu.

Thanks,
Michal




-- 
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs




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

Re: [U-Boot] [PATCH] imx_common: spl: Fix SPL boot from SD card

[Fabio Estevam]

Hi Marcin,

On Fri, Dec 2, 2016 at 12:11 PM, Marcin Niestroj
 wrote:

> Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics
> the SD card is connected to uSDHC2 port, because uSDHC1 is used for
> something else.

Yes, Udoo Neo boots from the SDHC2 port.

However BOOT_DEVICE_MMC1 does not mean "boot from the SDHC1 port".
BOOT_DEVICE_MMC1 just tells SPL to boot from the first registered mmc device.

Please take a look at common/spl/spl_mmc.c

int spl_mmc_get_device_index(u32 boot_device)
{
  switch (boot_device) {
  case BOOT_DEVICE_MMC1:
  return 0;
  case BOOT_DEVICE_MMC2:
  case BOOT_DEVICE_MMC2_2:
return 1;
}

,so we should return BOOT_DEVICE_MMC1 as we always did.

mx6cuboxi is also broken for the same reason.

If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1
port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection
support in SPL") I suggest we need to revert it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 11/11] spi: cadence_qspi: Support specifying the sample edge used

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Introduce a new DT property to specify whether the QSPI Controller
> samples the data on a rising edge. The default is falling edge.
> Some versions of the QSPI Controller do not implement this bit, in
> which case the property should be omitted.
>
> Signed-off-by: Phil Edworthy 
> ---
>  v3:
>   - Patch split so this one only has code related to the subject.
>   - Commit message updated.
>  v2:
>   - Change name of DT prop and provide details of what it does.
> Whilst at it, move the code to read the "sram-size" property
> into the other code that reads properties from the node, rather
> than the SF subnode.
>
> Also change the code to use a bool for the bypass arg.
> ---
>  doc/device-tree-bindings/spi/spi-cadence.txt |  2 ++
>  drivers/spi/cadence_qspi.c   | 10 +++---
>  drivers/spi/cadence_qspi.h   |  3 ++-
>  drivers/spi/cadence_qspi_apb.c   |  8 +++-
>  4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/doc/device-tree-bindings/spi/spi-cadence.txt 
> b/doc/device-tree-bindings/spi/spi-cadence.txt
> index c1e2233..94c800b 100644
> --- a/doc/device-tree-bindings/spi/spi-cadence.txt
> +++ b/doc/device-tree-bindings/spi/spi-cadence.txt
> @@ -26,3 +26,5 @@ connected flash properties
>   select (n_ss_out).
>  - tslch-ns : Delay in master reference clocks between setting
>   n_ss_out low and first bit transfer
> +- sample-edge-rising   : Data outputs from flash memory will be sampled on 
> the
> + rising edge. Default is falling edge.

Code look reasonable, but how Linux handling this with the same dt
property, any idea? I couldn't find it either.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] imx_common: spl: Fix SPL boot from SD card

[Marcin Niestroj]

Hi,

On 30.11.2016 18:12, Breno Lima wrote:

Since commit 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection
support in SPL") we can no longer boot from SD card on a mx6sx Udoo neo board:

U-Boot SPL 2016.11-32108-g9cd37b0 (Nov 30 2016 - 11:05:54)
Trying to boot from MMC2
MMC Device 1 not found
spl: could not find mmc device. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Prior to this commit we had the following logic:

/* SD/eSD: 8.5.3, Table 8-15  */
case 0x4:
case 0x5:
return BOOT_DEVICE_MMC1;
/* MMC/eMMC: 8.5.3 */
case 0x6:
case 0x7:
return BOOT_DEVICE_MMC1;

and in the case of MX6SX Udoo board we entered the case 0x5 (SD card boot)
and returned BOOT_DEVICE_MMC1 as expected.


Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics
the SD card is connected to uSDHC2 port, because uSDHC1 is used for
something else.



Now this does not happen anymore and BOOT_DEVICE_MMC2 is returned, which
breaks the boot.

In order to fix this problem keep the original behavior for the SD card case by
returning BOOT_DEVICE_MMC1.

Tested on mx6cuboxi and mx6sx UDOO neo boards.

Signed-off-by: Breno Lima 
---
 arch/arm/imx-common/spl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/imx-common/spl.c b/arch/arm/imx-common/spl.c
index 325ba26..cbcd936 100644
--- a/arch/arm/imx-common/spl.c
+++ b/arch/arm/imx-common/spl.c
@@ -58,6 +58,7 @@ u32 spl_boot_device(void)
/* SD/eSD: 8.5.3, Table 8-15  */
case 0x4:
case 0x5:
+return BOOT_DEVICE_MMC1;
/* MMC/eMMC: 8.5.3 */
case 0x6:
case 0x7:



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

Re: [U-Boot] Uboot send pull request

[Tom Rini]

On Fri, Dec 02, 2016 at 06:08:53PM +0900, Jaehoon Chung wrote:
> On 12/02/2016 04:44 PM, ub...@andestech.com wrote:
> >  Hi Tom,
> > 
> >  Please pull the following patch from u-boot-nds32 into your tree.
> >  Thanks!
> > 
> > The following changes since commit 9ae0e14350758e6447c90615ff4df530549a45e2:
> > 
> >   Merge git://www.denx.de/git/u-boot-marvell (2016-12-01 09:24:02 -0500)
> > 
> > are available in the git repository at:
> > 
> > 
> >   git://git.denx.de/u-boot-nds32.git master
> > 
> > for you to fetch changes up to 07ce9147e919be25d8928e54b4cd23460ff44a7f:
> > 
> >   nds32: Support eth DM. (2016-12-02 14:46:15 +0800)
> > 
> > 
> > rick (6):
> >   nds32: Support serial DM.
> >   nds32: Support timer DM.
> >   nds32: mmc: Support mmc DM.
> >   nds32: mmc: Support mmc DM.
> >   nds32: mmc: Support mmc DM.
> >   nds32: Support eth DM.
> 
> Even though I don't know how Tom thinks about this PR, I don't agree this PR.
> There are no review and ack about your patches.

Indeed, these were just posted and haven't gotten any review comments
from anyone yet, it's a bit too soon to pull, 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 v2] disk: convert to Kconfig

[Patrick DELAUNAY]

Hi Tom

> 
> > This converts the following to Kconfig:
> >CONFIG_PARTITIONS
> >CONFIG_MAC_PARTITION
> >CONFIG_DOS_PARTITION
> >CONFIG_ISO_PARTITION
> >CONFIG_AMIGA_PARTITION
> >CONFIG_EFI_PARTITION
> >CONFIG_PARTITION_UUIDS
> >CONFIG_PARTITION_TYPE_GUID
> [snip]
> >  606 files changed, 996 insertions(+), 583 deletions(-)
> 
> The insertions to deletions ratio is still high, and I think we can do a 
> little
> better.  Some of this is due to platforms that I fix with
> https://patchwork.ozlabs.org/patch/700546/ and will have the various types
> selected now.  But I think we can still do a little better with defaults too:

I agree that DISTRO_DEFAULT should reduce the update ratio
I wait the distro update and propose my patch on the top of  
https://patchwork.ozlabs.org/patch/700546/ ?
or I continue submission as it ?

> [snip]
> > +config ISO_PARTITION
> > +   bool "Enable ISO partition table"
> > +   depends on PARTITIONS
> 
> This should be default y for x86, along with DOS and MAC.
> 
> > +config SPL_ISO_PARTITION
> > +   bool "Enable ISO partition table for SPL"
> > +   depends on SPL && PARTITIONS
> 
> Here and elsewhere, SPL_xxx_PARTITION should be default y if
> xxx_PARTITION
> 
> > +config PARTITION_UUIDS
> > +   bool "Enable support of UUID for partition"
> > +   help
> > + Activate the configuration of UUID for partition
> 
> I think a lot of these will go away once CMD_GPT and CMD_PART are
> converted to Kconfig, but I don't want to chicken-and-egg this nor have too
> many things in flight at once, so lets put that off until after this series.
> Thanks!

Yes dependency need to be reviewed when all this command will moved to Kconfig

CMD_GPT => select EFI and PARTITION_UUIDS
CMD_PART => select PARTITION_UUIDS

I will propose v3 with reduced ratio (I hope) but it is more complicated 
depends rules :

config MAC_PARTITION
default y if PPC || x86 || SPARC || SH

config SPL_MAC_PARTITION
default y if MAC_PARTITION

config DOS_PARTITION
default y if PPC || x86 || CMD_FAT || USB_STORAGE

config SPL_DOS_PARTITION
default y if DOS_PARTITION

config ISO_PARTITION
default y if M68K || PPC || SPARC || MIPS

config SPL_ISO_PARTITION
default y if ISO_PARTITION

config SPL_AMIGA_PARTITION
default y if AMIGA_PARTITION

config SPL_EFI_PARTITION
default y if EFI_PARTITION

> --
> Tom

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

Re: [U-Boot] qemu and u-boot-console and other ports?

[Stephen Warren]

On 12/02/2016 07:40 AM, Tom Rini wrote:

Hey,

I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
current round of testing is applied you'll need
http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
for us to get a functional U-Boot.  After that, I have a "normal" conf
file for the board for QEMU that looks like:
console_impl=qemu
qemu_machine="r2d"
qemu_binary="qemu-system-sh4"
qemu_extra_args="-nographic -serial null -serial mon:stdio"
qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none

And here's where things get funny.  When I kick off test.py with --bd
r2dplus --id qemu --build -s -k sleep it will build and launch the board
and since I have -s I can see stdio and I see U-Boot come up and give me
the prompt, and then test.py says it times out waiting for the prompt.
Any ideas where to poke next?  I want to say something is funny with
respect to what we see and where we see it (in terms of pipes) due to
having to say -serial null -serial mon:stdio so that we see port #2 on
the "board" rather than port #1 as this is the port that U-Boot and
Linux use by default.  Thanks!


Does "-serial null -serial mon:stdio" cause qemu to re-open file 
descriptors rather than just using stdout directly, or something like 
that? If so, perhaps its output is getting into the overall script's 
stdout (e.g. your terminal/console?) rather than the pipe that test/py 
is reading. If so, you'd see the qemu output but test/py wouldn't.


I think you can test this assumption by removing the -s option. If you 
still see qemu output, then qemu is sending it directly to wherever the 
overall stdout is going. If you no longer see qemu's output, then 
test/py must be reading it and only echo'ing it due to the -s option, 
and so you'd have to look somewhere else.


Is test/py waiting for the exact prompt that U-Boot is actually emitting?

In the past I've debugged such things by editing test/py/u_boot_spawn.py 
expect() to print some debug spew; I made it dump the current unmatched 
buffer content and the strings/regexes it was waiting for.




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

Re: [U-Boot] [PATCH] imx_common: spl: Fix SPL boot from SD card

[Marcin Niestroj]

On 02.12.2016 16:03, Fabio Estevam wrote:

Hi Marcin,

On Fri, Dec 2, 2016 at 12:11 PM, Marcin Niestroj
 wrote:


Why is BOOT_DEVICE_MMC1 expected here? As I see in Udoo neo schematics
the SD card is connected to uSDHC2 port, because uSDHC1 is used for
something else.


Yes, Udoo Neo boots from the SDHC2 port.

However BOOT_DEVICE_MMC1 does not mean "boot from the SDHC1 port".
BOOT_DEVICE_MMC1 just tells SPL to boot from the first registered mmc device.

Please take a look at common/spl/spl_mmc.c

int spl_mmc_get_device_index(u32 boot_device)
{
  switch (boot_device) {
  case BOOT_DEVICE_MMC1:
  return 0;
  case BOOT_DEVICE_MMC2:
  case BOOT_DEVICE_MMC2_2:
return 1;
}

,so we should return BOOT_DEVICE_MMC1 as we always did.

mx6cuboxi is also broken for the same reason.

If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1
port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection
support in SPL") I suggest we need to revert it.



Indeed it was my assumption. I agree it should be reverted then.

So to support booting from two SD/MMC devices one should create
board_boot_order() function? That way BOOT_CFG2[3:4] can be read there
to figure out which MMC1 or MMC2 should be configured as the first boot
device.

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

Re: [U-Boot] qemu and u-boot-console and other ports?

[Stephen Warren]

On 12/02/2016 01:01 PM, Tom Rini wrote:

On Fri, Dec 02, 2016 at 12:21:43PM -0700, Stephen Warren wrote:

On 12/02/2016 12:18 PM, Tom Rini wrote:

On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:

On 12/02/2016 07:40 AM, Tom Rini wrote:

Hey,

I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
current round of testing is applied you'll need
http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
for us to get a functional U-Boot.  After that, I have a "normal" conf
file for the board for QEMU that looks like:
console_impl=qemu
qemu_machine="r2d"
qemu_binary="qemu-system-sh4"
qemu_extra_args="-nographic -serial null -serial mon:stdio"
qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none

And here's where things get funny.  When I kick off test.py with --bd
r2dplus --id qemu --build -s -k sleep it will build and launch the board
and since I have -s I can see stdio and I see U-Boot come up and give me
the prompt, and then test.py says it times out waiting for the prompt.
Any ideas where to poke next?  I want to say something is funny with
respect to what we see and where we see it (in terms of pipes) due to
having to say -serial null -serial mon:stdio so that we see port #2 on
the "board" rather than port #1 as this is the port that U-Boot and
Linux use by default.  Thanks!


Does "-serial null -serial mon:stdio" cause qemu to re-open file
descriptors rather than just using stdout directly, or something
like that? If so, perhaps its output is getting into the overall
script's stdout (e.g. your terminal/console?) rather than the pipe
that test/py is reading. If so, you'd see the qemu output but
test/py wouldn't.

I think you can test this assumption by removing the -s option. If
you still see qemu output, then qemu is sending it directly to
wherever the overall stdout is going. If you no longer see qemu's
output, then test/py must be reading it and only echo'ing it due to
the -s option, and so you'd have to look somewhere else.


When I drop out -s instead I get:
--- Captured stdout 

+u-boot-test-reset r2dplus qemu
long write to SH7750_WCR1_A7 (0x1f88) ignored
long write to SH7750_WCR2_A7 (0x1f8c) ignored
long write to SH7750_WCR3_A7 (0x1f800010) ignored
long write to SH7750_MCR_A7 (0x1f800014) ignored
word write to SH7750_RTCNT_A7 (0x1f800020) ignored
word write to SH7750_RTCOR_A7 (0x1f800024) ignored
Write access to refresh count register
word write to SH7750_RTCSR_A7 (0x1f80001c) ignored
Read access to refresh count register, incrementing
long write to SH7750_MCR_A7 (0x1f800014) ignored


U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)

CPU: SH4
BOARD: Renesas Solutions R2D Plus
DRAM:  64 MiB
Flash: ERROR: too many flash sectors
8 MiB
*** Warning - bad CRC, using default environment

PCI: SH7751 PCI host bridge found.
long read to SH7750_WCR1_A7 (0x1f88) ignored
long read to SH7750_WCR2_A7 (0x1f8c) ignored
long read to SH7750_WCR3_A7 (0x1f800010) ignored
long read to SH7750_MCR_A7 (0x1f800014) ignored
PCI:   Bus Dev VenId DevId Class Int
PCI:
 00:00.0 - 1054:350e - Bridge device
 00:02.0 - 10ec:8139 - Network controller
In:serial
Out:   serial
Err:   serial
Net:   RTL8139#0
Error: RTL8139#0 address not set.

IDE:   Bus 0: not available
=> => s
=== 92 tests deselected by '-ksleep' 
===
=== 1 failed, 92 deselected in 31.20 seconds 
===

So it's seeing output, but for some reason not matching on it?


If you drop -s, you shouldn't see any of U-Boot's output. It looks
like qemu is writing its serial port output to a file descriptor
other than the stdout that's fed to its parent.


Well, it doesn't give me output until it times out and then dumps that.


Oh, you can also confirm this by looking in the test-log.html
generated by test/py; that will show you whether test/py sees qemu's
output at all, since all of qemu's output is logged to that file. I
guess this assumes you're running locally, since Travis doesn't save
that file for you to look at. Perhaps you could cat it after running
test/py though.


I'm not quite sure what I should (not) be seeing,
http://hastebin.com/upimerumaz.xml is the file.  Thanks!


The qemu output is getting into test/py; I see the U-Boot boot output 
all the way up to the first shell prompt.


It looks like some test is attempting to execute a "sleep" command. The 
code sends the command text to the target in chunks and waits for it to 
echo back. The chunk size is 16 characters so I believe would included 
the entire command and trailing \n in this cae. I can see that qemu has 
only echo'd back the first character "s", so I think U-Boot hung and 
stopped responding, or there's some issue getting the 

Re: [U-Boot] [PATCH v2] disk: convert to Kconfig

[Tom Rini]

On Fri, Dec 02, 2016 at 05:23:16PM +, Patrick DELAUNAY wrote:
> Hi Tom
> 
> > 
> > > This converts the following to Kconfig:
> > >CONFIG_PARTITIONS
> > >CONFIG_MAC_PARTITION
> > >CONFIG_DOS_PARTITION
> > >CONFIG_ISO_PARTITION
> > >CONFIG_AMIGA_PARTITION
> > >CONFIG_EFI_PARTITION
> > >CONFIG_PARTITION_UUIDS
> > >CONFIG_PARTITION_TYPE_GUID
> > [snip]
> > >  606 files changed, 996 insertions(+), 583 deletions(-)
> > 
> > The insertions to deletions ratio is still high, and I think we can do a 
> > little
> > better.  Some of this is due to platforms that I fix with
> > https://patchwork.ozlabs.org/patch/700546/ and will have the various types
> > selected now.  But I think we can still do a little better with defaults 
> > too:
> 
> I agree that DISTRO_DEFAULT should reduce the update ratio
> I wait the distro update and propose my patch on the top of  
> https://patchwork.ozlabs.org/patch/700546/ ?
> or I continue submission as it ?

I'm testing 700546 right now so please wait for me to push and merge
that and then do on top of it.

> > [snip]
> > > +config ISO_PARTITION
> > > + bool "Enable ISO partition table"
> > > + depends on PARTITIONS
> > 
> > This should be default y for x86, along with DOS and MAC.
> > 
> > > +config SPL_ISO_PARTITION
> > > + bool "Enable ISO partition table for SPL"
> > > + depends on SPL && PARTITIONS
> > 
> > Here and elsewhere, SPL_xxx_PARTITION should be default y if
> > xxx_PARTITION
> > 
> > > +config PARTITION_UUIDS
> > > + bool "Enable support of UUID for partition"
> > > + help
> > > +   Activate the configuration of UUID for partition
> > 
> > I think a lot of these will go away once CMD_GPT and CMD_PART are
> > converted to Kconfig, but I don't want to chicken-and-egg this nor have too
> > many things in flight at once, so lets put that off until after this series.
> > Thanks!
> 
> Yes dependency need to be reviewed when all this command will moved to Kconfig
> 
> CMD_GPT => select EFI and PARTITION_UUIDS
> CMD_PART => select PARTITION_UUIDS
> 
> I will propose v3 with reduced ratio (I hope) but it is more complicated 
> depends rules :
> 
> config MAC_PARTITION
>   default y if PPC || x86 || SPARC || SH
> 
> config SPL_MAC_PARTITION
>   default y if MAC_PARTITION
> 
> config DOS_PARTITION
>   default y if PPC || x86 || CMD_FAT || USB_STORAGE
> 
> config SPL_DOS_PARTITION
>   default y if DOS_PARTITION
> 
> config ISO_PARTITION
>   default y if M68K || PPC || SPARC || MIPS
> 
> config SPL_ISO_PARTITION
>   default y if ISO_PARTITION
> 
> config SPL_AMIGA_PARTITION
>   default y if AMIGA_PARTITION
> 
> config SPL_EFI_PARTITION
>   default y if EFI_PARTITION

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] qemu and u-boot-console and other ports?

[Tom Rini]

On Fri, Dec 02, 2016 at 12:21:43PM -0700, Stephen Warren wrote:
> On 12/02/2016 12:18 PM, Tom Rini wrote:
> >On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
> >>On 12/02/2016 07:40 AM, Tom Rini wrote:
> >>>Hey,
> >>>
> >>>I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
> >>>current round of testing is applied you'll need
> >>>http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
> >>>for us to get a functional U-Boot.  After that, I have a "normal" conf
> >>>file for the board for QEMU that looks like:
> >>>console_impl=qemu
> >>>qemu_machine="r2d"
> >>>qemu_binary="qemu-system-sh4"
> >>>qemu_extra_args="-nographic -serial null -serial mon:stdio"
> >>>qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
> >>>reset_impl=none
> >>>flash_impl=none
> >>>
> >>>And here's where things get funny.  When I kick off test.py with --bd
> >>>r2dplus --id qemu --build -s -k sleep it will build and launch the board
> >>>and since I have -s I can see stdio and I see U-Boot come up and give me
> >>>the prompt, and then test.py says it times out waiting for the prompt.
> >>>Any ideas where to poke next?  I want to say something is funny with
> >>>respect to what we see and where we see it (in terms of pipes) due to
> >>>having to say -serial null -serial mon:stdio so that we see port #2 on
> >>>the "board" rather than port #1 as this is the port that U-Boot and
> >>>Linux use by default.  Thanks!
> >>
> >>Does "-serial null -serial mon:stdio" cause qemu to re-open file
> >>descriptors rather than just using stdout directly, or something
> >>like that? If so, perhaps its output is getting into the overall
> >>script's stdout (e.g. your terminal/console?) rather than the pipe
> >>that test/py is reading. If so, you'd see the qemu output but
> >>test/py wouldn't.
> >>
> >>I think you can test this assumption by removing the -s option. If
> >>you still see qemu output, then qemu is sending it directly to
> >>wherever the overall stdout is going. If you no longer see qemu's
> >>output, then test/py must be reading it and only echo'ing it due to
> >>the -s option, and so you'd have to look somewhere else.
> >
> >When I drop out -s instead I get:
> >--- Captured stdout 
> >
> >+u-boot-test-reset r2dplus qemu
> >long write to SH7750_WCR1_A7 (0x1f88) ignored
> >long write to SH7750_WCR2_A7 (0x1f8c) ignored
> >long write to SH7750_WCR3_A7 (0x1f800010) ignored
> >long write to SH7750_MCR_A7 (0x1f800014) ignored
> >word write to SH7750_RTCNT_A7 (0x1f800020) ignored
> >word write to SH7750_RTCOR_A7 (0x1f800024) ignored
> >Write access to refresh count register
> >word write to SH7750_RTCSR_A7 (0x1f80001c) ignored
> >Read access to refresh count register, incrementing
> >long write to SH7750_MCR_A7 (0x1f800014) ignored
> >
> >
> >U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)
> >
> >CPU: SH4
> >BOARD: Renesas Solutions R2D Plus
> >DRAM:  64 MiB
> >Flash: ERROR: too many flash sectors
> >8 MiB
> >*** Warning - bad CRC, using default environment
> >
> >PCI: SH7751 PCI host bridge found.
> >long read to SH7750_WCR1_A7 (0x1f88) ignored
> >long read to SH7750_WCR2_A7 (0x1f8c) ignored
> >long read to SH7750_WCR3_A7 (0x1f800010) ignored
> >long read to SH7750_MCR_A7 (0x1f800014) ignored
> >PCI:   Bus Dev VenId DevId Class Int
> >PCI:
> >  00:00.0 - 1054:350e - Bridge device
> >  00:02.0 - 10ec:8139 - Network controller
> >In:serial
> >Out:   serial
> >Err:   serial
> >Net:   RTL8139#0
> >Error: RTL8139#0 address not set.
> >
> >IDE:   Bus 0: not available
> >=> => s
> >=== 92 tests deselected by '-ksleep' 
> >===
> >=== 1 failed, 92 deselected in 31.20 seconds 
> >===
> >
> >So it's seeing output, but for some reason not matching on it?
> 
> If you drop -s, you shouldn't see any of U-Boot's output. It looks
> like qemu is writing its serial port output to a file descriptor
> other than the stdout that's fed to its parent.

Well, it doesn't give me output until it times out and then dumps that.

> Oh, you can also confirm this by looking in the test-log.html
> generated by test/py; that will show you whether test/py sees qemu's
> output at all, since all of qemu's output is logged to that file. I
> guess this assumes you're running locally, since Travis doesn't save
> that file for you to look at. Perhaps you could cat it after running
> test/py though.

I'm not quite sure what I should (not) be seeing,
http://hastebin.com/upimerumaz.xml is the file.  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] [U-Boot,1/4] env_sf: factor out prepare_flash_device

[Tom Rini]

On Mon, Nov 28, 2016 at 11:01:14AM +0100, Andreas Fenkart wrote:

> copy code found in single/double buffered code path
> 
> Signed-off-by: Andreas Fenkart 
> Reviewed-by: Simon Glass 

Please test build this series on all platforms (perhaps via travis-ci)
as this breaks on ls1012afrdm_qspi and others, 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] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Tom Rini]

On Fri, Dec 02, 2016 at 06:24:49PM +0200, Jyri Sarha wrote:
> On 12/02/16 15:06, Jyri Sarha wrote:
> >>> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
> >>> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> >>> >> index 43e122e..c71cfd0 100644
> >>> >> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> >>> >> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
> >>> >> @@ -25,6 +25,14 @@
> >>> >>  #endif
> >>> >>  #define PHY_EN_DYN_PWRDN  (0x1 << 20)
> >>> >>  
> >>> >> +/**
> >>> >> + * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
> >>> >> + * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
> >>> >> + * Synchronization Lost errors.
> >>> >> + */
> >>> >> +#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK  0x00141414
> >>> >> +#define EMIF_OCP_CONFIG_AM335X_EVM0x003d3d3d
> >> > 
> >> > OK, but the problems I see are that first we don't explain what these
> >> > values are tied to physically.  Is it the display? The DDR memory?
> > It is a combination of both. I'll add that to the comment.
> > 
> >> > Second, since these are board specific they should be in
> >> > board/ti/am335x/board.h.  Thanks!
> >> > 
> > Ok, I'll move the defines there.
> 
> H, there there are no defined constants in board/ti/am335x/board.h.
> Should I just put the constants above, with improved comment, somewhere
> in that file?

Yes, 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] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Tom Rini]

On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote:
> On 2 December 2016 at 15:41, Tom Rini  wrote:
> > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:
> >
> >> I've been working with Soby Mathew to get U-Boot booting on ARM's
> >> AEMv8 FVP model in Aarch32 mode.
> >>
> >> Soby worked out what needed to be changed and I'm refining the changes
> >> into patches that can be built for both Aarch64 and Aarch32 mode.
> >>
> >> There are two patches for discussion:
> >>
> >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
> >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
> >>
> >> I expect the first patch to be controversial.  I also don't expect it to
> >> be accepted, but to demonstrate what changes we needed to make to get an
> >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
> >> ARM64 as the CPU type.  This in itself may be the wrong approach.
> >>
> >> It adds an ARMV8_AARCH32 config option and some checks in generic code
> >> for that option to allow the code to differentiate between the two
> >> modes.
> >>
> >> The second patch should be less controversial.  It adds support for a
> >> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
> >> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
> >> change based on feedback from patch 1/2.
> >>
> >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
> >> takes an extra per-core model launch parameter to switch the cores into
> >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
> >
> > So my first and slightly ignorant question is, why isn't this just a new
> > regular ARMv7 board being added rather than a special cased ARMv8?
> >
> 
> That's a valid question.
> 
> I guess it could be either.  At the moment, it's a bit of both.
> arch/arm/Kconfig says it's an ARMv7, but then it's added to
> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
> 
> But there's no reason it couldn't be added to
> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
> isn't special cased at all.  That approach seems more copy/paste-y
> than what I've done in this series, though.
> 
> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
> confused.  Really, all of these armlt boards are the same with minor
> variations, even if the minor variation could be ARMv7 vs ARMv8.

Maybe this gets to the heart of the problem then, and we should
re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
support rpi1 2 and 3, and that includes rpi3 in 64bit mode.  So if we
want to re-work board/armlt/vexpress/ to support the various ways the
base hardware can be (/ has been over the years), lets.  Does that sound
like a plan?

-- 
Tom


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

[U-Boot] qemu and u-boot-console and other ports?

[Tom Rini]

Hey,

I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
current round of testing is applied you'll need
http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
for us to get a functional U-Boot.  After that, I have a "normal" conf
file for the board for QEMU that looks like:
console_impl=qemu
qemu_machine="r2d"
qemu_binary="qemu-system-sh4"
qemu_extra_args="-nographic -serial null -serial mon:stdio"
qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none

And here's where things get funny.  When I kick off test.py with --bd
r2dplus --id qemu --build -s -k sleep it will build and launch the board
and since I have -s I can see stdio and I see U-Boot come up and give me
the prompt, and then test.py says it times out waiting for the prompt.
Any ideas where to poke next?  I want to say something is funny with
respect to what we see and where we see it (in terms of pipes) due to
having to say -serial null -serial mon:stdio so that we see port #2 on
the "board" rather than port #1 as this is the port that U-Boot and
Linux use by default.  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] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Tom Rini]

On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:

> I've been working with Soby Mathew to get U-Boot booting on ARM's
> AEMv8 FVP model in Aarch32 mode.
> 
> Soby worked out what needed to be changed and I'm refining the changes
> into patches that can be built for both Aarch64 and Aarch32 mode.
> 
> There are two patches for discussion:
> 
> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
> 
> I expect the first patch to be controversial.  I also don't expect it to 
> be accepted, but to demonstrate what changes we needed to make to get an 
> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
> ARM64 as the CPU type.  This in itself may be the wrong approach.
> 
> It adds an ARMV8_AARCH32 config option and some checks in generic code 
> for that option to allow the code to differentiate between the two
> modes.
> 
> The second patch should be less controversial.  It adds support for a
> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
> change based on feedback from patch 1/2.
> 
> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but 
> takes an extra per-core model launch parameter to switch the cores into
> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".

So my first and slightly ignorant question is, why isn't this just a new
regular ARMv7 board being added rather than a special cased ARMv8?

-- 
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 04/14] net: core: Sanitize get/set operations for enetaddr

[Olliver Schinagl]

Hey Joe,


On 30-11-16 20:20, Joe Hershberger wrote:

On Fri, Nov 25, 2016 at 9:30 AM, Olliver Schinagl  wrote:

In the current net stack, we have a few functions to get and set
the "ethaddr" and "ethNaddr" environment variables, which use magic
values to get and set these environment variables. Remove the magicness
of the buffer by defining it proper and also check the input for its
length.

Additionally use the define in fdt parser where the ethaddr variables
are also used.

Signed-off-by: Olliver Schinagl 
---
  common/fdt_support.c |  2 +-
  include/net.h|  1 +
  net/eth_common.c | 12 
  3 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index b082662..89e6e47 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -469,7 +469,7 @@ void fdt_fixup_ethernet(void *fdt)
  {
 int i, j, prop;
 char *tmp, *end;
-   char mac[16];
+   char mac[ETH_ENETADDR_LEN];
 const char *path;
 unsigned char mac_addr[ARP_HLEN];
 int offset;
diff --git a/include/net.h b/include/net.h
index 9cd7870..2534913 100644
--- a/include/net.h
+++ b/include/net.h
@@ -243,6 +243,7 @@ void eth_set_current(void); /* set nterface to 
ethcur var */

  int eth_get_dev_index(void);   /* get the device index */
  void eth_parse_enetaddr(const char *addr, uchar *enetaddr);
+#define ETH_ENETADDR_LEN 32

I'd prefer a clearer name here.

I'd agree, but


Maybe ETH_ENETADDR_ENV_NAME_LEN?
I do find it to be quite a long name. Which makes the whole 80 charcters 
per line a thing.


But done :)



  int eth_getenv_enetaddr(const char *name, uchar *enetaddr);
  int eth_setenv_enetaddr(const char *name, const uchar *enetaddr);

diff --git a/net/eth_common.c b/net/eth_common.c
index e9d3c66..079be89 100644
--- a/net/eth_common.c
+++ b/net/eth_common.c
@@ -42,16 +42,20 @@ int eth_setenv_enetaddr(const char *name, const uchar 
*enetaddr)
  int eth_getenv_enetaddr_by_index(const char *base_name, int index,
  uchar *enetaddr)
  {
-   char enetvar[32];
-   sprintf(enetvar, index ? "%s%daddr" : "%saddr", base_name, index);
+   char enetvar[ETH_ENETADDR_LEN];
+
+   snprintf(enetvar, ETH_ENETADDR_LEN, index ? "%s%daddr" : "%saddr",
+base_name, index);
 return eth_getenv_enetaddr(enetvar, enetaddr);
  }

  int eth_setenv_enetaddr_by_index(const char *base_name, int index,
  uchar *enetaddr)
  {
-   char enetvar[32];
-   sprintf(enetvar, index ? "%s%daddr" : "%saddr", base_name, index);
+   char enetvar[ETH_ENETADDR_LEN];
+
+   snprintf(enetvar, ETH_ENETADDR_LEN, index ? "%s%daddr" : "%saddr",
+base_name, index);
 return eth_setenv_enetaddr(enetvar, enetaddr);
  }

--
2.10.2

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


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

Re: [U-Boot] [PATCH] imx_common: spl: Fix SPL boot from SD card

[Fabio Estevam]

On Fri, Dec 2, 2016 at 3:16 PM, Marcin Niestroj
 wrote:

>> If you took the assumption that in "BOOT_DEVICE_MMC1 = Boot from SDHC1
>> port" in 54e4fcfa3c749a78 ("ARM: mx6: add MMC2 boot device detection
>> support in SPL") I suggest we need to revert it.
>>
>
> Indeed it was my assumption. I agree it should be reverted then.

Thanks for confirming.

Stefano, would you like to take Breno's original patch with the
revert? Or would you like me to resend it with an improved commit log
explaining the reason for the breakage?

> So to support booting from two SD/MMC devices one should create
> board_boot_order() function? That way BOOT_CFG2[3:4] can be read there
> to figure out which MMC1 or MMC2 should be configured as the first boot
> device.

If you want to determine the SD/MMC port dynamically it seems like a solution.

Or if you always know the SD/MMC port you will boot from then you can
simply register the associated SDHC port first.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] qemu and u-boot-console and other ports?

[Tom Rini]

On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:
> On 12/02/2016 07:40 AM, Tom Rini wrote:
> >Hey,
> >
> >I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
> >current round of testing is applied you'll need
> >http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
> >for us to get a functional U-Boot.  After that, I have a "normal" conf
> >file for the board for QEMU that looks like:
> >console_impl=qemu
> >qemu_machine="r2d"
> >qemu_binary="qemu-system-sh4"
> >qemu_extra_args="-nographic -serial null -serial mon:stdio"
> >qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
> >reset_impl=none
> >flash_impl=none
> >
> >And here's where things get funny.  When I kick off test.py with --bd
> >r2dplus --id qemu --build -s -k sleep it will build and launch the board
> >and since I have -s I can see stdio and I see U-Boot come up and give me
> >the prompt, and then test.py says it times out waiting for the prompt.
> >Any ideas where to poke next?  I want to say something is funny with
> >respect to what we see and where we see it (in terms of pipes) due to
> >having to say -serial null -serial mon:stdio so that we see port #2 on
> >the "board" rather than port #1 as this is the port that U-Boot and
> >Linux use by default.  Thanks!
> 
> Does "-serial null -serial mon:stdio" cause qemu to re-open file
> descriptors rather than just using stdout directly, or something
> like that? If so, perhaps its output is getting into the overall
> script's stdout (e.g. your terminal/console?) rather than the pipe
> that test/py is reading. If so, you'd see the qemu output but
> test/py wouldn't.
> 
> I think you can test this assumption by removing the -s option. If
> you still see qemu output, then qemu is sending it directly to
> wherever the overall stdout is going. If you no longer see qemu's
> output, then test/py must be reading it and only echo'ing it due to
> the -s option, and so you'd have to look somewhere else.

When I drop out -s instead I get:
--- Captured stdout 

+u-boot-test-reset r2dplus qemu
long write to SH7750_WCR1_A7 (0x1f88) ignored
long write to SH7750_WCR2_A7 (0x1f8c) ignored
long write to SH7750_WCR3_A7 (0x1f800010) ignored
long write to SH7750_MCR_A7 (0x1f800014) ignored
word write to SH7750_RTCNT_A7 (0x1f800020) ignored
word write to SH7750_RTCOR_A7 (0x1f800024) ignored
Write access to refresh count register
word write to SH7750_RTCSR_A7 (0x1f80001c) ignored
Read access to refresh count register, incrementing
long write to SH7750_MCR_A7 (0x1f800014) ignored


U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)

CPU: SH4
BOARD: Renesas Solutions R2D Plus
DRAM:  64 MiB
Flash: ERROR: too many flash sectors
8 MiB
*** Warning - bad CRC, using default environment

PCI: SH7751 PCI host bridge found.
long read to SH7750_WCR1_A7 (0x1f88) ignored
long read to SH7750_WCR2_A7 (0x1f8c) ignored
long read to SH7750_WCR3_A7 (0x1f800010) ignored
long read to SH7750_MCR_A7 (0x1f800014) ignored
PCI:   Bus Dev VenId DevId Class Int
PCI:
  00:00.0 - 1054:350e - Bridge device
  00:02.0 - 10ec:8139 - Network controller
In:serial
Out:   serial
Err:   serial
Net:   RTL8139#0
Error: RTL8139#0 address not set.

IDE:   Bus 0: not available
=> => s
=== 92 tests deselected by '-ksleep' 
===
=== 1 failed, 92 deselected in 31.20 seconds 
===

So it's seeing output, but for some reason not matching on it?

-- 
Tom


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

Re: [U-Boot] qemu and u-boot-console and other ports?

[Stephen Warren]

On 12/02/2016 12:18 PM, Tom Rini wrote:

On Fri, Dec 02, 2016 at 11:03:00AM -0700, Stephen Warren wrote:

On 12/02/2016 07:40 AM, Tom Rini wrote:

Hey,

I'm trying to debug adding sh4 and r2dplus support to test.py.  Until my
current round of testing is applied you'll need
http://patchwork.ozlabs.org/bundle/trini/fix-sh4-support-v2/ in order
for us to get a functional U-Boot.  After that, I have a "normal" conf
file for the board for QEMU that looks like:
console_impl=qemu
qemu_machine="r2d"
qemu_binary="qemu-system-sh4"
qemu_extra_args="-nographic -serial null -serial mon:stdio"
qemu_kernel_args="-kernel ${U_BOOT_BUILD_DIR}/u-boot.bin"
reset_impl=none
flash_impl=none

And here's where things get funny.  When I kick off test.py with --bd
r2dplus --id qemu --build -s -k sleep it will build and launch the board
and since I have -s I can see stdio and I see U-Boot come up and give me
the prompt, and then test.py says it times out waiting for the prompt.
Any ideas where to poke next?  I want to say something is funny with
respect to what we see and where we see it (in terms of pipes) due to
having to say -serial null -serial mon:stdio so that we see port #2 on
the "board" rather than port #1 as this is the port that U-Boot and
Linux use by default.  Thanks!


Does "-serial null -serial mon:stdio" cause qemu to re-open file
descriptors rather than just using stdout directly, or something
like that? If so, perhaps its output is getting into the overall
script's stdout (e.g. your terminal/console?) rather than the pipe
that test/py is reading. If so, you'd see the qemu output but
test/py wouldn't.

I think you can test this assumption by removing the -s option. If
you still see qemu output, then qemu is sending it directly to
wherever the overall stdout is going. If you no longer see qemu's
output, then test/py must be reading it and only echo'ing it due to
the -s option, and so you'd have to look somewhere else.


When I drop out -s instead I get:
--- Captured stdout 

+u-boot-test-reset r2dplus qemu
long write to SH7750_WCR1_A7 (0x1f88) ignored
long write to SH7750_WCR2_A7 (0x1f8c) ignored
long write to SH7750_WCR3_A7 (0x1f800010) ignored
long write to SH7750_MCR_A7 (0x1f800014) ignored
word write to SH7750_RTCNT_A7 (0x1f800020) ignored
word write to SH7750_RTCOR_A7 (0x1f800024) ignored
Write access to refresh count register
word write to SH7750_RTCSR_A7 (0x1f80001c) ignored
Read access to refresh count register, incrementing
long write to SH7750_MCR_A7 (0x1f800014) ignored


U-Boot 2016.11-00492-ged6a1e9bbf0c (Dec 02 2016 - 14:14:17 -0500)

CPU: SH4
BOARD: Renesas Solutions R2D Plus
DRAM:  64 MiB
Flash: ERROR: too many flash sectors
8 MiB
*** Warning - bad CRC, using default environment

PCI: SH7751 PCI host bridge found.
long read to SH7750_WCR1_A7 (0x1f88) ignored
long read to SH7750_WCR2_A7 (0x1f8c) ignored
long read to SH7750_WCR3_A7 (0x1f800010) ignored
long read to SH7750_MCR_A7 (0x1f800014) ignored
PCI:   Bus Dev VenId DevId Class Int
PCI:
  00:00.0 - 1054:350e - Bridge device
  00:02.0 - 10ec:8139 - Network controller
In:serial
Out:   serial
Err:   serial
Net:   RTL8139#0
Error: RTL8139#0 address not set.

IDE:   Bus 0: not available
=> => s
=== 92 tests deselected by '-ksleep' 
===
=== 1 failed, 92 deselected in 31.20 seconds 
===

So it's seeing output, but for some reason not matching on it?


If you drop -s, you shouldn't see any of U-Boot's output. It looks like 
qemu is writing its serial port output to a file descriptor other than 
the stdout that's fed to its parent.


Oh, you can also confirm this by looking in the test-log.html generated 
by test/py; that will show you whether test/py sees qemu's output at 
all, since all of qemu's output is logged to that file. I guess this 
assumes you're running locally, since Travis doesn't save that file for 
you to look at. Perhaps you could cat it after running test/py though.

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

Re: [U-Boot] [PATCH v5 10/13] tegra: Use a U-Boot-specific .dtsi file

[Stephen Warren]

On 11/30/2016 07:19 PM, Simon Glass wrote:

Hi Stephen,

On 29 November 2016 at 21:09, Stephen Warren  wrote:

On 11/28/2016 03:09 PM, Simon Glass wrote:


Hi Stephen,

On 17 November 2016 at 12:45, Stephen Warren 
wrote:



On 11/16/2016 06:13 PM, Simon Glass wrote:



With the new device-tree rules it is possible to put device-tree changes
needed by U-Boot into their own file. As an example of this approach,
move
Tegra over to use it.




Sounds like a good idea.


diff --git a/arch/arm/dts/tegra20-u-boot.dtsi
b/arch/arm/dts/tegra20-u-boot.dtsi




I'd expect to see more "U-Boot overlay" DTs than this; I recall there
being more differences between U-Boot and kernel DTS files when I last
sync'd the two.



Yes but most of those changes should be dropped. I did a partial sync
a few months back but if you recall there were still differences. Is
this something the Tegra maintainer might look at?

I don't want to immortalise those differences in a separate U-Boot
file when really we should just get rid of them.



From my perspective, we should have two files:

1) The base DT.

This should not contain any U-Boot modifications, and should exactly match
the DT used elsewhere, such as in mainline Linux. Since this should always
match other DTs, we should pretty much always be able to over-write it with
any updated DT from other sources.

2) The U-Boot modifications.

This always contain /all/ local modifications applied by U-Boot. It
shouldn't matter why the change was made, or how long we hope/expect the
delta to continue to exist. This will isolate all U-Boot changes into this
file so it's obvious what local changes exist. If some changes are intended
to be temporary, we can add a comment to that effect, and eventually submit
a patch to remove the delta.

I don't think that putting a change into this "U-Boot local overlay" should
in any way imply that the change is by definition correct and long-term;
some changes may satisfy that decription and others won't. Just like we
sometimes have C code that we wish we didn't and eventually clean up.


That's fine with me. What do you want to do with this patch?


IIRC the patch content is fine as far as it goes, but it'd be nice to 
take it all the way and move all the U-Boot diffs into 
arch/arm/dts/tegra20-u-boot.dtsi if possible.

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

[U-Boot] [PATCH] ARM: tegra: allow passing cboot DTB to the kernel

[Stephen Warren]

From: Stephen Warren 

Some users may wish to pass the cboot-supplied DTB to the booted kernel
rather than having U-Boot load the DTB itself. To allow this, expose the
address of the cboot-supplied DTB in environment variable $fdt_addr. At
least when using extlinux.conf, if the user doesn't explicitly specify
which DTB to pass to the kernel, U-Boot passes the DTB referred to by
this variable.

Signed-off-by: Stephen Warren 
---
 arch/arm/mach-tegra/tegra186/nvtboot_board.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/mach-tegra/tegra186/nvtboot_board.c 
b/arch/arm/mach-tegra/tegra186/nvtboot_board.c
index 1d78346f9843..feb935f0d908 100644
--- a/arch/arm/mach-tegra/tegra186/nvtboot_board.c
+++ b/arch/arm/mach-tegra/tegra186/nvtboot_board.c
@@ -11,6 +11,19 @@
 
 extern unsigned long nvtboot_boot_x0;
 
+static int set_fdt_addr(void)
+{
+   int ret;
+
+   ret = setenv_hex("fdt_addr", nvtboot_boot_x0);
+   if (ret) {
+   printf("Failed to set fdt_addr to point at DTB: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
 /*
  * Attempt to use /chosen/nvidia,ether-mac in the nvtboot DTB to U-Boot's
  * ethaddr environment variable if possible.
@@ -47,6 +60,11 @@ static int set_ethaddr_from_nvtboot(void)
 
 int tegra_soc_board_init_late(void)
 {
+   /*
+* Ignore errors here; the value may not be used depending on
+* extlinux.conf or boot script content.
+*/
+   set_fdt_addr();
/* Ignore errors here; not all cases care about Ethernet addresses */
set_ethaddr_from_nvtboot();
 
-- 
2.11.0

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

Re: [U-Boot] [PATCH] arm: am33xx: Initialize EMIF REG_PR_OLD_COUNT for BBB and am335x-evm

[Jyri Sarha]

On 12/02/16 15:01, Tom Rini wrote:
> On Fri, Dec 02, 2016 at 09:54:39AM +0200, Jyri Sarha wrote:
> 
>> Initialize EMIF OCP_CONFIG registers REG_COS_COUNT_1, REG_COS_COUNT_2,
>> and REG_PR_OLD_COUNT field for Beaglebone-Black and am335x-evm. With
>> the default values LCDC suffers from DMA FIFO underflows and frame
>> synchronization lost errors. The initialization values are the highest
>> that work flawlessly when heavy memory load is generated by CPU. 32bpp
>> colors were used in the test. On BBB the video mode used 110MHz pixel
>> clock. The mode supported by the panel of am335x-evm uses 30MHz pixel
>> clock.
>>
>> Signed-off-by: Jyri Sarha 
> [snip]
>> diff --git a/arch/arm/include/asm/arch-am33xx/ddr_defs.h 
>> b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> index 43e122e..c71cfd0 100644
>> --- a/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> +++ b/arch/arm/include/asm/arch-am33xx/ddr_defs.h
>> @@ -25,6 +25,14 @@
>>  #endif
>>  #define PHY_EN_DYN_PWRDN(0x1 << 20)
>>  
>> +/**
>> + * AM335X (EMIF_4D) EMIF REG_COS_COUNT_1, REG_COS_COUNT_2, and
>> + * REG_PR_OLD_COUNT values to avoid LCDC DMA FIFO underflows and Frame
>> + * Synchronization Lost errors.
>> + */
>> +#define EMIF_OCP_CONFIG_BEAGLEBONE_BLACK0x00141414
>> +#define EMIF_OCP_CONFIG_AM335X_EVM  0x003d3d3d
> 
> OK, but the problems I see are that first we don't explain what these
> values are tied to physically.  Is it the display? The DDR memory?

It is a combination of both. I'll add that to the comment.

> Second, since these are board specific they should be in
> board/ti/am335x/board.h.  Thanks!
> 

Ok, I'll move the defines there.

Thanks,
Jyri

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

[U-Boot] [PATCH 02/11] powerpc: mpc85xx: Convert CONFIG_SYS_CCSRBAR_DEFAULT to Kconfig option

[York Sun]

Move default value definitions to to Kconfig SYS_CCSRBAR_DEFAULT.

Signed-off-by: York Sun 
---

 arch/powerpc/cpu/mpc85xx/Kconfig  | 50 +++
 arch/powerpc/include/asm/config_mpc85xx.h | 41 -
 doc/README.ramboot-ppc85xx|  4 +--
 3 files changed, 52 insertions(+), 43 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 9a5cd85..1d2e027 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -471,6 +471,56 @@ config MAX_CPUS
  cores, count the reserved ports. This will allocate enough memory
  in spin table to properly handle all cores.
 
+config SYS_CCSRBAR_DEFAULT
+   hex "Default CCSRBAR address"
+   default 0xff70 if   ARCH_BSC9131|| \
+   ARCH_BSC9132|| \
+   ARCH_C29X   || \
+   ARCH_MPC8536|| \
+   ARCH_MPC8540|| \
+   ARCH_MPC8541|| \
+   ARCH_MPC8544|| \
+   ARCH_MPC8548|| \
+   ARCH_MPC8555|| \
+   ARCH_MPC8560|| \
+   ARCH_MPC8568|| \
+   ARCH_MPC8569|| \
+   ARCH_MPC8572|| \
+   ARCH_P1010  || \
+   ARCH_P1011  || \
+   ARCH_P1020  || \
+   ARCH_P1021  || \
+   ARCH_P1022  || \
+   ARCH_P1024  || \
+   ARCH_P1025  || \
+   ARCH_P2020
+   default 0xff60 if   ARCH_P1023
+   default 0xfe00 if   ARCH_B4420  || \
+   ARCH_B4860  || \
+   ARCH_P2041  || \
+   ARCH_P3041  || \
+   ARCH_P4080  || \
+   ARCH_P5020  || \
+   ARCH_P5040  || \
+   ARCH_T1013  || \
+   ARCH_T1014  || \
+   ARCH_T1020  || \
+   ARCH_T1022  || \
+   ARCH_T1023  || \
+   ARCH_T1024  || \
+   ARCH_T1040  || \
+   ARCH_T1042  || \
+   ARCH_T2080  || \
+   ARCH_T2081  || \
+   ARCH_T4160  || \
+   ARCH_T4240
+   default 0xe000 if ARCH_QEMU_E500
+   help
+   Default value of CCSRBAR comes from power-on-reset. It
+   is fixed on each SoC. Some SoCs can have different value
+   if changed by pre-boot regime. The value here must match
+   the current value in SoC. If not sure, do not change.
+
 source "board/freescale/b4860qds/Kconfig"
 source "board/freescale/bsc9131rdb/Kconfig"
 source "board/freescale/bsc9132qds/Kconfig"
diff --git a/arch/powerpc/include/asm/config_mpc85xx.h 
b/arch/powerpc/include/asm/config_mpc85xx.h
index c92bc1e..474fd1a 100644
--- a/arch/powerpc/include/asm/config_mpc85xx.h
+++ b/arch/powerpc/include/asm/config_mpc85xx.h
@@ -9,10 +9,6 @@
 
 /* SoC specific defines for Freescale MPC85xx (PQ3) and QorIQ processors */
 
-#ifdef CONFIG_SYS_CCSRBAR_DEFAULT
-#error "Do not define CONFIG_SYS_CCSRBAR_DEFAULT in the board header file."
-#endif
-
 /*
  * This macro should be removed when we no longer care about backwards
  * compatibility with older operating systems.
@@ -39,27 +35,23 @@
 #define CONFIG_SYS_FSL_NUM_LAWS12
 #define CONFIG_SYS_PPC_E500_DEBUG_TLB  1
 #define CONFIG_SYS_FSL_SEC_COMPAT  2
-#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 #define CONFIG_SYS_FSL_ERRATUM_A004508
 #define CONFIG_SYS_FSL_ERRATUM_A005125
 
 #elif defined(CONFIG_ARCH_MPC8540)
 #define CONFIG_SYS_FSL_NUM_LAWS8
 #define CONFIG_SYS_FSL_DDRC_GEN1
-#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 
 #elif defined(CONFIG_ARCH_MPC8541)
 #define CONFIG_SYS_FSL_NUM_LAWS8
 #define CONFIG_SYS_FSL_DDRC_GEN1
 #define CONFIG_SYS_FSL_SEC_COMPAT  2
-#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 
 #elif defined(CONFIG_ARCH_MPC8544)
 #define CONFIG_SYS_FSL_NUM_LAWS10
 #define CONFIG_SYS_FSL_DDRC_GEN2
 #define CONFIG_SYS_PPC_E500_DEBUG_TLB  0
 #define CONFIG_SYS_FSL_SEC_COMPAT  2
-#define CONFIG_SYS_CCSRBAR_DEFAULT 0xff70
 #define CONFIG_SYS_FSL_ERRATUM_A005125
 
 #elif 

[U-Boot] [PATCH 07/11] powerpc: mpc85xx: Move SECURE_BOOT to Kconfig

[York Sun]

Move from CONFIG_SYS_EXTRA_OPTIONS to Kconfig option.

Signed-off-by: York Sun 
---

 arch/powerpc/cpu/mpc85xx/Kconfig   | 6 ++
 configs/B4860QDS_SECURE_BOOT_defconfig | 2 +-
 configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig | 3 ++-
 configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig | 3 ++-
 configs/BSC9132QDS_NOR_DDRCLK100_SECURE_defconfig  | 3 ++-
 configs/BSC9132QDS_NOR_DDRCLK133_SECURE_defconfig  | 3 ++-
 configs/BSC9132QDS_SDCARD_DDRCLK100_SECURE_defconfig   | 3 ++-
 configs/BSC9132QDS_SDCARD_DDRCLK133_SECURE_defconfig   | 3 ++-
 configs/BSC9132QDS_SPIFLASH_DDRCLK100_SECURE_defconfig | 3 ++-
 configs/BSC9132QDS_SPIFLASH_DDRCLK133_SECURE_defconfig | 3 ++-
 configs/C29XPCIE_NOR_SECBOOT_defconfig | 2 +-
 configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig| 3 ++-
 configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig   | 3 ++-
 configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig| 2 +-
 configs/P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig   | 3 ++-
 configs/P1010RDB-PA_NAND_SECBOOT_defconfig | 3 ++-
 configs/P1010RDB-PA_NOR_SECBOOT_defconfig  | 2 +-
 configs/P1010RDB-PA_SPIFLASH_SECBOOT_defconfig | 3 ++-
 configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig   | 3 ++-
 configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig| 2 +-
 configs/P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig   | 3 ++-
 configs/P1010RDB-PB_NAND_SECBOOT_defconfig | 3 ++-
 configs/P1010RDB-PB_NOR_SECBOOT_defconfig  | 2 +-
 configs/P1010RDB-PB_SPIFLASH_SECBOOT_defconfig | 3 ++-
 configs/P2041RDB_SECURE_BOOT_defconfig | 2 +-
 configs/P3041DS_NAND_SECURE_BOOT_defconfig | 3 ++-
 configs/P3041DS_SECURE_BOOT_defconfig  | 2 +-
 configs/P4080DS_SECURE_BOOT_defconfig  | 2 +-
 configs/P5020DS_NAND_SECURE_BOOT_defconfig | 3 ++-
 configs/P5020DS_SECURE_BOOT_defconfig  | 2 +-
 configs/P5040DS_NAND_SECURE_BOOT_defconfig | 3 ++-
 configs/P5040DS_SECURE_BOOT_defconfig  | 2 +-
 configs/T1023RDB_SECURE_BOOT_defconfig | 3 ++-
 configs/T1024QDS_DDR4_SECURE_BOOT_defconfig| 3 ++-
 configs/T1024QDS_SECURE_BOOT_defconfig | 2 +-
 configs/T1024RDB_SECURE_BOOT_defconfig | 3 ++-
 configs/T1040D4RDB_SECURE_BOOT_defconfig   | 3 ++-
 configs/T1040QDS_SECURE_BOOT_defconfig | 2 +-
 configs/T1040RDB_SECURE_BOOT_defconfig | 2 +-
 configs/T1042D4RDB_SECURE_BOOT_defconfig   | 3 ++-
 configs/T1042RDB_PI_NAND_SECURE_BOOT_defconfig | 3 ++-
 configs/T1042RDB_SECURE_BOOT_defconfig | 2 +-
 configs/T2080QDS_SECURE_BOOT_defconfig | 2 +-
 configs/T2080RDB_SECURE_BOOT_defconfig | 2 +-
 configs/T4160QDS_SECURE_BOOT_defconfig | 2 +-
 configs/T4240QDS_SECURE_BOOT_defconfig | 2 +-
 46 files changed, 77 insertions(+), 45 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/Kconfig b/arch/powerpc/cpu/mpc85xx/Kconfig
index 1d2e027..f782695 100644
--- a/arch/powerpc/cpu/mpc85xx/Kconfig
+++ b/arch/powerpc/cpu/mpc85xx/Kconfig
@@ -435,6 +435,12 @@ config ARCH_T4160
 config ARCH_T4240
bool
 
+config SECURE_BOOT
+   bool"Secure Boot"
+   help
+   Enable Freescale Secure Boot feature. Normally selected
+   by defconfig. If unsure, do not change.
+
 config MAX_CPUS
int "Maximum number of CPUs permitted for MPC85xx"
default 12 if ARCH_T4240
diff --git a/configs/B4860QDS_SECURE_BOOT_defconfig 
b/configs/B4860QDS_SECURE_BOOT_defconfig
index 53c122c..e2e16fb 100644
--- a/configs/B4860QDS_SECURE_BOOT_defconfig
+++ b/configs/B4860QDS_SECURE_BOOT_defconfig
@@ -6,7 +6,7 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_SYS_EXTRA_OPTIONS="SECURE_BOOT"
+CONFIG_SECURE_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig 
b/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
index a8fa5ab..52d5fe9 100644
--- a/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
+++ b/configs/BSC9132QDS_NAND_DDRCLK100_SECURE_defconfig
@@ -6,7 +6,8 @@ CONFIG_FIT=y
 CONFIG_FIT_VERBOSE=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
-CONFIG_SYS_EXTRA_OPTIONS="NAND_SECBOOT,SYS_CLK_100_DDR_100,SECURE_BOOT"
+CONFIG_SYS_EXTRA_OPTIONS="NAND_SECBOOT,SYS_CLK_100_DDR_100"
+CONFIG_SECURE_BOOT=y
 CONFIG_BOOTDELAY=10
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 CONFIG_HUSH_PARSER=y
diff --git a/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig 
b/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
index 4d79281..afa4aad 100644
--- a/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
+++ b/configs/BSC9132QDS_NAND_DDRCLK133_SECURE_defconfig
@@ -6,7 +6,8 @@ CONFIG_FIT=y