[U-Boot] [PATCH v3 0/9] From Simon:

[U-Boot] [PATCH v3 0/9] From Simon:

[Simon Glass]

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 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-rk3288
- 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] [PATCH v3 1/9] net: designware: Export various functions/struct to allow subclassing

[Simon Glass]

From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

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 <sjoerd.simons@collabora.co.uk>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

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] [PATCH v3 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 <sjg@chromium.org>
---

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(&mac_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] [PATCH v3 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 <sjg@chromium.org>
---

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] [PATCH v3 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 <sjg@chromium.org>
---

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] [PATCH v3 5/9] net: gmac_rk3288: Add RK3288 GMAC driver

[Simon Glass]

From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

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 <sjoerd.simons@collabora.co.uk>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

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 0000000..0c22756
--- /dev/null
+++ b/drivers/net/gmac_rk3288.c
@@ -0,0 +1,154 @@
+/*
+ * (C) Copyright 2015 Sjoerd Simons <sjoerd.simons@collabora.co.uk>
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ *
+ * Rockchip GMAC ethernet IP driver for U-Boot
+ */
+
+#include <common.h>
+#include <dm.h>
+#include <clk.h>
+#include <phy.h>
+#include <syscon.h>
+#include <asm/io.h>
+#include <asm/arch/periph.h>
+#include <asm/arch/clock.h>
+#include <asm/arch/grf_rk3288.h>
+#include <dm/pinctrl.h>
+#include <dt-bindings/clock/rk3288-cru.h>
+#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(&grf->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, &clk);
+	if (ret)
+		return ret;
+
+	/* Since mac_clk is fed by an external clock we can use 0 here */
+	ret = clk_set_rate(&clk, 0);
+	if (ret)
+		return ret;
+
+	/* Set to RGMII mode */
+	grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+	rk_clrsetreg(&grf->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(&grf->soc_con3,
+		     RXCLK_DLY_ENA_GMAC_MASK <<  RXCLK_DLY_ENA_GMAC_SHIFT |
+		     TXCLK_DLY_ENA_GMAC_MASK <<  TXCLK_DLY_ENA_GMAC_SHIFT |
+		     CLK_RX_DL_CFG_GMAC_MASK <<  CLK_RX_DL_CFG_GMAC_SHIFT |
+		     CLK_TX_DL_CFG_GMAC_MASK <<  CLK_TX_DL_CFG_GMAC_SHIFT,
+		     RXCLK_DLY_ENA_GMAC_ENABLE << RXCLK_DLY_ENA_GMAC_SHIFT |
+		     TXCLK_DLY_ENA_GMAC_ENABLE << TXCLK_DLY_ENA_GMAC_SHIFT |
+		     pdata->rx_delay << CLK_RX_DL_CFG_GMAC_SHIFT |
+		     pdata->tx_delay << CLK_TX_DL_CFG_GMAC_SHIFT);
+
+	return designware_eth_probe(dev);
+}
+
+static int gmac_rk3288_eth_start(struct udevice *dev)
+{
+	struct eth_pdata *pdata = dev_get_platdata(dev);
+	struct dw_eth_dev *priv = dev_get_priv(dev);
+	int ret;
+
+	ret = designware_eth_init(priv, pdata->enetaddr);
+	if (ret)
+		return ret;
+	ret = gmac_rk3288_fix_mac_speed(priv);
+	if (ret)
+		return ret;
+	ret = designware_eth_enable(priv);
+	if (ret)
+		return ret;
+
+	return 0;
+}
+
+const struct eth_ops gmac_rk3288_eth_ops = {
+	.start			= gmac_rk3288_eth_start,
+	.send			= designware_eth_send,
+	.recv			= designware_eth_recv,
+	.free_pkt		= designware_eth_free_pkt,
+	.stop			= designware_eth_stop,
+	.write_hwaddr		= designware_eth_write_hwaddr,
+};
+
+static const struct udevice_id rk3288_gmac_ids[] = {
+	{ .compatible = "rockchip,rk3288-gmac" },
+	{ }
+};
+
+U_BOOT_DRIVER(eth_gmac_rk3288) = {
+	.name	= "gmac_rk3288",
+	.id	= UCLASS_ETH,
+	.of_match = rk3288_gmac_ids,
+	.ofdata_to_platdata = gmac_rk3288_ofdata_to_platdata,
+	.probe	= gmac_rk3288_probe,
+	.ops	= &gmac_rk3288_eth_ops,
+	.priv_auto_alloc_size = sizeof(struct dw_eth_dev),
+	.platdata_auto_alloc_size = sizeof(struct gmac_rk3288_platdata),
+	.flags = DM_FLAG_ALLOC_PRIV_DMA,
+};
-- 
2.8.0.rc3.226.g39d4020

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

[Simon Glass]

From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

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

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

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] [PATCH v3 7/9] rockchip: evb-rk3339: Enable DHCP

[Simon Glass]

This is the only RK3288 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 <sjg@chromium.org>
---

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

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] [PATCH v3 8/9] rockchip: Add PXE and DHCP to the default boot targets

[Simon Glass]

From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

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 <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

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] [PATCH v3 9/9] rockchip: Drop Ethernet from the TODO

[Simon Glass]

From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

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

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
---

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] [PATCH v3 7/9] rockchip: evb-rk3339: Enable DHCP

[Heiko Stübner]

Hi Simon,

Am Sonntag, 27. November 2016, 10:01:47 schrieb Simon Glass:
> This is the only RK3288 device without DHCP. Enable it so that we
                      ^^ rk3288/rk3399?
> 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 <sjg@chromium.org>
> ---
> 
> Changes in v3:
> - Add new patch to enable networking on evb-rk3288

same here :-)


Heiko

> 
> 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

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

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass <sjg@chromium.org> wrote:
> This function can fail, so return the error if there is one.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

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

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass <sjg@chromium.org> wrote:
> From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>
> 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 <sjoerd.simons@collabora.co.uk>
> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
> Acked-by: Simon Glass <sjg@chromium.org>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

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

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass <sjg@chromium.org> wrote:
> 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 <sjg@chromium.org>

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

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

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass <sjg@chromium.org> wrote:
> Export all functions so that drivers can use them, or not, as the need
> arises.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

With a minor nit below,

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

> ---
>
> 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)

Modern functions are called "_start", not init. Also, this already
uses stop below, instead of halt. It would be nice to keep them
symmetric.

>  {
>         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;
>  }

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

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass <sjg@chromium.org> wrote:
> From: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
>
> 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 <sjoerd.simons@collabora.co.uk>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Acked-by: Joe Hershberger <joe.hershberger@ni.com>

[U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Hi Simon,

Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> 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.

Tested on a firefly as well. Though I get mixed results in my netboot 
environment. At 100MBit (manually limited) everything seems fine:

----------------------
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.58 (269 ms)
Using ethernet at ff290000 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.58
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x4000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #########################
         2.9 MiB/s
done
Bytes transferred = 7033483 (6b528b hex)
----------------------

5 out of 5 boots worked fine.


but at 1000MHz I only get:

----------------------
Speed: 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.57 (270 ms)
Using ethernet at ff290000 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.57
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x4000000
Loading: #####T #T #T ##T T #T #T T ####T #T ####
Retry count exceeded; starting again
----------------------

on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
I'm not sure if just my switch is some special snowflake (TL-SG1024 from TP-
Link) or there is some other voodoo at work here.

The rootfs over nfs seems to work fine on 1000MBit though.


Heiko

> 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 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-rk3288
> - 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

[U-Boot] [PATCH v3 0/9] From Simon:

[Simon Glass]

Hi Heiko,

On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
> Hi Simon,
>
> Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
>> 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.
>
> Tested on a firefly as well. Though I get mixed results in my netboot
> environment. At 100MBit (manually limited) everything seems fine:
>
> ----------------------
> Speed: 100, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.140.58 (269 ms)
> Using ethernet at ff290000 device
> TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> Filename 'hstuebner/firefly.vmlinuz'.
> Load address: 0x4000000
> Loading: #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #################################################################
>          #########################
>          2.9 MiB/s
> done
> Bytes transferred = 7033483 (6b528b hex)
> ----------------------
>
> 5 out of 5 boots worked fine.
>
>
> but at 1000MHz I only get:
>
> ----------------------
> Speed: 1000, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.140.57 (270 ms)
> Using ethernet at ff290000 device
> TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> Filename 'hstuebner/firefly.vmlinuz'.
> Load address: 0x4000000
> Loading: #####T #T #T ##T T #T #T T ####T #T ####
> Retry count exceeded; starting again
> ----------------------
>
> on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
> I'm not sure if just my switch is some special snowflake (TL-SG1024 from TP-
> Link) or there is some other voodoo at work here.
>
> The rootfs over nfs seems to work fine on 1000MBit though.

Yes I see some timeouts, although I don't think it is anything to do
with the driver conversion. Or does this not happen unless my patches
are applied?


>
>
> Heiko
>
[..]

Regards,
Simon

[U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> Hi Heiko,
> 
> On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
> > Hi Simon,
> > 
> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> >> 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.
> > 
> > Tested on a firefly as well. Though I get mixed results in my netboot
> > environment. At 100MBit (manually limited) everything seems fine:
> > 
> > ----------------------
> > Speed: 100, full duplex
> > BOOTP broadcast 1
> > BOOTP broadcast 2
> > DHCP client bound to address 192.168.140.58 (269 ms)
> > Using ethernet at ff290000 device
> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> > Filename 'hstuebner/firefly.vmlinuz'.
> > Load address: 0x4000000
> > Loading: #################################################################
> > 
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          #################################################################
> >          #########################
> >          2.9 MiB/s
> > 
> > done
> > Bytes transferred = 7033483 (6b528b hex)
> > ----------------------
> > 
> > 5 out of 5 boots worked fine.
> > 
> > 
> > but at 1000MHz I only get:
> > 
> > ----------------------
> > Speed: 1000, full duplex
> > BOOTP broadcast 1
> > BOOTP broadcast 2
> > DHCP client bound to address 192.168.140.57 (270 ms)
> > Using ethernet at ff290000 device
> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> > Filename 'hstuebner/firefly.vmlinuz'.
> > Load address: 0x4000000
> > Loading: #####T #T #T ##T T #T #T T ####T #T ####
> > Retry count exceeded; starting again
> > ----------------------
> > 
> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
> > I'm not sure if just my switch is some special snowflake (TL-SG1024 from
> > TP- Link) or there is some other voodoo at work here.
> > 
> > The rootfs over nfs seems to work fine on 1000MBit though.
> 
> Yes I see some timeouts, although I don't think it is anything to do
> with the driver conversion. Or does this not happen unless my patches
> are applied?

nope, really looks like some other parts are just not fast enough? And the 
setup of GRF and so on, look the same as in the linux kernel, so should be fine 
as well.


Heiko

[U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Hi Simon,

Am Mittwoch, 30. November 2016, 12:52:22 schrieb Heiko St?bner:
> Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> > On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
> > > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> > >> 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.
> > > 
> > > Tested on a firefly as well. Though I get mixed results in my netboot
> > > environment. At 100MBit (manually limited) everything seems fine:

so assuming the 1000MBit issue comes from somewhere else, this series
Tested-by: Heiko Stuebner <heiko@sntech.de>


> > > ----------------------
> > > Speed: 100, full duplex
> > > BOOTP broadcast 1
> > > BOOTP broadcast 2
> > > DHCP client bound to address 192.168.140.58 (269 ms)
> > > Using ethernet at ff290000 device
> > > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> > > Filename 'hstuebner/firefly.vmlinuz'.
> > > Load address: 0x4000000
> > > Loading:
> > > #################################################################
> > > 
> > >          ###############################################################
> > >          ##
> > >          ###############################################################
> > >          ##
> > >          ###############################################################
> > >          ##
> > >          ###############################################################
> > >          ##
> > >          ###############################################################
> > >          ##
> > >          ###############################################################
> > >          ##
> > >          #########################
> > >          2.9 MiB/s
> > > 
> > > done
> > > Bytes transferred = 7033483 (6b528b hex)
> > > ----------------------
> > > 
> > > 5 out of 5 boots worked fine.
> > > 
> > > 
> > > but at 1000MHz I only get:
> > > 
> > > ----------------------
> > > Speed: 1000, full duplex
> > > BOOTP broadcast 1
> > > BOOTP broadcast 2
> > > DHCP client bound to address 192.168.140.57 (270 ms)
> > > Using ethernet at ff290000 device
> > > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> > > Filename 'hstuebner/firefly.vmlinuz'.
> > > Load address: 0x4000000
> > > Loading: #####T #T #T ##T T #T #T T ####T #T ####
> > > Retry count exceeded; starting again
> > > ----------------------
> > > 
> > > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown
> > > reason.
> > > I'm not sure if just my switch is some special snowflake (TL-SG1024 from
> > > TP- Link) or there is some other voodoo at work here.
> > > 
> > > The rootfs over nfs seems to work fine on 1000MBit though.
> > 
> > Yes I see some timeouts, although I don't think it is anything to do
> > with the driver conversion. Or does this not happen unless my patches
> > are applied?
> 
> nope, really looks like some other parts are just not fast enough? And the
> setup of GRF and so on, look the same as in the linux kernel, so should be
> fine as well.
> 
> 
> Heiko

[U-Boot] [PATCH v3 0/9] From Simon:

[Simon Glass]

Hi Heiko,

On 30 November 2016 at 04:52, Heiko St?bner <heiko@sntech.de> wrote:
> Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
>> Hi Heiko,
>>
>> On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
>> > Hi Simon,
>> >
>> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
>> >> 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.
>> >
>> > Tested on a firefly as well. Though I get mixed results in my netboot
>> > environment. At 100MBit (manually limited) everything seems fine:
>> >
>> > ----------------------
>> > Speed: 100, full duplex
>> > BOOTP broadcast 1
>> > BOOTP broadcast 2
>> > DHCP client bound to address 192.168.140.58 (269 ms)
>> > Using ethernet at ff290000 device
>> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
>> > Filename 'hstuebner/firefly.vmlinuz'.
>> > Load address: 0x4000000
>> > Loading: #################################################################
>> >
>> >          #################################################################
>> >          #################################################################
>> >          #################################################################
>> >          #################################################################
>> >          #################################################################
>> >          #################################################################
>> >          #########################
>> >          2.9 MiB/s
>> >
>> > done
>> > Bytes transferred = 7033483 (6b528b hex)
>> > ----------------------
>> >
>> > 5 out of 5 boots worked fine.
>> >
>> >
>> > but at 1000MHz I only get:
>> >
>> > ----------------------
>> > Speed: 1000, full duplex
>> > BOOTP broadcast 1
>> > BOOTP broadcast 2
>> > DHCP client bound to address 192.168.140.57 (270 ms)
>> > Using ethernet at ff290000 device
>> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
>> > Filename 'hstuebner/firefly.vmlinuz'.
>> > Load address: 0x4000000
>> > Loading: #####T #T #T ##T T #T #T T ####T #T ####
>> > Retry count exceeded; starting again
>> > ----------------------
>> >
>> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
>> > I'm not sure if just my switch is some special snowflake (TL-SG1024 from
>> > TP- Link) or there is some other voodoo at work here.
>> >
>> > The rootfs over nfs seems to work fine on 1000MBit though.
>>
>> Yes I see some timeouts, although I don't think it is anything to do
>> with the driver conversion. Or does this not happen unless my patches
>> are applied?
>
> nope, really looks like some other parts are just not fast enough? And the
> setup of GRF and so on, look the same as in the linux kernel, so should be fine
> as well.

So to be clear, are you saying that the same problem happens on a
downstream tree that you tried, or not?

In terms of 'not fast enough' you could try turning off HDMI if that
is on. Also see veyron_init() and see if you can adapt that to firefly
to get the clock speed up?

Regards,
Simon

[U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Am Mittwoch, 30. November 2016, 19:20:30 schrieb Simon Glass:
> Hi Heiko,
> 
> On 30 November 2016 at 04:52, Heiko St?bner <heiko@sntech.de> wrote:
> > Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
> >> Hi Heiko,
> >> 
> >> On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
> >> > Hi Simon,
> >> > 
> >> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> >> >> 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.
> >> > 
> >> > Tested on a firefly as well. Though I get mixed results in my netboot
> >> > environment. At 100MBit (manually limited) everything seems fine:
> >> > 
> >> > ----------------------
> >> > Speed: 100, full duplex
> >> > BOOTP broadcast 1
> >> > BOOTP broadcast 2
> >> > DHCP client bound to address 192.168.140.58 (269 ms)
> >> > Using ethernet at ff290000 device
> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> >> > Filename 'hstuebner/firefly.vmlinuz'.
> >> > Load address: 0x4000000
> >> > Loading:
> >> > #################################################################
> >> > 
> >> >          ##############################################################
> >> >          ###
> >> >          ##############################################################
> >> >          ###
> >> >          ##############################################################
> >> >          ###
> >> >          ##############################################################
> >> >          ###
> >> >          ##############################################################
> >> >          ###
> >> >          ##############################################################
> >> >          ###
> >> >          #########################
> >> >          2.9 MiB/s
> >> > 
> >> > done
> >> > Bytes transferred = 7033483 (6b528b hex)
> >> > ----------------------
> >> > 
> >> > 5 out of 5 boots worked fine.
> >> > 
> >> > 
> >> > but at 1000MHz I only get:
> >> > 
> >> > ----------------------
> >> > Speed: 1000, full duplex
> >> > BOOTP broadcast 1
> >> > BOOTP broadcast 2
> >> > DHCP client bound to address 192.168.140.57 (270 ms)
> >> > Using ethernet at ff290000 device
> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> >> > Filename 'hstuebner/firefly.vmlinuz'.
> >> > Load address: 0x4000000
> >> > Loading: #####T #T #T ##T T #T #T T ####T #T ####
> >> > Retry count exceeded; starting again
> >> > ----------------------
> >> > 
> >> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown
> >> > reason.
> >> > I'm not sure if just my switch is some special snowflake (TL-SG1024
> >> > from
> >> > TP- Link) or there is some other voodoo at work here.
> >> > 
> >> > The rootfs over nfs seems to work fine on 1000MBit though.
> >> 
> >> Yes I see some timeouts, although I don't think it is anything to do
> >> with the driver conversion. Or does this not happen unless my patches
> >> are applied?
> > 
> > nope, really looks like some other parts are just not fast enough? And the
> > setup of GRF and so on, look the same as in the linux kernel, so should be
> > fine as well.
> 
> So to be clear, are you saying that the same problem happens on a
> downstream tree that you tried, or not?

nope, didn't say that. The firefly actually is my first board using the internal 
ethernet. My other boards normally use usb-ethernet adapters as the arc-emac 
used in other socs isn't supported at all yet.


> In terms of 'not fast enough' you could try turning off HDMI if that
> is on. Also see veyron_init() and see if you can adapt that to firefly
> to get the clock speed up?

Sadly not until after the 11th of december. But I guess we could just merge it 
now and hopefully fixup the special case later on. It seems to work always at 
100MBit and it seems also at 1000MBit on your side.


Heiko

[U-Boot] [PATCH v3 0/9] From Simon:

[Simon Glass]

Hi Heiko,

On 2 December 2016 at 04:30, Heiko St?bner <heiko@sntech.de> wrote:
> Am Mittwoch, 30. November 2016, 19:20:30 schrieb Simon Glass:
>> Hi Heiko,
>>
>> On 30 November 2016 at 04:52, Heiko St?bner <heiko@sntech.de> wrote:
>> > Am Dienstag, 29. November 2016, 19:47:10 schrieb Simon Glass:
>> >> Hi Heiko,
>> >>
>> >> On 29 November 2016 at 16:45, Heiko St?bner <heiko@sntech.de> wrote:
>> >> > Hi Simon,
>> >> >
>> >> > Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
>> >> >> 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.
>> >> >
>> >> > Tested on a firefly as well. Though I get mixed results in my netboot
>> >> > environment. At 100MBit (manually limited) everything seems fine:
>> >> >
>> >> > ----------------------
>> >> > Speed: 100, full duplex
>> >> > BOOTP broadcast 1
>> >> > BOOTP broadcast 2
>> >> > DHCP client bound to address 192.168.140.58 (269 ms)
>> >> > Using ethernet at ff290000 device
>> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.58
>> >> > Filename 'hstuebner/firefly.vmlinuz'.
>> >> > Load address: 0x4000000
>> >> > Loading:
>> >> > #################################################################
>> >> >
>> >> >          ##############################################################
>> >> >          ###
>> >> >          ##############################################################
>> >> >          ###
>> >> >          ##############################################################
>> >> >          ###
>> >> >          ##############################################################
>> >> >          ###
>> >> >          ##############################################################
>> >> >          ###
>> >> >          ##############################################################
>> >> >          ###
>> >> >          #########################
>> >> >          2.9 MiB/s
>> >> >
>> >> > done
>> >> > Bytes transferred = 7033483 (6b528b hex)
>> >> > ----------------------
>> >> >
>> >> > 5 out of 5 boots worked fine.
>> >> >
>> >> >
>> >> > but at 1000MHz I only get:
>> >> >
>> >> > ----------------------
>> >> > Speed: 1000, full duplex
>> >> > BOOTP broadcast 1
>> >> > BOOTP broadcast 2
>> >> > DHCP client bound to address 192.168.140.57 (270 ms)
>> >> > Using ethernet at ff290000 device
>> >> > TFTP from server 192.168.140.1; our IP address is 192.168.140.57
>> >> > Filename 'hstuebner/firefly.vmlinuz'.
>> >> > Load address: 0x4000000
>> >> > Loading: #####T #T #T ##T T #T #T T ####T #T ####
>> >> > Retry count exceeded; starting again
>> >> > ----------------------
>> >> >
>> >> > on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown
>> >> > reason.
>> >> > I'm not sure if just my switch is some special snowflake (TL-SG1024
>> >> > from
>> >> > TP- Link) or there is some other voodoo at work here.
>> >> >
>> >> > The rootfs over nfs seems to work fine on 1000MBit though.
>> >>
>> >> Yes I see some timeouts, although I don't think it is anything to do
>> >> with the driver conversion. Or does this not happen unless my patches
>> >> are applied?
>> >
>> > nope, really looks like some other parts are just not fast enough? And the
>> > setup of GRF and so on, look the same as in the linux kernel, so should be
>> > fine as well.
>>
>> So to be clear, are you saying that the same problem happens on a
>> downstream tree that you tried, or not?
>
> nope, didn't say that. The firefly actually is my first board using the internal
> ethernet. My other boards normally use usb-ethernet adapters as the arc-emac
> used in other socs isn't supported at all yet.
>
>
>> In terms of 'not fast enough' you could try turning off HDMI if that
>> is on. Also see veyron_init() and see if you can adapt that to firefly
>> to get the clock speed up?
>
> Sadly not until after the 11th of december. But I guess we could just merge it
> now and hopefully fixup the special case later on. It seems to work always at
> 100MBit and it seems also at 1000MBit on your side.

I decided to hold off until we get a bit more testing. Let me know
what you fine.

Regards,
Simon