[PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Ezequiel Garcia]

Very delayed third round of the support for the network controller present
on Marvell Armada 370/XP SoC.

The first patch enables the peripherals in a PUP register, which is required
on RGMII ports.

The second and third patches add support for Marvell's 88E1543 and 88E1545 PHY
chips.

The fourth patch adds the mvneta driver. Most of the configuration part is
based on Linux's mvneta driver, while some of code organization is based
on Barebox's orion-gbe driver.

Changes from v2:

  * Included SPI in the PUP register as noted by Sebastian.

  * Added MAC flow control configuration. Added missing support
    for TX-delayed RGMII (RGMII_TXID) and RX-delayed RGMII.
    As per Sebastian's comments.

  * Dropped the defconfig patch. mvebu_defconfig should work fine.

Ezequiel Garcia (4):
  ARM: mvebu: Enable PUP register
  net: phy: Support Marvell 88EE1545 PHY
  net: phy: Support Marvell 88EE1543 PHY
  net: Add driver for Armada 370/XP 10/100/1000 Mbps network controller

 arch/arm/mach-mvebu/armada-370-xp.c                |   5 +
 .../mach-mvebu/include/mach/armada-370-xp-regs.h   |   7 +
 drivers/net/Kconfig                                |   6 +
 drivers/net/Makefile                               |   1 +
 drivers/net/mvneta.c                               | 766 +++++++++++++++++++++
 drivers/net/phy/marvell.c                          |  67 ++
 include/linux/marvell_phy.h                        |   2 +
 7 files changed, 854 insertions(+)
 create mode 100644 drivers/net/mvneta.c

-- 
2.1.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v3 1/4] ARM: mvebu: Enable PUP register

[Ezequiel Garcia]

As reported by Sebastian, we need to enable this explicitly for the
Tx clock on RGMII. While here, let's enable all the other peripherals.

Although this is documented to be required only for Armada XP SoC,
it has been found to be harmless on Armada 370, so we do it unconditionally
to simplify the code.

Reported-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 arch/arm/mach-mvebu/armada-370-xp.c                   | 5 +++++
 arch/arm/mach-mvebu/include/mach/armada-370-xp-regs.h | 7 +++++++
 2 files changed, 12 insertions(+)

diff --git a/arch/arm/mach-mvebu/armada-370-xp.c b/arch/arm/mach-mvebu/armada-370-xp.c
index 57f6a5f..244f8cd 100644
--- a/arch/arm/mach-mvebu/armada-370-xp.c
+++ b/arch/arm/mach-mvebu/armada-370-xp.c
@@ -74,6 +74,11 @@ static int armada_370_xp_init_soc(struct device_node *root, void *context)
 
 	mvebu_set_memory(phys_base, phys_size);
 
+	/* Enable peripherals PUP */
+	reg = readl(ARMADA_XP_PUP_ENABLE_BASE);
+	reg |= GE0_PUP_EN | GE1_PUP_EN | LCD_PUP_EN | NAND_PUP_EN | SPI_PUP_EN;
+	writel(reg, ARMADA_XP_PUP_ENABLE_BASE);
+
 	return 0;
 }
 
diff --git a/arch/arm/mach-mvebu/include/mach/armada-370-xp-regs.h b/arch/arm/mach-mvebu/include/mach/armada-370-xp-regs.h
index ccc687c..bac27e5 100644
--- a/arch/arm/mach-mvebu/include/mach/armada-370-xp-regs.h
+++ b/arch/arm/mach-mvebu/include/mach/armada-370-xp-regs.h
@@ -30,6 +30,13 @@
 #define  SAR_TCLK_FREQ			BIT(20)
 #define  SAR_HIGH			0x04
 
+#define ARMADA_XP_PUP_ENABLE_BASE       (ARMADA_370_XP_INT_REGS_BASE + 0x1864c)
+#define  GE0_PUP_EN			BIT(0)
+#define  GE1_PUP_EN			BIT(1)
+#define  LCD_PUP_EN			BIT(2)
+#define  NAND_PUP_EN			BIT(4)
+#define  SPI_PUP_EN			BIT(5)
+
 #define ARMADA_370_XP_SDRAM_BASE	(ARMADA_370_XP_INT_REGS_BASE + 0x20000)
 #define  DDR_BASE_CS			0x180
 #define  DDR_BASE_CSn(n)		(DDR_BASE_CS + ((n) * 0x8))
-- 
2.1.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v3 2/4] net: phy: Support Marvell 88EE1545 PHY

[Ezequiel Garcia]

This commit adds support for Marvell's 88E1545 PHY chip. In particular, this
allows to support QSGMII interfaces.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/net/phy/marvell.c   | 58 +++++++++++++++++++++++++++++++++++++++++++++
 include/linux/marvell_phy.h |  1 +
 2 files changed, 59 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index f2bc649..3ea72e2 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -35,6 +35,13 @@
 #define MII_88E1121_PHY_MSCR_DELAY_MASK	\
 	(MII_88E1121_PHY_MSCR_RX_DELAY | MII_88E1121_PHY_MSCR_TX_DELAY)
 
+#define MII_88E1540_LED_PAGE		0x3
+#define MII_88E1540_LED_CONTROL		0x10
+
+#define MII_88E1540_QSGMII_PAGE		0x4
+#define MII_88E1540_QSGMII_CONTROL	0x0
+#define MII_88E1540_QSGMII_AUTONEG_EN	BIT(12)
+
 /*
  * marvell_read_status
  *
@@ -123,6 +130,48 @@ static int marvell_read_status(struct phy_device *phydev)
 	return 0;
 }
 
+static int m88e1540_config_init(struct phy_device *phydev)
+{
+	u16 reg;
+	int ret;
+
+	/* Configure QSGMII auto-negotiation */
+	if (phydev->interface == PHY_INTERFACE_MODE_QSGMII) {
+		ret = phy_write(phydev, MII_MARVELL_PHY_PAGE,
+				MII_88E1540_QSGMII_PAGE);
+		if (ret < 0)
+			return ret;
+
+		reg = phy_read(phydev, MII_88E1540_QSGMII_CONTROL);
+		ret = phy_write(phydev, MII_88E1540_QSGMII_CONTROL,
+					reg | MII_88E1540_QSGMII_AUTONEG_EN);
+		if (ret < 0)
+			return ret;
+	}
+
+	/* Configure LED as:
+	 * Activity: Blink
+	 * Link:     On
+	 * No Link:  Off
+	 */
+	phy_write(phydev, MII_MARVELL_PHY_PAGE, MII_88E1540_LED_PAGE);
+	phy_write(phydev, MII_88E1540_LED_CONTROL, 0x1111);
+
+	/* Power-up the PHY. When going from power down to normal operation,
+	 * software reset and auto-negotiation restart are also performed.
+	 */
+	ret = phy_write(phydev, MII_MARVELL_PHY_PAGE,
+				MII_MARVELL_PHY_DEFAULT_PAGE);
+	if (ret < 0)
+		return ret;
+	ret = phy_write(phydev, MII_BMCR,
+			phy_read(phydev, MII_BMCR) & ~BMCR_PDOWN);
+	if (ret < 0)
+		return ret;
+
+	return 0;
+}
+
 static int m88e1121_config_init(struct phy_device *phydev)
 {
 	u16 reg;
@@ -175,6 +224,15 @@ static struct phy_driver marvell_phys[] = {
 	.config_aneg	= genphy_config_aneg,
 	.read_status	= marvell_read_status,
 },
+{
+	.phy_id		= MARVELL_PHY_ID_88E1545,
+	.phy_id_mask	= MARVELL_PHY_ID_MASK,
+	.drv.name	= "Marvell 88E1545",
+	.features	= PHY_GBIT_FEATURES,
+	.config_init	= m88e1540_config_init,
+	.config_aneg	= genphy_config_aneg,
+	.read_status	= marvell_read_status,
+},
 };
 
 static int __init marvell_phy_init(void)
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index bf2c66a..deb75bf 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -27,6 +27,7 @@
 #define MARVELL_PHY_ID_88E1318S		0x01410e90
 #define MARVELL_PHY_ID_88E1116R		0x01410e40
 #define MARVELL_PHY_ID_88E1510		0x01410dd0
+#define MARVELL_PHY_ID_88E1545		0x01410eb0
 
 /* Mask used for ID comparisons */
 #define MARVELL_PHY_ID_MASK		0xfffffff0
-- 
2.1.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v3 3/4] net: phy: Support Marvell 88EE1543 PHY

[Ezequiel Garcia]

This commit adds support for Marvell's 88E1543 PHY chip. This chip is
almost identical to the 88EE1545, except the 88E1545 supports QSGMII
and the 88EE1543 supports SGMII.

Therefore, the same configuration function is used for both PHYs. For now,
the only initialization provided for the 88EE1543 is the LED setup.

Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/net/phy/marvell.c   | 9 +++++++++
 include/linux/marvell_phy.h | 1 +
 2 files changed, 10 insertions(+)

diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 3ea72e2..3248b48 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -233,6 +233,15 @@ static struct phy_driver marvell_phys[] = {
 	.config_aneg	= genphy_config_aneg,
 	.read_status	= marvell_read_status,
 },
+{
+	.phy_id		= MARVELL_PHY_ID_88E1543,
+	.phy_id_mask	= MARVELL_PHY_ID_MASK,
+	.drv.name	= "Marvell 88E1543",
+	.features	= PHY_GBIT_FEATURES,
+	.config_init	= m88e1540_config_init,
+	.config_aneg	= genphy_config_aneg,
+	.read_status	= marvell_read_status,
+},
 };
 
 static int __init marvell_phy_init(void)
diff --git a/include/linux/marvell_phy.h b/include/linux/marvell_phy.h
index deb75bf..b7baae1 100644
--- a/include/linux/marvell_phy.h
+++ b/include/linux/marvell_phy.h
@@ -27,6 +27,7 @@
 #define MARVELL_PHY_ID_88E1318S		0x01410e90
 #define MARVELL_PHY_ID_88E1116R		0x01410e40
 #define MARVELL_PHY_ID_88E1510		0x01410dd0
+#define MARVELL_PHY_ID_88E1543		0x01410ea0
 #define MARVELL_PHY_ID_88E1545		0x01410eb0
 
 /* Mask used for ID comparisons */
-- 
2.1.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 3/4] net: phy: Support Marvell 88EE1543 PHY

[Sascha Hauer]

Hi Ezequiel,

On Sun, Nov 09, 2014 at 11:56:17AM -0300, Ezequiel Garcia wrote:
> This commit adds support for Marvell's 88E1543 PHY chip. This chip is
> almost identical to the 88EE1545, except the 88E1545 supports QSGMII
> and the 88EE1543 supports SGMII.
> 
> Therefore, the same configuration function is used for both PHYs. For now,
> the only initialization provided for the 88EE1543 is the LED setup.
> 
> Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> ---
>  drivers/net/phy/marvell.c   | 9 +++++++++
>  include/linux/marvell_phy.h | 1 +
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 3ea72e2..3248b48 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -233,6 +233,15 @@ static struct phy_driver marvell_phys[] = {
>  	.config_aneg	= genphy_config_aneg,
>  	.read_status	= marvell_read_status,
>  },
> +{
> +	.phy_id		= MARVELL_PHY_ID_88E1543,
> +	.phy_id_mask	= MARVELL_PHY_ID_MASK,
> +	.drv.name	= "Marvell 88E1543",
> +	.features	= PHY_GBIT_FEATURES,
> +	.config_init	= m88e1540_config_init,
> +	.config_aneg	= genphy_config_aneg,
> +	.read_status	= marvell_read_status,
> +},
>  };

Could you fix the indentation before adding more elements to this array?
It should be

static struct phy_driver marvell_phys[] = {
	{
		...
	},
};

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

[PATCH v3 4/4] net: Add driver for Armada 370/XP 10/100/1000 Mbps network controller

[Ezequiel Garcia]

This patch introduces the mvneta driver to support the network controller
found in Armada 370/XP SoCs.

Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
---
 drivers/net/Kconfig  |   6 +
 drivers/net/Makefile |   1 +
 drivers/net/mvneta.c | 766 +++++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 773 insertions(+)
 create mode 100644 drivers/net/mvneta.c

diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 24b9844..724507f 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -137,6 +137,12 @@ config DRIVER_NET_MPC5200
 	depends on ARCH_MPC5200
 	select PHYLIB
 
+config DRIVER_NET_MVNETA
+	bool "Marvell NETA"
+	depends on ARCH_MVEBU
+	select PHYLIB
+	select MDIO_MVEBU
+
 config DRIVER_NET_NETX
 	bool "Hilscher Netx ethernet driver"
 	depends on HAS_NETX_ETHER
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 3e66b31..75a70be 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_DRIVER_NET_KS8851_MLL)	+= ks8851_mll.o
 obj-$(CONFIG_DRIVER_NET_MACB)		+= macb.o
 obj-$(CONFIG_DRIVER_NET_MICREL)		+= ksz8864rmn.o
 obj-$(CONFIG_DRIVER_NET_MPC5200)	+= fec_mpc5200.o
+obj-$(CONFIG_DRIVER_NET_MVNETA)		+= mvneta.o
 obj-$(CONFIG_DRIVER_NET_NETX)		+= netx_eth.o
 obj-$(CONFIG_DRIVER_NET_ORION)		+= orion-gbe.o
 obj-$(CONFIG_DRIVER_NET_RTL8139)	+= rtl8139.o
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
new file mode 100644
index 0000000..7734cf8
--- /dev/null
+++ b/drivers/net/mvneta.c
@@ -0,0 +1,766 @@
+/*
+ * (C) Copyright 2014 - Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
+ *
+ * based on mvneta driver from linux
+ *   (C) Copyright 2012 Marvell
+ *   Rami Rosen <rosenr@marvell.com>
+ *   Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
+ *
+ * based on orion-gbe driver from barebox
+ *   (C) Copyright 2014
+ *   Pengutronix, Michael Grzeschik <mgr@pengutronix.de>
+ *   Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <common.h>
+#include <init.h>
+#include <io.h>
+#include <net.h>
+#include <of_net.h>
+#include <sizes.h>
+#include <asm/mmu.h>
+#include <linux/clk.h>
+#include <linux/err.h>
+#include <linux/mbus.h>
+
+/* Registers */
+
+/* Rx queue */
+#define MVNETA_RXQ_CONFIG_REG(q)                (0x1400 + ((q) << 2))
+#define      MVNETA_RXQ_PKT_OFFSET_ALL_MASK     (0xf    << 8)
+#define      MVNETA_RXQ_PKT_OFFSET_MASK(offs)   ((offs) << 8)
+#define MVNETA_RXQ_THRESHOLD_REG(q)             (0x14c0 + ((q) << 2))
+#define      MVNETA_RXQ_NON_OCCUPIED(v)         ((v) << 16)
+#define MVNETA_RXQ_BASE_ADDR_REG(q)             (0x1480 + ((q) << 2))
+#define MVNETA_RXQ_SIZE_REG(q)                  (0x14a0 + ((q) << 2))
+#define      MVNETA_RXQ_BUF_SIZE_SHIFT          19
+#define      MVNETA_RXQ_BUF_SIZE_MASK           (0x1fff << 19)
+#define MVNETA_RXQ_STATUS_REG(q)                (0x14e0 + ((q) << 2))
+#define      MVNETA_RXQ_OCCUPIED_ALL_MASK       0x3fff
+#define MVNETA_RXQ_STATUS_UPDATE_REG(q)         (0x1500 + ((q) << 2))
+#define      MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT  16
+#define      MVNETA_RXQ_ADD_NON_OCCUPIED_MAX    255
+
+#define MVNETA_PORT_RX_RESET                    0x1cc0
+#define MVNETA_MBUS_RETRY                       0x2010
+#define MVNETA_UNIT_INTR_CAUSE                  0x2080
+#define MVNETA_UNIT_CONTROL                     0x20B0
+#define MVNETA_WIN_BASE(w)                      (0x2200 + ((w) << 3))
+#define MVNETA_WIN_SIZE(w)                      (0x2204 + ((w) << 3))
+#define MVNETA_WIN_REMAP(w)                     (0x2280 + ((w) << 2))
+#define MVNETA_BASE_ADDR_ENABLE                 0x2290
+#define MVNETA_PORT_CONFIG                      0x2400
+#define      MVNETA_DEF_RXQ(q)                  ((q) << 1)
+#define      MVNETA_DEF_RXQ_ARP(q)              ((q) << 4)
+#define      MVNETA_TX_UNSET_ERR_SUM            BIT(12)
+#define      MVNETA_DEF_RXQ_TCP(q)              ((q) << 16)
+#define      MVNETA_DEF_RXQ_UDP(q)              ((q) << 19)
+#define      MVNETA_DEF_RXQ_BPDU(q)             ((q) << 22)
+#define      MVNETA_RX_CSUM_WITH_PSEUDO_HDR     BIT(25)
+#define      MVNETA_PORT_CONFIG_DEFL_VALUE(q)   (MVNETA_DEF_RXQ(q)       | \
+						 MVNETA_DEF_RXQ_ARP(q)	 | \
+						 MVNETA_DEF_RXQ_TCP(q)	 | \
+						 MVNETA_DEF_RXQ_UDP(q)	 | \
+						 MVNETA_DEF_RXQ_BPDU(q)	 | \
+						 MVNETA_TX_UNSET_ERR_SUM | \
+						 MVNETA_RX_CSUM_WITH_PSEUDO_HDR)
+#define MVNETA_PORT_CONFIG_EXTEND                0x2404
+#define MVNETA_MAC_ADDR_LOW                      0x2414
+#define MVNETA_MAC_ADDR_HIGH                     0x2418
+#define MVNETA_SDMA_CONFIG                       0x241c
+#define      MVNETA_SDMA_BRST_SIZE_16            4
+#define      MVNETA_RX_BRST_SZ_MASK(burst)       ((burst) << 1)
+#define      MVNETA_RX_NO_DATA_SWAP              BIT(4)
+#define      MVNETA_TX_NO_DATA_SWAP              BIT(5)
+#define      MVNETA_DESC_SWAP                    BIT(6)
+#define      MVNETA_TX_BRST_SZ_MASK(burst)       ((burst) << 22)
+#define MVNETA_RX_MIN_FRAME_SIZE                 0x247c
+#define MVNETA_SERDES_CFG			 0x24a0
+#define      MVNETA_SGMII_SERDES		 0x0cc7
+#define      MVNETA_QSGMII_SERDES		 0x0667
+#define MVNETA_TYPE_PRIO                         0x24bc
+#define MVNETA_TXQ_CMD_1                         0x24e4
+#define MVNETA_TXQ_CMD                           0x2448
+#define      MVNETA_TXQ_DISABLE_SHIFT            8
+#define      MVNETA_TXQ_ENABLE_MASK              0x000000ff
+#define MVNETA_ACC_MODE                          0x2500
+#define MVNETA_CPU_MAP(cpu)                      (0x2540 + ((cpu) << 2))
+
+#define MVNETA_INTR_NEW_CAUSE                    0x25a0
+#define MVNETA_INTR_NEW_MASK                     0x25a4
+#define MVNETA_INTR_OLD_CAUSE                    0x25a8
+#define MVNETA_INTR_OLD_MASK                     0x25ac
+#define MVNETA_INTR_MISC_CAUSE                   0x25b0
+#define MVNETA_INTR_MISC_MASK                    0x25b4
+#define MVNETA_INTR_ENABLE                       0x25b8
+
+#define MVNETA_RXQ_CMD                           0x2680
+#define      MVNETA_RXQ_DISABLE_SHIFT            8
+#define      MVNETA_RXQ_ENABLE_MASK              0x000000ff
+#define MVETH_TXQ_TOKEN_COUNT_REG(q)             (0x2700 + ((q) << 4))
+#define MVETH_TXQ_TOKEN_CFG_REG(q)               (0x2704 + ((q) << 4))
+#define MVNETA_GMAC_CTRL_0                       0x2c00
+#define MVNETA_GMAC_CTRL_2                       0x2c08
+#define      MVNETA_GMAC2_PCS_ENABLE             BIT(3)
+#define      MVNETA_GMAC2_PORT_RGMII             BIT(4)
+#define      MVNETA_GMAC2_PORT_RESET             BIT(6)
+#define MVNETA_GMAC_AUTONEG_CONFIG               0x2c0c
+#define      MVNETA_GMAC_FORCE_LINK_DOWN         BIT(0)
+#define      MVNETA_GMAC_FORCE_LINK_PASS         BIT(1)
+#define      MVNETA_GMAC_CONFIG_MII_SPEED        BIT(5)
+#define      MVNETA_GMAC_CONFIG_GMII_SPEED       BIT(6)
+#define      MVNETA_GMAC_AN_SPEED_EN             BIT(7)
+#define      MVNETA_GMAC_CONFIG_FLOWCTRL         BIT(8)
+#define      MVNETA_GMAC_CONFIG_FULL_DUPLEX      BIT(12)
+#define      MVNETA_GMAC_AN_FLOWCTRL_EN          BIT(11)
+#define      MVNETA_GMAC_AN_DUPLEX_EN            BIT(13)
+#define MVNETA_MIB_COUNTERS_BASE                 0x3080
+#define      MVNETA_MIB_LATE_COLLISION           0x7c
+#define MVNETA_DA_FILT_SPEC_MCAST                0x3400
+#define MVNETA_DA_FILT_OTH_MCAST                 0x3500
+#define MVNETA_DA_FILT_UCAST_BASE                0x3600
+#define MVNETA_TXQ_BASE_ADDR_REG(q)              (0x3c00 + ((q) << 2))
+#define MVNETA_TXQ_SIZE_REG(q)                   (0x3c20 + ((q) << 2))
+#define MVNETA_TXQ_UPDATE_REG(q)                 (0x3c60 + ((q) << 2))
+#define      MVNETA_TXQ_DEC_SENT_SHIFT           16
+#define MVNETA_TXQ_STATUS_REG(q)                 (0x3c40 + ((q) << 2))
+#define MVNETA_PORT_TX_RESET                     0x3cf0
+#define MVNETA_TX_MTU                            0x3e0c
+#define MVNETA_TX_TOKEN_SIZE                     0x3e14
+#define MVNETA_TXQ_TOKEN_SIZE_REG(q)             (0x3e40 + ((q) << 2))
+
+/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
+ * layout of the transmit and reception DMA descriptors, and their
+ * layout is therefore defined by the hardware design
+ */
+
+#define MVNETA_TX_L3_OFF_SHIFT	0
+#define MVNETA_TX_IP_HLEN_SHIFT	8
+#define MVNETA_TX_L4_UDP	BIT(16)
+#define MVNETA_TX_L3_IP6	BIT(17)
+#define MVNETA_TXD_IP_CSUM	BIT(18)
+#define MVNETA_TXD_Z_PAD	BIT(19)
+#define MVNETA_TXD_L_DESC	BIT(20)
+#define MVNETA_TXD_F_DESC	BIT(21)
+#define MVNETA_TXD_FLZ_DESC	(MVNETA_TXD_Z_PAD  | \
+				 MVNETA_TXD_L_DESC | \
+				 MVNETA_TXD_F_DESC)
+#define MVNETA_TX_L4_CSUM_FULL	BIT(30)
+#define MVNETA_TX_L4_CSUM_NOT	BIT(31)
+
+#define MVNETA_TXD_ERROR	BIT(0)
+#define TXD_ERROR_MASK		0x6
+#define TXD_ERROR_SHIFT		1
+
+#define MVNETA_RXD_ERR_CRC		0x0
+#define MVNETA_RXD_ERR_SUMMARY		BIT(16)
+#define MVNETA_RXD_ERR_OVERRUN		BIT(17)
+#define MVNETA_RXD_ERR_LEN		BIT(18)
+#define MVNETA_RXD_ERR_RESOURCE		(BIT(17) | BIT(18))
+#define MVNETA_RXD_ERR_CODE_MASK	(BIT(17) | BIT(18))
+#define MVNETA_RXD_L3_IP4		BIT(25)
+#define MVNETA_RXD_FIRST_LAST_DESC	(BIT(26) | BIT(27))
+#define MVNETA_RXD_L4_CSUM_OK		BIT(30)
+
+#define MVNETA_MH_SIZE		2
+#define TXQ_NUM			8
+#define RX_RING_SIZE		4
+#define TRANSFER_TIMEOUT	(10 * MSECOND)
+
+struct rxdesc {
+	u32  cmd_sts;		/* Info about received packet		*/
+	u16  reserved1;		/* pnc_info - (for future use, PnC)	*/
+	u16  data_size;		/* Size of received packet in bytes	*/
+
+	u32  buf_phys_addr;	/* Physical address of the buffer	*/
+	u32  reserved2;		/* pnc_flow_id  (for future use, PnC)	*/
+
+	u32  buf_cookie;	/* cookie for access to RX buffer in rx path */
+	u16  reserved3;		/* prefetch_cmd, for future use		*/
+	u16  reserved4;		/* csum_l4 - (for future use, PnC)	*/
+
+	u32  reserved5;		/* pnc_extra PnC (for future use, PnC)	*/
+	u32  reserved6;		/* hw_cmd (for future use, PnC and HWF)	*/
+};
+
+struct txdesc {
+	u32  cmd_sts;		/* Options used by HW for packet transmitting.*/
+	u16  reserverd1;	/* csum_l4 (for future use)		*/
+	u16  byte_cnt;		/* Data size of transmitted packet in bytes */
+	u32  buf_ptr;		/* Physical addr of transmitted buffer	*/
+	u8   error;		/*					*/
+	u8   reserved2;		/* Reserved - (for future use)		*/
+	u16  reserved3;		/* Reserved - (for future use)		*/
+	u32  reserved4[4];	/* Reserved - (for future use)		*/
+};
+
+struct mvneta_port {
+	void __iomem *reg;
+	struct device_d dev;
+	struct eth_device edev;
+	struct clk *clk;
+
+	struct txdesc *txdesc;
+	struct rxdesc *rxdesc;
+	int curr_rxdesc;
+	u8 *rxbuf;
+	phy_interface_t intf;
+};
+
+static void mvneta_conf_mbus_windows(struct mvneta_port *priv)
+{
+	const struct mbus_dram_target_info *dram = mvebu_mbus_dram_info();
+	u32 win_enable, win_protect;
+	int i;
+
+	for (i = 0; i < 6; i++) {
+		writel(0, priv->reg + MVNETA_WIN_BASE(i));
+		writel(0, priv->reg + MVNETA_WIN_SIZE(i));
+
+		if (i < 4)
+			writel(0, priv->reg + MVNETA_WIN_REMAP(i));
+	}
+
+	win_enable = 0x3f;
+	win_protect = 0;
+
+	for (i = 0; i < dram->num_cs; i++) {
+		const struct mbus_dram_window *cs = dram->cs + i;
+
+		writel((cs->base & 0xffff0000) |
+		       (cs->mbus_attr << 8) |
+		       dram->mbus_dram_target_id,
+		       priv->reg + MVNETA_WIN_BASE(i));
+
+		writel((cs->size - 1) & 0xffff0000,
+		       priv->reg + MVNETA_WIN_SIZE(i));
+
+		win_enable &= ~(1 << i);
+		win_protect |= 3 << (2 * i);
+	}
+
+	writel(win_enable, priv->reg + MVNETA_BASE_ADDR_ENABLE);
+}
+
+static void mvneta_clear_mcast_table(struct mvneta_port *priv)
+{
+	int offset;
+
+	for (offset = 0; offset <= 0xfc; offset += 4) {
+		writel(0, priv->reg + MVNETA_DA_FILT_UCAST_BASE + offset);
+		writel(0, priv->reg + MVNETA_DA_FILT_SPEC_MCAST + offset);
+		writel(0, priv->reg + MVNETA_DA_FILT_OTH_MCAST + offset);
+	}
+}
+
+/* Set unicast address */
+static void mvneta_set_ucast_addr(struct mvneta_port *priv, u8 last_nibble)
+{
+	unsigned int tbl_offset, reg_offset;
+	int queue = 0;
+	u32 val;
+
+	/* Locate the Unicast table entry */
+	last_nibble = (0xf & last_nibble);
+
+	/* offset from unicast tbl base */
+	tbl_offset = (last_nibble / 4) * 4;
+
+	/* offset within the above reg  */
+	reg_offset = last_nibble % 4;
+
+	val = readl(priv->reg + MVNETA_DA_FILT_UCAST_BASE + tbl_offset);
+
+	val &= ~(0xff << (8 * reg_offset));
+	val |= ((0x01 | (queue << 1)) << (8 * reg_offset));
+
+	writel(val, priv->reg + MVNETA_DA_FILT_UCAST_BASE + tbl_offset);
+}
+
+static void mvneta_clear_ucast_addr(struct mvneta_port *priv, u8 last_nibble)
+{
+	unsigned int tbl_offset, reg_offset;
+	u32 val;
+
+	/* Locate the Unicast table entry */
+	last_nibble = (0xf & last_nibble);
+
+	/* offset from unicast tbl base */
+	tbl_offset = (last_nibble / 4) * 4;
+
+	/* offset within the above reg  */
+	reg_offset = last_nibble % 4;
+
+	val = readl(priv->reg + MVNETA_DA_FILT_UCAST_BASE + tbl_offset);
+
+	/* Clear accepts frame bit at specified unicast DA tbl entry */
+	val &= ~(0xff << (8 * reg_offset));
+
+	writel(val, priv->reg + MVNETA_DA_FILT_UCAST_BASE + tbl_offset);
+}
+
+static void mvneta_rx_unicast_promisc_clear(struct mvneta_port *priv)
+{
+	u32 portcfg, val;
+
+	portcfg = readl(priv->reg + MVNETA_PORT_CONFIG);
+	val = readl(priv->reg + MVNETA_TYPE_PRIO);
+
+	/* Reject all Unicast addresses */
+	writel(portcfg & ~BIT(0), priv->reg + MVNETA_PORT_CONFIG);
+	writel(val & ~BIT(21), priv->reg + MVNETA_TYPE_PRIO);
+}
+
+/* Clear all MIB counters */
+static void mvneta_mib_counters_clear(struct mvneta_port *priv)
+{
+	int i;
+
+	/* Perform dummy reads from MIB counters */
+	for (i = 0; i < MVNETA_MIB_LATE_COLLISION; i += 4)
+		readl(priv->reg + MVNETA_MIB_COUNTERS_BASE + i);
+}
+
+static int mvneta_pending_tx(struct mvneta_port *priv)
+{
+	u32 val = readl(priv->reg + MVNETA_TXQ_STATUS_REG(0));
+
+	return val & 0x3fff;
+}
+
+static int mvneta_pending_rx(struct mvneta_port *priv)
+{
+	u32 val = readl(priv->reg + MVNETA_RXQ_STATUS_REG(0));
+
+	return val & 0x3fff;
+}
+
+static void mvneta_port_stop(struct mvneta_port *priv)
+{
+	u32 val;
+
+	/* Stop all queues */
+	writel(0xff << MVNETA_RXQ_DISABLE_SHIFT, priv->reg + MVNETA_RXQ_CMD);
+	writel(0xff << MVNETA_TXQ_DISABLE_SHIFT, priv->reg + MVNETA_TXQ_CMD);
+
+	/* Reset Tx */
+	writel(BIT(0), priv->reg + MVNETA_PORT_TX_RESET);
+	writel(0, priv->reg + MVNETA_PORT_TX_RESET);
+
+	/* Reset Rx */
+	writel(BIT(0), priv->reg + MVNETA_PORT_RX_RESET);
+	writel(0, priv->reg + MVNETA_PORT_RX_RESET);
+
+	/* Disable port 0 */
+	val = readl(priv->reg + MVNETA_GMAC_CTRL_0);
+	writel(val & ~BIT(0), priv->reg + MVNETA_GMAC_CTRL_0);
+	udelay(200);
+
+	/* Clear all Cause registers */
+	writel(0, priv->reg + MVNETA_INTR_NEW_CAUSE);
+	writel(0, priv->reg + MVNETA_INTR_OLD_CAUSE);
+	writel(0, priv->reg + MVNETA_INTR_MISC_CAUSE);
+	writel(0, priv->reg + MVNETA_UNIT_INTR_CAUSE);
+
+	/* Mask all interrupts */
+	writel(0, priv->reg + MVNETA_INTR_NEW_MASK);
+	writel(0, priv->reg + MVNETA_INTR_OLD_MASK);
+	writel(0, priv->reg + MVNETA_INTR_MISC_MASK);
+	writel(0, priv->reg + MVNETA_INTR_ENABLE);
+}
+
+static void mvneta_halt(struct eth_device *edev)
+{
+	mvneta_port_stop((struct mvneta_port *)edev->priv);
+}
+
+static int mvneta_send(struct eth_device *edev, void *data, int len)
+{
+	struct mvneta_port *priv = edev->priv;
+	struct txdesc *txdesc = priv->txdesc;
+	int ret, error, last_desc;
+
+	/* Flush transmit data */
+	dma_flush_range((unsigned long)data, (unsigned long)data+len);
+
+	/* Fill the Tx descriptor */
+	txdesc->cmd_sts |= MVNETA_TX_L4_CSUM_NOT | MVNETA_TXD_FLZ_DESC;
+	txdesc->buf_ptr = (u32)data;
+	txdesc->byte_cnt = len;
+
+	/* Increase the number of prepared descriptors (one), by writing
+	 * to the 'NoOfWrittenDescriptors' field in the PTXSU register.
+	 */
+	writel(1, priv->reg + MVNETA_TXQ_UPDATE_REG(0));
+
+	/* The controller updates the number of transmitted descriptors in
+	 * the Tx port status register (PTXS).
+	 */
+	ret = wait_on_timeout(TRANSFER_TIMEOUT, !mvneta_pending_tx(priv));
+	if (ret) {
+		dev_err(&edev->dev, "transmit timeout\n");
+		return ret;
+	}
+
+	last_desc = readl(&txdesc->cmd_sts) & MVNETA_TXD_L_DESC;
+	error = readl(&txdesc->error);
+	if (last_desc && error & MVNETA_TXD_ERROR) {
+		dev_err(&edev->dev, "transmit error %d\n",
+			(error & TXD_ERROR_MASK) >> TXD_ERROR_SHIFT);
+		return -EIO;
+	}
+
+	/* Release the transmitted descriptor by writing to the
+	 * 'NoOfReleasedBuffers' field in the PTXSU register.
+	 */
+	writel(1 << MVNETA_TXQ_DEC_SENT_SHIFT,
+	       priv->reg + MVNETA_TXQ_UPDATE_REG(0));
+
+	return 0;
+}
+
+static int mvneta_recv(struct eth_device *edev)
+{
+	struct mvneta_port *priv = edev->priv;
+	struct rxdesc *rxdesc = &priv->rxdesc[priv->curr_rxdesc];
+	int ret, pending;
+	u32 cmd_sts;
+
+	/* wait for received packet */
+	pending = mvneta_pending_rx(priv);
+	if (!pending)
+		return 0;
+
+	/* drop malicious packets */
+	cmd_sts = readl(&rxdesc->cmd_sts);
+	if ((cmd_sts & MVNETA_RXD_FIRST_LAST_DESC) !=
+	    MVNETA_RXD_FIRST_LAST_DESC) {
+		dev_err(&edev->dev, "rx packet spread on multiple descriptors\n");
+		ret = -EIO;
+		goto recv_err;
+	}
+
+	if (cmd_sts & MVNETA_RXD_ERR_SUMMARY) {
+		dev_err(&edev->dev, "receive error\n");
+		ret = -EIO;
+		goto recv_err;
+	}
+
+	/* invalidate current receive buffer */
+	dma_inv_range((unsigned long)rxdesc->buf_phys_addr,
+		      (unsigned long)rxdesc->buf_phys_addr +
+		      ALIGN(PKTSIZE, 8));
+
+	/* received packet is padded with two null bytes (Marvell header) */
+	net_receive(edev, (void *)(rxdesc->buf_phys_addr + MVNETA_MH_SIZE),
+			  rxdesc->data_size - MVNETA_MH_SIZE);
+	ret = 0;
+
+recv_err:
+	/* reset this and get next rx descriptor*/
+	rxdesc->data_size = 0;
+	rxdesc->cmd_sts = 0;
+
+	priv->curr_rxdesc++;
+	if (priv->curr_rxdesc == RX_RING_SIZE)
+		priv->curr_rxdesc = 0;
+
+	/* Descriptor processed and refilled */
+	writel(1 | 1 << MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT,
+	       priv->reg + MVNETA_RXQ_STATUS_UPDATE_REG(0));
+	return ret;
+}
+
+static int mvneta_set_ethaddr(struct eth_device *edev, unsigned char *mac)
+{
+	struct mvneta_port *priv = edev->priv;
+	u32 mac_h = (mac[0] << 24) | (mac[1] << 16) | (mac[2] << 8) | mac[3];
+	u32 mac_l = (mac[4] << 8) | mac[5];
+
+	mvneta_clear_ucast_addr(priv, mac[5]);
+
+	writel(mac_l, priv->reg + MVNETA_MAC_ADDR_LOW);
+	writel(mac_h, priv->reg + MVNETA_MAC_ADDR_HIGH);
+
+	/* accept frames for this address */
+	mvneta_set_ucast_addr(priv, mac[5]);
+
+	return 0;
+}
+
+static int mvneta_get_ethaddr(struct eth_device *edev, unsigned char *mac)
+{
+	struct mvneta_port *priv = edev->priv;
+	u32 mac_l = readl(priv->reg + MVNETA_MAC_ADDR_LOW);
+	u32 mac_h = readl(priv->reg + MVNETA_MAC_ADDR_HIGH);
+
+	mac[0] = (mac_h >> 24) & 0xff;
+	mac[1] = (mac_h >> 16) & 0xff;
+	mac[2] = (mac_h >> 8) & 0xff;
+	mac[3] = mac_h & 0xff;
+	mac[4] = (mac_l >> 8) & 0xff;
+	mac[5] = mac_l & 0xff;
+
+	return 0;
+}
+
+static void mvneta_adjust_link(struct eth_device *edev)
+{
+	struct mvneta_port *priv = edev->priv;
+	struct phy_device *phy = edev->phydev;
+	u32 val;
+
+	if (!phy->link)
+		return;
+
+	val = readl(priv->reg + MVNETA_GMAC_AUTONEG_CONFIG);
+	val &= ~(MVNETA_GMAC_CONFIG_MII_SPEED |
+		 MVNETA_GMAC_CONFIG_GMII_SPEED |
+		 MVNETA_GMAC_CONFIG_FULL_DUPLEX |
+		 MVNETA_GMAC_AN_SPEED_EN |
+		 MVNETA_GMAC_AN_FLOWCTRL_EN |
+		 MVNETA_GMAC_AN_DUPLEX_EN);
+
+	if (phy->speed == SPEED_1000)
+		val |= MVNETA_GMAC_CONFIG_GMII_SPEED;
+	else if (phy->speed == SPEED_100)
+		val |= MVNETA_GMAC_CONFIG_MII_SPEED;
+
+	if (phy->duplex)
+		val |= MVNETA_GMAC_CONFIG_FULL_DUPLEX;
+
+	if (phy->pause)
+		val |= MVNETA_GMAC_CONFIG_FLOWCTRL;
+
+	val |= MVNETA_GMAC_FORCE_LINK_PASS | MVNETA_GMAC_FORCE_LINK_DOWN;
+
+	writel(val, priv->reg + MVNETA_GMAC_AUTONEG_CONFIG);
+
+	mvneta_mib_counters_clear(priv);
+
+	/* Enable first Tx and first Rx queues */
+	writel(BIT(0), priv->reg + MVNETA_TXQ_CMD);
+	writel(BIT(0), priv->reg + MVNETA_RXQ_CMD);
+}
+
+static int mvneta_open(struct eth_device *edev)
+{
+	struct mvneta_port *priv = edev->priv;
+	int ret;
+	u32 val;
+
+	ret = phy_device_connect(&priv->edev, NULL, -1,
+				 mvneta_adjust_link, 0, priv->intf);
+	if (ret)
+		return ret;
+
+	/* Enable the first port */
+	val = readl(priv->reg + MVNETA_GMAC_CTRL_0);
+	writel(val | BIT(0), priv->reg + MVNETA_GMAC_CTRL_0);
+
+	return 0;
+}
+
+static void mvneta_init_rx_ring(struct mvneta_port *priv)
+{
+	int i;
+
+	for (i = 0; i < RX_RING_SIZE; i++) {
+		struct rxdesc *desc = &priv->rxdesc[i];
+
+		desc->buf_phys_addr = (u32)priv->rxbuf + i * ALIGN(PKTSIZE, 8);
+	}
+
+	priv->curr_rxdesc = 0;
+}
+
+void mvneta_setup_tx_rx(struct mvneta_port *priv)
+{
+	u32 val;
+
+	/* Allocate descriptors and buffers */
+	priv->txdesc = dma_alloc_coherent(ALIGN(sizeof(*priv->txdesc), 32));
+	priv->rxdesc = dma_alloc_coherent(RX_RING_SIZE *
+					  ALIGN(sizeof(*priv->rxdesc), 32));
+	priv->rxbuf = dma_alloc(RX_RING_SIZE * ALIGN(PKTSIZE, 8));
+
+	mvneta_init_rx_ring(priv);
+
+	/* Configure the Rx queue */
+	val = readl(priv->reg + MVNETA_RXQ_CONFIG_REG(0));
+	val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
+	writel(val, priv->reg + MVNETA_RXQ_CONFIG_REG(0));
+
+	/* Configure the Tx descriptor */
+	writel(1, priv->reg + MVNETA_TXQ_SIZE_REG(0));
+	writel((u32)priv->txdesc, priv->reg + MVNETA_TXQ_BASE_ADDR_REG(0));
+
+	/* Configure the Rx descriptor. Packet size is in 8-byte units. */
+	val = RX_RING_SIZE;
+	val |= ((PKTSIZE >> 3) << MVNETA_RXQ_BUF_SIZE_SHIFT);
+	writel(val , priv->reg + MVNETA_RXQ_SIZE_REG(0));
+	writel((u32)priv->rxdesc, priv->reg + MVNETA_RXQ_BASE_ADDR_REG(0));
+
+	/* Set the number of available Rx descriptors */
+	writel(RX_RING_SIZE << MVNETA_RXQ_ADD_NON_OCCUPIED_SHIFT,
+	       priv->reg + MVNETA_RXQ_STATUS_UPDATE_REG(0));
+}
+
+static int mvneta_port_config(struct mvneta_port *priv)
+{
+	int queue;
+	u32 val;
+
+	/* Enable MBUS Retry bit16 */
+	writel(0x20, priv->reg + MVNETA_MBUS_RETRY);
+
+	/* Map the first Tx queue and first Rx queue to CPU0 */
+	writel(BIT(0) | (BIT(0) << 8), priv->reg + MVNETA_CPU_MAP(0));
+
+	/* Reset Tx/Rx DMA */
+	writel(BIT(0), priv->reg + MVNETA_PORT_TX_RESET);
+	writel(BIT(0), priv->reg + MVNETA_PORT_RX_RESET);
+
+	/* Disable Legacy WRR, Disable EJP, Release from reset */
+	writel(0, priv->reg + MVNETA_TXQ_CMD_1);
+
+	/* Set maximum bandwidth for the first TX queue */
+	writel(0x3ffffff, priv->reg + MVETH_TXQ_TOKEN_CFG_REG(0));
+	writel(0x3ffffff, priv->reg + MVETH_TXQ_TOKEN_COUNT_REG(0));
+
+	/* Minimum bandwidth on the rest of them */
+	for (queue = 1; queue < TXQ_NUM; queue++) {
+		writel(0, priv->reg + MVETH_TXQ_TOKEN_COUNT_REG(queue));
+		writel(0, priv->reg + MVETH_TXQ_TOKEN_CFG_REG(queue));
+	}
+
+	writel(0, priv->reg + MVNETA_PORT_RX_RESET);
+	writel(0, priv->reg + MVNETA_PORT_TX_RESET);
+
+	/* Disable hardware PHY polling */
+	val = readl(priv->reg + MVNETA_UNIT_CONTROL);
+	writel(val & ~BIT(1), priv->reg + MVNETA_UNIT_CONTROL);
+
+	/* Port Acceleration Mode */
+	writel(0x1, priv->reg + MVNETA_ACC_MODE);
+
+	/* Port default configuration for the first Rx queue */
+	val = MVNETA_PORT_CONFIG_DEFL_VALUE(0);
+	writel(val, priv->reg + MVNETA_PORT_CONFIG);
+	writel(0, priv->reg + MVNETA_PORT_CONFIG_EXTEND);
+	writel(64, priv->reg + MVNETA_RX_MIN_FRAME_SIZE);
+
+	/* Default burst size */
+	val = 0;
+	val |= MVNETA_TX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
+	val |= MVNETA_RX_BRST_SZ_MASK(MVNETA_SDMA_BRST_SIZE_16);
+	val |= MVNETA_RX_NO_DATA_SWAP | MVNETA_TX_NO_DATA_SWAP;
+	writel(val, priv->reg + MVNETA_SDMA_CONFIG);
+
+	mvneta_clear_mcast_table(priv);
+	mvneta_rx_unicast_promisc_clear(priv);
+
+	/* Configure maximum MTU and token size */
+	writel(0x0003ffff, priv->reg + MVNETA_TX_MTU);
+	writel(0xffffffff, priv->reg + MVNETA_TX_TOKEN_SIZE);
+	writel(0x7fffffff, priv->reg + MVNETA_TXQ_TOKEN_SIZE_REG(0));
+
+	val = readl(priv->reg + MVNETA_GMAC_CTRL_2);
+
+	/* Even though it might look weird, when we're configured in
+	 * SGMII or QSGMII mode, the RGMII bit needs to be set.
+	 */
+	switch (priv->intf) {
+	case PHY_INTERFACE_MODE_QSGMII:
+		writel(MVNETA_QSGMII_SERDES, priv->reg + MVNETA_SERDES_CFG);
+		val |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_SGMII:
+		writel(MVNETA_SGMII_SERDES, priv->reg + MVNETA_SERDES_CFG);
+		val |= MVNETA_GMAC2_PCS_ENABLE | MVNETA_GMAC2_PORT_RGMII;
+		break;
+	case PHY_INTERFACE_MODE_RGMII:
+	case PHY_INTERFACE_MODE_RGMII_ID:
+	case PHY_INTERFACE_MODE_RGMII_TXID:
+	case PHY_INTERFACE_MODE_RGMII_RXID:
+		val |= MVNETA_GMAC2_PORT_RGMII;
+		break;
+	default:
+		return -EINVAL;
+	}
+
+	/* Cancel Port Reset */
+	val &= ~MVNETA_GMAC2_PORT_RESET;
+	writel(val, priv->reg + MVNETA_GMAC_CTRL_2);
+	while (readl(priv->reg + MVNETA_GMAC_CTRL_2) & MVNETA_GMAC2_PORT_RESET)
+		continue;
+
+	return 0;
+}
+
+static int mvneta_probe(struct device_d *dev)
+{
+	struct mvneta_port *priv;
+	int ret;
+
+	priv = xzalloc(sizeof(*priv));
+
+	priv->reg = dev_get_mem_region(dev, 0);
+
+	priv->clk = clk_get(dev, 0);
+	if (IS_ERR(priv->clk))
+		return PTR_ERR(priv->clk);
+	clk_enable(priv->clk);
+
+	ret = of_get_phy_mode(dev->device_node);
+	if (ret < 0)
+		return ret;
+	priv->intf = ret;
+
+	mvneta_port_stop(priv);
+
+	ret = mvneta_port_config(priv);
+	if (ret)
+		return ret;
+
+	mvneta_conf_mbus_windows(priv);
+	mvneta_setup_tx_rx(priv);
+
+	/* register eth device */
+	priv->edev.priv = priv;
+	priv->edev.open = mvneta_open;
+	priv->edev.send = mvneta_send;
+	priv->edev.recv = mvneta_recv;
+	priv->edev.halt = mvneta_halt;
+	priv->edev.set_ethaddr = mvneta_set_ethaddr;
+	priv->edev.get_ethaddr = mvneta_get_ethaddr;
+	priv->edev.parent = dev;
+
+	ret = eth_register(&priv->edev);
+	if (ret)
+		return ret;
+	return 0;
+}
+
+static struct of_device_id mvneta_dt_ids[] = {
+	{ .compatible = "marvell,armada-370-neta", },
+	{ }
+};
+
+static struct driver_d mvneta_driver = {
+	.name   = "mvneta",
+	.probe  = mvneta_probe,
+	.of_compatible = DRV_OF_COMPAT(mvneta_dt_ids),
+};
+device_platform_driver(mvneta_driver);
-- 
2.1.0


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hello Ezequiel,

On Sun, Nov 09, 2014 at 11:56:14AM -0300, Ezequiel Garcia wrote:
> Very delayed third round of the support for the network controller present
> on Marvell Armada 370/XP SoC.
> 
> The first patch enables the peripherals in a PUP register, which is required
> on RGMII ports.
> 
> The second and third patches add support for Marvell's 88E1543 and 88E1545 PHY
> chips.
> 
> The fourth patch adds the mvneta driver. Most of the configuration part is
> based on Linux's mvneta driver, while some of code organization is based
> on Barebox's orion-gbe driver.
I tested this series on top of 784b352aeeed with a patch to support my
ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage
booting from U-Boot, similar to mirabox with
armada-370-netgear-rn104.dts from next-20141106).

	Marvell>> tftp start_netgear_rn104.pblx
	Using egiga1 device
	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
	Filename 'start_netgear_rn104.pblx'.
	Load address: 0x2000000
	Loading: ####################
	done
	Bytes transferred = 292148 (47534 hex)
	Marvell>> go 0x2000000
	## Starting application at 0x02000000 ...


	barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014


	Board: NETGEAR ReadyNAS 104
	SoC: Marvell 6710 rev 1
	mdio_bus: miibus0: probed
	eth1: got preset MAC address: 28:c6:8e:36:df:57
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
	environment load /dev/env0: No such file or directory
	Maybe you have to create the partition.
	no valid environment found on /dev/env0. Using default environment
	running /env/bin/init...
	/env/bin/init not found
	barebox:/ ethact eth1
	barebox:/ dhcp
	eth1: 1000Mbps full duplex link detected
	T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out
	dhcp: Connection timed out
	barebox:/ eth1.ipaddr=192.168.77.133
	barebox:/ eth1.netmask=255.255.255.0
	barebox:/ echo $eth1.ethaddr
	28:c6:8e:36:df:57
	barebox:/ ping 192.168.77.157
	T T T T T ping failed: Connection timed out
	barebox:/ 

tcpdump on 192.168.77.157 (which is connected via a switch) worked just
fine from U-Boot, after all it served the barebox image.

The pca9554 i2c device is only used for leds, so I don't think the error
messages above are related.

Yesterday I saw a different error, that I cannot reproduce now with the
same barebox image. IIRC I first played around a bit with eth0 until
noticing that I need eth1. I didn't save the full log, but it resulted
in:

	barebox:/ ethact eth1
	barebox:/ dhcp
	eth1: 1000Mbps full duplex link detected
	eth1: transmit error 3
	dhcp failed: I/O error
	dhcp: I/O error

Any ideas? I can try to use a dtb without pinmux definitions later
today.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Ezequiel Garcia]

On 11/10/2014 05:06 AM, Uwe Kleine-König wrote:
> Hello Ezequiel,
> 
> On Sun, Nov 09, 2014 at 11:56:14AM -0300, Ezequiel Garcia wrote:
>> Very delayed third round of the support for the network controller present
>> on Marvell Armada 370/XP SoC.
>>
>> The first patch enables the peripherals in a PUP register, which is required
>> on RGMII ports.
>>
>> The second and third patches add support for Marvell's 88E1543 and 88E1545 PHY
>> chips.
>>
>> The fourth patch adds the mvneta driver. Most of the configuration part is
>> based on Linux's mvneta driver, while some of code organization is based
>> on Barebox's orion-gbe driver.
> I tested this series on top of 784b352aeeed with a patch to support my
> ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage
> booting from U-Boot, similar to mirabox with
> armada-370-netgear-rn104.dts from next-20141106).
> 
> 	Marvell>> tftp start_netgear_rn104.pblx
> 	Using egiga1 device
> 	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
> 	Filename 'start_netgear_rn104.pblx'.
> 	Load address: 0x2000000
> 	Loading: ####################
> 	done
> 	Bytes transferred = 292148 (47534 hex)
> 	Marvell>> go 0x2000000
> 	## Starting application at 0x02000000 ...
> 
> 
> 	barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014
> 
> 
> 	Board: NETGEAR ReadyNAS 104
> 	SoC: Marvell 6710 rev 1
> 	mdio_bus: miibus0: probed
> 	eth1: got preset MAC address: 28:c6:8e:36:df:57
> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> 	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
> 	environment load /dev/env0: No such file or directory
> 	Maybe you have to create the partition.
> 	no valid environment found on /dev/env0. Using default environment
> 	running /env/bin/init...
> 	/env/bin/init not found
> 	barebox:/ ethact eth1
> 	barebox:/ dhcp
> 	eth1: 1000Mbps full duplex link detected
> 	T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out
> 	dhcp: Connection timed out
> 	barebox:/ eth1.ipaddr=192.168.77.133
> 	barebox:/ eth1.netmask=255.255.255.0
> 	barebox:/ echo $eth1.ethaddr
> 	28:c6:8e:36:df:57
> 	barebox:/ ping 192.168.77.157
> 	T T T T T ping failed: Connection timed out
> 	barebox:/ 
> 
> tcpdump on 192.168.77.157 (which is connected via a switch) worked just
> fine from U-Boot, after all it served the barebox image.
> 
> The pca9554 i2c device is only used for leds, so I don't think the error
> messages above are related.
> 
> Yesterday I saw a different error, that I cannot reproduce now with the
> same barebox image. IIRC I first played around a bit with eth0 until
> noticing that I need eth1. I didn't save the full log, but it resulted
> in:
> 
> 	barebox:/ ethact eth1
> 	barebox:/ dhcp
> 	eth1: 1000Mbps full duplex link detected
> 	eth1: transmit error 3
> 	dhcp failed: I/O error
> 	dhcp: I/O error
> 
> Any ideas? I can try to use a dtb without pinmux definitions later
> today.
> 

Hm, not really. I've tested this with my Armada 370 Mirabox and Armada
XP Openblocks AX3-4 boards (I use kwboot to load the barebox image, so I
don't jump from U-Boot).

I guess we must be missing some config. What's confusing is that the
Mirabox and the RN104 should be pretty similar in this regard (e.g. they
use the same phy mode).

Sebastian, do you have any ideas?
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hello Ezequiel,

On Mon, Nov 10, 2014 at 03:10:56PM -0300, Ezequiel Garcia wrote:
> On 11/10/2014 05:06 AM, Uwe Kleine-König wrote:
> > I tested this series on top of 784b352aeeed with a patch to support my
> > ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage
> > booting from U-Boot, similar to mirabox with
> > armada-370-netgear-rn104.dts from next-20141106).
> > 
> > 	Marvell>> tftp start_netgear_rn104.pblx
> > 	Using egiga1 device
> > 	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
> > 	Filename 'start_netgear_rn104.pblx'.
> > 	Load address: 0x2000000
> > 	Loading: ####################
> > 	done
> > 	Bytes transferred = 292148 (47534 hex)
> > 	Marvell>> go 0x2000000
> > 	## Starting application at 0x02000000 ...
> > 
> > 
> > 	barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014
> > 
> > 
> > 	Board: NETGEAR ReadyNAS 104
> > 	SoC: Marvell 6710 rev 1
> > 	mdio_bus: miibus0: probed
> > 	eth1: got preset MAC address: 28:c6:8e:36:df:57
> > 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> > 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> > 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> > 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> > 	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
> > 	environment load /dev/env0: No such file or directory
> > 	Maybe you have to create the partition.
> > 	no valid environment found on /dev/env0. Using default environment
> > 	running /env/bin/init...
> > 	/env/bin/init not found
> > 	barebox:/ ethact eth1
> > 	barebox:/ dhcp
> > 	eth1: 1000Mbps full duplex link detected
> > 	T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out
> > 	dhcp: Connection timed out
> > 	barebox:/ eth1.ipaddr=192.168.77.133
> > 	barebox:/ eth1.netmask=255.255.255.0
> > 	barebox:/ echo $eth1.ethaddr
> > 	28:c6:8e:36:df:57
> > 	barebox:/ ping 192.168.77.157
> > 	T T T T T ping failed: Connection timed out
> > 	barebox:/ 
> > 
> > tcpdump on 192.168.77.157 (which is connected via a switch) worked just
> > fine from U-Boot, after all it served the barebox image.
> > 
> > The pca9554 i2c device is only used for leds, so I don't think the error
> > messages above are related.
> > 
> > Yesterday I saw a different error, that I cannot reproduce now with the
> > same barebox image. IIRC I first played around a bit with eth0 until
> > noticing that I need eth1. I didn't save the full log, but it resulted
> > in:
> > 
> > 	barebox:/ ethact eth1
> > 	barebox:/ dhcp
> > 	eth1: 1000Mbps full duplex link detected
> > 	eth1: transmit error 3
> > 	dhcp failed: I/O error
> > 	dhcp: I/O error
> > 
> > Any ideas? I can try to use a dtb without pinmux definitions later
> > today.
> > 
> 
> Hm, not really. I've tested this with my Armada 370 Mirabox and Armada
> XP Openblocks AX3-4 boards (I use kwboot to load the barebox image, so I
> don't jump from U-Boot).
I would expect to use second stage booting to be more robust, because a
missing gpio to enable some hardware component in barebox is already
setup by U-Boot.

Do you have a command line for me? I used

	scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0

which took much longer than I expected (didn't time it, but I'd say in
the several minutes range). And I didn't know what to do then. Ctrl-C
and then connecting microcom was wrong. Adding -t to the command line
above, too.
 
> I guess we must be missing some config. What's confusing is that the
> Mirabox and the RN104 should be pretty similar in this regard (e.g. they
> use the same phy mode).
How do you know which phy is used? I assume from Arnaud's webpage?

Any hints how I can debug this apart from using a dtb without pinmuxing
stuff? (OTOH the same dtb works with linux, hmm.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sebastian Hesselbarth]

On 11/10/2014 07:43 PM, Uwe Kleine-König wrote:
> On Mon, Nov 10, 2014 at 03:10:56PM -0300, Ezequiel Garcia wrote:
>> On 11/10/2014 05:06 AM, Uwe Kleine-König wrote:
>>> I tested this series on top of 784b352aeeed with a patch to support my
>>> ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage
>>> booting from U-Boot, similar to mirabox with
>>> armada-370-netgear-rn104.dts from next-20141106).
>>>
>>> 	Marvell>> tftp start_netgear_rn104.pblx
>>> 	Using egiga1 device
>>> 	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
>>> 	Filename 'start_netgear_rn104.pblx'.
>>> 	Load address: 0x2000000
>>> 	Loading: ####################
>>> 	done
>>> 	Bytes transferred = 292148 (47534 hex)
>>> 	Marvell>> go 0x2000000
>>> 	## Starting application at 0x02000000 ...
>>>
>>> 	barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014
>>>
>>> 	Board: NETGEAR ReadyNAS 104
>>> 	SoC: Marvell 6710 rev 1
>>> 	mdio_bus: miibus0: probed
>>> 	eth1: got preset MAC address: 28:c6:8e:36:df:57
>>> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
>>> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
>>> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
>>> 	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
>>> 	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
>>> 	environment load /dev/env0: No such file or directory
>>> 	Maybe you have to create the partition.
>>> 	no valid environment found on /dev/env0. Using default environment
>>> 	running /env/bin/init...
>>> 	/env/bin/init not found
>>> 	barebox:/ ethact eth1
>>> 	barebox:/ dhcp
>>> 	eth1: 1000Mbps full duplex link detected
>>> 	T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out
>>> 	dhcp: Connection timed out
>>> 	barebox:/ eth1.ipaddr=192.168.77.133
>>> 	barebox:/ eth1.netmask=255.255.255.0
>>> 	barebox:/ echo $eth1.ethaddr
>>> 	28:c6:8e:36:df:57
>>> 	barebox:/ ping 192.168.77.157
>>> 	T T T T T ping failed: Connection timed out
>>> 	barebox:/
>>>
>>> tcpdump on 192.168.77.157 (which is connected via a switch) worked just
>>> fine from U-Boot, after all it served the barebox image.
>>>
[...]
>> Hm, not really. I've tested this with my Armada 370 Mirabox and Armada
>> XP Openblocks AX3-4 boards (I use kwboot to load the barebox image, so I
>> don't jump from U-Boot).

> I would expect to use second stage booting to be more robust, because a
> missing gpio to enable some hardware component in barebox is already
> setup by U-Boot.
>
> Do you have a command line for me? I used
>
> 	scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0
>
> which took much longer than I expected (didn't time it, but I'd say in
> the several minutes range). And I didn't know what to do then. Ctrl-C
> and then connecting microcom was wrong. Adding -t to the command line
> above, too.
>
>> I guess we must be missing some config. What's confusing is that the
>> Mirabox and the RN104 should be pretty similar in this regard (e.g. they
>> use the same phy mode).
> How do you know which phy is used? I assume from Arnaud's webpage?
>
> Any hints how I can debug this apart from using a dtb without pinmuxing
> stuff? (OTOH the same dtb works with linux, hmm.)

If you use barebox as first-stage BL, then you definitely need the 
pinmuxing. If you use it as second-stage BL, u-boot should have set
it up already. The log above suggests that you already used the same
egiga/mvneta controller before on u-boot so that should be fine.

Currently, I cannot tell what is the problem here. I never tried 2nd
stage booting. Can you add the pinmuxing and try uart booting? Also,
can you connect the RN104 directly to a PC and run wireshark on the
interface? You should see packets from the MAC above when e.g. ping
from RN104.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hello Sebastian,

On Mon, Nov 10, 2014 at 08:36:07PM +0100, Sebastian Hesselbarth wrote:
> On 11/10/2014 07:43 PM, Uwe Kleine-König wrote:
> >On Mon, Nov 10, 2014 at 03:10:56PM -0300, Ezequiel Garcia wrote:
> >>On 11/10/2014 05:06 AM, Uwe Kleine-König wrote:
> >>>I tested this series on top of 784b352aeeed with a patch to support my
> >>>ReadyNAS 104 (by Netgear, Armada 370 system, currently only second stage
> >>>booting from U-Boot, similar to mirabox with
> >>>armada-370-netgear-rn104.dts from next-20141106).
> >>>
> >>>	Marvell>> tftp start_netgear_rn104.pblx
> >>>	Using egiga1 device
> >>>	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
> >>>	Filename 'start_netgear_rn104.pblx'.
> >>>	Load address: 0x2000000
> >>>	Loading: ####################
> >>>	done
> >>>	Bytes transferred = 292148 (47534 hex)
> >>>	Marvell>> go 0x2000000
> >>>	## Starting application at 0x02000000 ...
> >>>
> >>>	barebox 2014.11.0-00123-g422a0a9d46a8 #3 Sun Nov 9 21:35:11 CET 2014
> >>>
> >>>	Board: NETGEAR ReadyNAS 104
> >>>	SoC: Marvell 6710 rev 1
> >>>	mdio_bus: miibus0: probed
> >>>	eth1: got preset MAC address: 28:c6:8e:36:df:57
> >>>	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> >>>	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> >>>	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> >>>	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
> >>>	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
> >>>	environment load /dev/env0: No such file or directory
> >>>	Maybe you have to create the partition.
> >>>	no valid environment found on /dev/env0. Using default environment
> >>>	running /env/bin/init...
> >>>	/env/bin/init not found
> >>>	barebox:/ ethact eth1
> >>>	barebox:/ dhcp
> >>>	eth1: 1000Mbps full duplex link detected
> >>>	T T T T T T T T T T T T T T T T T T T T dhcp failed: Connection timed out
> >>>	dhcp: Connection timed out
> >>>	barebox:/ eth1.ipaddr=192.168.77.133
> >>>	barebox:/ eth1.netmask=255.255.255.0
> >>>	barebox:/ echo $eth1.ethaddr
> >>>	28:c6:8e:36:df:57
> >>>	barebox:/ ping 192.168.77.157
> >>>	T T T T T ping failed: Connection timed out
> >>>	barebox:/
> >>>
> >>>tcpdump on 192.168.77.157 (which is connected via a switch) worked just
> >>>fine from U-Boot, after all it served the barebox image.
> >>>
> [...]
> >>Hm, not really. I've tested this with my Armada 370 Mirabox and Armada
> >>XP Openblocks AX3-4 boards (I use kwboot to load the barebox image, so I
> >>don't jump from U-Boot).
> 
> >I would expect to use second stage booting to be more robust, because a
> >missing gpio to enable some hardware component in barebox is already
> >setup by U-Boot.
> >
> >Do you have a command line for me? I used
> >
> >	scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0
> >
> >which took much longer than I expected (didn't time it, but I'd say in
> >the several minutes range). And I didn't know what to do then. Ctrl-C
> >and then connecting microcom was wrong. Adding -t to the command line
> >above, too.
Any hints on how kwboot is used? It loads the binary into RAM and runs
it from there, right? I timed my above command and it took 38m28.225s
for my image (341304 bytes).

> >>I guess we must be missing some config. What's confusing is that the
> >>Mirabox and the RN104 should be pretty similar in this regard (e.g. they
> >>use the same phy mode).
> >How do you know which phy is used? I assume from Arnaud's webpage?
> >
> >Any hints how I can debug this apart from using a dtb without pinmuxing
> >stuff? (OTOH the same dtb works with linux, hmm.)
> 
> If you use barebox as first-stage BL, then you definitely need the
> pinmuxing. If you use it as second-stage BL, u-boot should have set
> it up already. The log above suggests that you already used the same
> egiga/mvneta controller before on u-boot so that should be fine.
right.

> Currently, I cannot tell what is the problem here. I never tried 2nd
> stage booting. Can you add the pinmuxing and try uart booting? Also,
I have the pinmuxing, the dts I used is

	https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/boot/dts/armada-370-netgear-rn104.dts?id=b0187bd33fba065ec736dc33085914a137d390d3

And arch/arm/dts/armada-370-rn104-bb.dts contains:

	#include "arm/armada-370-netgear-rn104.dts"
	/ {
		chosen {
			stdout-path = "/soc/internal-regs/serial@12000";
		};
	};

Double checking using

	dtc -I dtb -O dts arch/arm/dts/armada-370-rn104-bb.dtb

shows that not all nodes (e.g. serial@12000) have pinctrl-* nodes, but
the same applies to armada-370-mirabox.dts.

> can you connect the RN104 directly to a PC and run wireshark on the
> interface? You should see packets from the MAC above when e.g. ping
> from RN104.
Running

	tcpdump -i br-lan -vvv not ip6 and not host 192.168.77.177 and not host 192.168.77.157 and not host 192.168.77.151

on my router (which isn't a PC, but still should be good enough,
shouldn't it? It has the address 192.168.77.1). Running "ping 192.168.77.1"
seems to result in packages like this:

10:01:30.233928 42:40:00:10:40:60 > 00:00:00:34:00:12, ethertype MOP RC (0x6002), length 60: 
        0x0000:  0000 0034 0012 4240 0010 4060 6002 4000  ...4..B@..@``.@.
        0x0010:  0054 8080 0012 4100 0002 c095 08e8 01a0  .T....A.........
        0x0020:  1420 0020 8001 1020 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000            ............

which is utter nonsense.

Will debug that further later today.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Ezequiel Garcia]

Uwe,

On 11/11/2014 06:06 AM, Uwe Kleine-König wrote:
>>>
>>> Do you have a command line for me? I used
>>>
>>> 	scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0
>>>
>>> which took much longer than I expected (didn't time it, but I'd say in
>>> the several minutes range). And I didn't know what to do then. Ctrl-C
>>> and then connecting microcom was wrong. Adding -t to the command line
>>> above, too.
> Any hints on how kwboot is used? It loads the binary into RAM and runs
> it from there, right? I timed my above command and it took 38m28.225s
> for my image (341304 bytes).
> 

This is how I use kwboot:

1. Boot your board (with stock U-Boot and Linux) and extract the bootloader.
   According to my notes, I just grabbed a couple megabytes:

   $ dd if=/dev/mtd0 of=/mtd0.dump bs=1M count=2

   I guess you can grab the entire bootloader partition (if you have one).

2. Run kwbimage tool and dump the output to the appropriate board directory:

  $ ./scripts/kwbimage -x -i /srv/nfs/mtd0.dump -o arch/arm/boards/plathome-openblocks-ax3/

  Fix the produced kwbimage.cfg to boot from UART (actually, I think it's not needed):

  diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
  index 219c2ec..fd6c0df 100644
  --- a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
  +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
  @@ -1,5 +1,5 @@
   VERSION 1
  -BOOT_FROM spi
  +BOOT_FROM uart
   DESTADDR 00600000
   EXECADDR 006b0000
   NAND_BLKSZ 00000000

3. Make your barebox

  $ make

4. Run kwboot and have fun!

  $ ./scripts/kwboot -b images/barebox-plathome-openblocks-ax3.img -t -B 115200 /dev/ttyUSB0

After kwboot transfers the image, it starts a terminal. You don't need to open another one,
and close everything listening on ttyUSB0 or kwboot won't work fine. It should take less
than a minute to transfer the image.

This works for me on every mvebu board I have, but it was a major pain at first :/
-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Thomas Petazzoni]

Dear Ezequiel Garcia,

On Tue, 11 Nov 2014 11:25:40 -0300, Ezequiel Garcia wrote:

>   Fix the produced kwbimage.cfg to boot from UART (actually, I think it's not needed):
> 
>   diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   index 219c2ec..fd6c0df 100644
>   --- a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   @@ -1,5 +1,5 @@
>    VERSION 1
>   -BOOT_FROM spi
>   +BOOT_FROM uart
>    DESTADDR 00600000
>    EXECADDR 006b0000
>    NAND_BLKSZ 00000000

This is indeed not needed. The Barebox build system calls kwbimage
twice: once to generate an image that uses the BOOT_FROM media as the
boot media, and once to generate an image that can boot from the UART.
The former has a .kwb extension, the latter a .kwbuart extension.

Other than that, I think your tutorial is good. Is there a good place
in Barebox to put some documentation such as this?

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Ezequiel Garcia]

On 11/11/2014 11:31 AM, Thomas Petazzoni wrote:
> Dear Ezequiel Garcia,
> 
> On Tue, 11 Nov 2014 11:25:40 -0300, Ezequiel Garcia wrote:
> 
>>   Fix the produced kwbimage.cfg to boot from UART (actually, I think it's not needed):
>>
>>   diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>>   index 219c2ec..fd6c0df 100644
>>   --- a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>>   +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>>   @@ -1,5 +1,5 @@
>>    VERSION 1
>>   -BOOT_FROM spi
>>   +BOOT_FROM uart
>>    DESTADDR 00600000
>>    EXECADDR 006b0000
>>    NAND_BLKSZ 00000000
> 
> This is indeed not needed. The Barebox build system calls kwbimage
> twice: once to generate an image that uses the BOOT_FROM media as the
> boot media, and once to generate an image that can boot from the UART.
> The former has a .kwb extension, the latter a .kwbuart extension.
> 
> Other than that, I think your tutorial is good. Is there a good place
> in Barebox to put some documentation such as this?
> 

Actually... it's a copy-paste of a something I wrote as
Documentation/boards/mvebu.txt, but never sent as a patch.

I can send it now, if you agree to double-check it and perhaps extend it
a bit :)

-- 
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sascha Hauer]

On Tue, Nov 11, 2014 at 11:34:30AM -0300, Ezequiel Garcia wrote:
> On 11/11/2014 11:31 AM, Thomas Petazzoni wrote:
> > Dear Ezequiel Garcia,
> > 
> > On Tue, 11 Nov 2014 11:25:40 -0300, Ezequiel Garcia wrote:
> > 
> >>   Fix the produced kwbimage.cfg to boot from UART (actually, I think it's not needed):
> >>
> >>   diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> >>   index 219c2ec..fd6c0df 100644
> >>   --- a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> >>   +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
> >>   @@ -1,5 +1,5 @@
> >>    VERSION 1
> >>   -BOOT_FROM spi
> >>   +BOOT_FROM uart
> >>    DESTADDR 00600000
> >>    EXECADDR 006b0000
> >>    NAND_BLKSZ 00000000
> > 
> > This is indeed not needed. The Barebox build system calls kwbimage
> > twice: once to generate an image that uses the BOOT_FROM media as the
> > boot media, and once to generate an image that can boot from the UART.
> > The former has a .kwb extension, the latter a .kwbuart extension.
> > 
> > Other than that, I think your tutorial is good. Is there a good place
> > in Barebox to put some documentation such as this?
> > 
> 
> Actually... it's a copy-paste of a something I wrote as
> Documentation/boards/mvebu.txt, but never sent as a patch.

s/txt/rst/ please. The docs are in restructured text format.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hi Ezequiel,

On Tue, Nov 11, 2014 at 11:25:40AM -0300, Ezequiel Garcia wrote:
> On 11/11/2014 06:06 AM, Uwe Kleine-König wrote:
> >>>
> >>> Do you have a command line for me? I used
> >>>
> >>> 	scripts/kwboot -b images/barebox-netgear-rn104-uart.img /dev/ttyUSB0
> >>>
> >>> which took much longer than I expected (didn't time it, but I'd say in
> >>> the several minutes range). And I didn't know what to do then. Ctrl-C
> >>> and then connecting microcom was wrong. Adding -t to the command line
> >>> above, too.
> > Any hints on how kwboot is used? It loads the binary into RAM and runs
> > it from there, right? I timed my above command and it took 38m28.225s
> > for my image (341304 bytes).
> > 
> 
> This is how I use kwboot:
> 
> 1. Boot your board (with stock U-Boot and Linux) and extract the bootloader.
>    According to my notes, I just grabbed a couple megabytes:
> 
>    $ dd if=/dev/mtd0 of=/mtd0.dump bs=1M count=2
> 
>    I guess you can grab the entire bootloader partition (if you have one).
> 
> 2. Run kwbimage tool and dump the output to the appropriate board directory:
> 
>   $ ./scripts/kwbimage -x -i /srv/nfs/mtd0.dump -o arch/arm/boards/plathome-openblocks-ax3/
> 
>   Fix the produced kwbimage.cfg to boot from UART (actually, I think it's not needed):
> 
>   diff --git a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   index 219c2ec..fd6c0df 100644
>   --- a/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   +++ b/arch/arm/boards/plathome-openblocks-ax3/kwbimage.cfg
>   @@ -1,5 +1,5 @@
>    VERSION 1
>   -BOOT_FROM spi
>   +BOOT_FROM uart
>    DESTADDR 00600000
>    EXECADDR 006b0000
>    NAND_BLKSZ 00000000
My kwbimage looks similar:

	VERSION 1
	BOOT_FROM nand
	DESTADDR 00600000
	EXECADDR 006a0000
	NAND_BLKSZ 00020000
	NAND_BADBLK_LOCATION 01
	BINARY arch/arm/boards/netgear-rn104/binary.0 0000005b 00000068
	PAYLOAD ./payload

The other kwbimage.cfg files don't have a "PAYLOAD" line though, but if
I read the source correctly this shouldn't a problem.

BTW, is this binary.0 expected to be located in the source or the build
directory for oot-building? I would expect to provide it in the source
tree, but it's not picked up from there.
 
> 3. Make your barebox
> 
>   $ make
> 
> 4. Run kwboot and have fun!
> 
>   $ ./scripts/kwboot -b images/barebox-plathome-openblocks-ax3.img -t -B 115200 /dev/ttyUSB0
With the patch I just sent, kwboot doesn't take 30+ minutes anymore, but
dies when an error occurs. (Unfortunately this happens 100% reproducibly
with two different USB-to-RS232 adapters.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hello again,

here come the recent insights.

On Tue, Nov 11, 2014 at 10:06:49AM +0100, Uwe Kleine-König wrote:
> shouldn't it? It has the address 192.168.77.1). Running "ping 192.168.77.1"
> seems to result in packages like this:
> 
> 10:01:30.233928 42:40:00:10:40:60 > 00:00:00:34:00:12, ethertype MOP RC (0x6002), length 60: 
>         0x0000:  0000 0034 0012 4240 0010 4060 6002 4000  ...4..B@..@``.@.
>         0x0010:  0054 8080 0012 4100 0002 c095 08e8 01a0  .T....A.........
>         0x0020:  1420 0020 8001 1020 0000 0000 0000 0000  ................
>         0x0030:  0000 0000 0000 0000 0000 0000            ............
> 
> which is utter nonsense.
I sprinkled printfs over the network driver. The packet that is intended
to be sent looks ok:

	Send a packet (len = 42, txdesc=0x01f15000):
	01f12040: ff ff ff ff ff ff 28 c6 8e 36 df 57 08 06 00 01    ......(..6.W....
	01f12050: 08 00 06 04 00 01 28 c6 8e 36 df 57 c0 a8 4d 85    ......(..6.W..M.
	01f12060: 00 00 00 00 00 00 c0 a8 4d 01                      ........M.

That's an ARP request asking for the address of 192.168.77.1 which is
expected. After that, both the descriptor and the data buffer look ok:

	barebox:/ md 0x01f15000+32
	01f15000: fefeffff 002a6fef 01f12040 f7effff4                .....o*.@ ......
	01f15010: fcfefcfa ff2fbff6 fdfbffef 01f14ff8                ....../......O..

	barebox:/ md -b 0x01f12040+42
	01f12040: ff ff ff ff ff ff 28 c6 8e 36 df 57 08 06 00 01    ......(..6.W....
	01f12050: 08 00 06 04 00 01 28 c6 8e 36 df 57 c0 a8 4d 85    ......(..6.W..M.
	01f12060: 00 00 00 00 00 00 c0 a8 4d 01                      ........M.

And I don't see what this has to do with the packet that enters my router:

10:26:31.133258 fe:bf:f7:f3:fb:7f (oui Unknown) > da:74:f7:fc:fb:fa (oui Unknown), ethertype Unknown (0xdfbf), length 60: 
        0x0000:  da74 f7fc fbfa febf f7f3 fb7f dfbf fffb  .t..............
        0x0010:  dffd ffea 7ffd c6e7 fffb faff febd fb5f  ..............._
        0x0020:  fefb effc fefc eff5 0000 0000 0000 0000  ................
        0x0030:  0000 0000 0000 0000 0000 0000            ............

The size looks OK (it was increased from 42 to 60 because that's the
minimal size that is supported by ethernet). So my theory is that either
the phy or some setting in the ethernet address range is broken.

The output of

	md -s /dev/phy1

looks sane, too:

	barebox:/ md -s /dev/phy1
	00000000: 796d1140 0e900141 cde101e1 2001000f                @.myA.......... 
	00000010: 03004502 00003800 00000000 30000000                .E...8.........0
	00000020: bc083060 1c400080 00000020 00000000                `0....@. .......
	00000030: 00000000 00000040 00000000 00000000                ....@...........

It seems to be not possible to easily dump the register space in both
U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
somewhere in the middle.

A difference between U-Boot and barebox is the location where the
internal registers are mapped. Maybe something that depends on U-Boot's
memory layout leaks into barebox because I do 2nd stage booting?

Out of ideas at the moment. :-(

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sebastian Hesselbarth]

On 11/12/2014 11:56 AM, Uwe Kleine-König wrote:
> Hello again,
>
> here come the recent insights.
[...]
>
> It seems to be not possible to easily dump the register space in both
> U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
> somewhere in the middle.
>
> A difference between U-Boot and barebox is the location where the
> internal registers are mapped. Maybe something that depends on U-Boot's
> memory layout leaks into barebox because I do 2nd stage booting?
>
> Out of ideas at the moment. :-(

Uwe,

Nice comparison, but did you double check caches are disabled? There is
no support for Dcache on mvebu SoCs in barebox atm.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote:
> On 11/12/2014 11:56 AM, Uwe Kleine-König wrote:
> >Hello again,
> >
> >here come the recent insights.
> [...]
> >
> >It seems to be not possible to easily dump the register space in both
> >U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
> >somewhere in the middle.
> >
> >A difference between U-Boot and barebox is the location where the
> >internal registers are mapped. Maybe something that depends on U-Boot's
> >memory layout leaks into barebox because I do 2nd stage booting?
> >
> >Out of ideas at the moment. :-(
> 
> Uwe,
> 
> Nice comparison, but did you double check caches are disabled? There is
> no support for Dcache on mvebu SoCs in barebox atm.
I would expect that U-Boot disables caches on go. But I remember there
was a bug in that area some time ago.

Now I saw a different behaviour:

	Marvell>> dhcp
	BOOTP broadcast 1
	*** Unhandled DHCP Option in OFFER/ACK: 28
	*** Unhandled DHCP Option in OFFER/ACK: 28
	DHCP client bound to address 192.168.77.133
	Marvell>> tftp barebox-netgear-rn104-2nd.img
	Using egiga1 device
	TFTP from server 192.168.77.157; our IP address is 192.168.77.133
	Filename 'barebox-netgear-rn104-2nd.img'.
	Load address: 0x2000000
	Loading: ####################
	done
	Bytes transferred = 292299 (475cb hex)
	Marvell>> md 0x01f15000
That is where the descriptor ...

	01f15000: ffffffff ffffffff ffffffff ffffffff    ................
	01f15010: ffffffff ffffffff ffffffff ffffffff    ................
	01f15020: ffffffff ffffffff ffffffff ffffffff    ................
	01f15030: ffffffff ffffffff ffffffff ffffffff    ................
	01f15040: ffffffff ffffffff ffffffff ffffffff    ................
	01f15050: ffffffff ffffffff ffffffff ffffffff    ................
	01f15060: ffffffff ffffffff ffffffff ffffffff    ................
	01f15070: ffffffff ffffffff ffffffff ffffffff    ................
	01f15080: ffffffff ffffffff ffffffff ffffffff    ................
	01f15090: ffffffff ffffffff ffffffff ffffffff    ................
	01f150a0: ffffffff ffffffff ffffffff ffffffff    ................
	01f150b0: ffffffff ffffffff ffffffff ffffffff    ................
	01f150c0: ffffffff ffffffff ffffffff ffffffff    ................
	01f150d0: ffffffff ffffffff ffffffff ffffffff    ................
	01f150e0: ffffffff ffffffff ffffffff ffffffff    ................
	01f150f0: ffffffff ffffffff ffffffff ffffffff    ................
	Marvell>> md 0x01f12040
... and the actual data will be located by barebox:

	01f12040: ffffffff ffffffff ffffffff ffffffff    ................
	01f12050: ffffffff ffffffff ffffffff ffffffff    ................
	01f12060: ffffffff ffffffff ffffffff ffffffff    ................
	01f12070: ffffffff ffffffff ffffffff ffffffff    ................
	01f12080: ffffffff ffffffff ffffffff ffffffff    ................
	01f12090: ffffffff ffffffff ffffffff ffffffff    ................
	01f120a0: ffffffff ffffffff ffffffff ffffffff    ................
	01f120b0: ffffffff ffffffff ffffffff ffffffff    ................
	01f120c0: ffffffff ffffffff ffffffff ffffffff    ................
	01f120d0: ffffffff ffffffff ffffffff ffffffff    ................
	01f120e0: ffffffff ffffffff ffffffff ffffffff    ................
	01f120f0: ffffffff ffffffff ffffffff ffffffff    ................
	01f12100: ffffffff ffffffff ffffffff ffffffff    ................
	01f12110: ffffffff ffffffff ffffffff ffffffff    ................
	01f12120: ffffffff ffffffff ffffffff ffffffff    ................
	01f12130: ffffffff ffffffff ffffffff ffffffff    ................
	Marvell>> go $loadaddr
	## Starting application at 0x02000000 ...


	barebox 2014.11.0-00127-g263044f25b47-dirty #14 Thu Nov 13 09:26:54 CET 2014


	Board: NETGEAR ReadyNAS 104
	SoC: Marvell 6710 rev 1
	mdio_bus: miibus0: probed
	mvneta_setup_tx_rx: port = 0x01f11210, regbase = f1070000
	mvneta_setup_tx_rx: port = 0x01f11520, regbase = f1074000
	eth1: got preset MAC address: 28:c6:8e:36:df:57
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	of_get_named_gpio_flags: unable to get gpio num of device pca95540: -19
	malloc space: 0x01f00000 -> 0x03dfffff (size 31 MiB)
	environment load /dev/env0: No such file or directory
	Maybe you have to create the partition.
	no valid environment found on /dev/env0. Using default environment
	running /env/bin/init...
	/env/bin/init not found
	barebox:/ ethact eth1
	barebox:/ eth1.ipaddr=192.168.77.133
	barebox:/ eth1.netmask=255.255.255.0
	barebox:/ ping 192.168.77.1
	eth1: 1000Mbps full duplex link detected
	Send a packet (len = 42, txdesc=0x01f15000):
	01f12040: ff ff ff ff ff ff 28 c6 8e 36 df 57 08 06 00 01    ......(..6.W....
	01f12050: 08 00 06 04 00 01 28 c6 8e 36 df 57 c0 a8 4d 85    ......(..6.W..M.
	01f12060: 00 00 00 00 00 00 c0 a8 4d 01                      ........M.
	eth1: transmit error 3
	ping failed: I/O error

Hmm, never saw an I/O error before. What does error 3 mean?

	barebox:/ md 0x01f15000
	01f15000: ffffffff 002affff 01f12040 ffffffff                ......*.@ ......
	01f15010: ffffffff ffffffff ffffffff 01f14ff8                .............O..
	01f15020: 00000028 03e303f0 03e30408 00000000                (...............
	01f15030: 00000000 01f11fd8 00000000 03e616fc                ................
	01f15040: 00000000 01f15070 01f11fbc 00000028                ....pP......(...
	01f15050: 03e303f0 03e30408 00000000 00000000                ................
	01f15060: 01f1507c 00000000 03e616fc 00000000                |P..............
	01f15070: 01f150b0 01f15044 00000010 746f6f62                .P..DP......boot
	01f15080: 666f2e6d 65657274 01f15000 00000028                m.oftree.P..(...
	01f15090: 03e303f0 03e30408 00000000 00000000                ................
	01f150a0: 01f150bc 00000000 03e616fc 00000000                .P..............
	01f150b0: 01f150f0 01f15070 00000010 746f6f62                .P..pP......boot
	01f150c0: 6e692e6d 64727469 01f15000 00000028                m.initrd.P..(...
	01f150d0: 03e303f0 03e30408 00000000 00000000                ................
	01f150e0: 01f150fc 00000000 03e616fc 00000000                .P..............
	01f150f0: 01f15224 01f150b0 00000018 746f6f62                $R...P......boot
	barebox:/ md 0x01f12040
	01f12040: ffffffff c628ffff 57df368e 01000608                ......(..6.W....
	01f12050: 04060008 c6280100 57df368e 854da8c0                ......(..6.W..M.
	01f12060: 00000000 a8c00000 ffff014d ffffffff                ........M.......
	01f12070: ffffffff ffffffff ffffffff ffffffff                ................
	01f12080: ffffffff ffffffff ffffffff ffffffff                ................
	01f12090: ffffffff ffffffff ffffffff ffffffff                ................
	01f120a0: ffffffff ffffffff ffffffff ffffffff                ................
	01f120b0: ffffffff ffffffff ffffffff ffffffff                ................
	01f120c0: ffffffff ffffffff ffffffff ffffffff                ................
	01f120d0: ffffffff ffffffff ffffffff ffffffff                ................
	01f120e0: ffffffff ffffffff ffffffff ffffffff                ................
	01f120f0: ffffffff ffffffff ffffffff ffffffff                ................
	01f12100: ffffffff ffffffff ffffffff ffffffff                ................
	01f12110: ffffffff ffffffff ffffffff ffffffff                ................
	01f12120: ffffffff ffffffff ffffffff ffffffff                ................
	01f12130: ffffffff ffffffff ffffffff ffffffff                ................

That looks ok. And when I warm reset and look at these memory locations
using U-Boot again, they are still holding that arp packet. So if it's
really a cache problem, the cache is very insistent and U-Boot has a
problem, too.

Furthermore Sascha interpreted

	barebox:/ cpuinfo
	implementer: Marvell Semiconductor Inc.
	architecture: v7
	core: unknown r1p1
	cache: 512 bytes (linelen = 64)
	Control register: A W P D L Z I DT IT U XP 

as: The MMU is off (as there is no M in the Control register line) and
so caches must be off, too.

Looking into the vendor U-Boot sources and they didn't change
drivers/net/kirkwood_egiga.c compared to v2009.08.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sebastian Hesselbarth]

On 11/13/2014 10:09 AM, Uwe Kleine-König wrote:
> On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote:
>> On 11/12/2014 11:56 AM, Uwe Kleine-König wrote:
>>> Hello again,
>>>
>>> here come the recent insights.
>> [...]
>>>
>>> It seems to be not possible to easily dump the register space in both
>>> U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
>>> somewhere in the middle.
>>>
>>> A difference between U-Boot and barebox is the location where the
>>> internal registers are mapped. Maybe something that depends on U-Boot's
>>> memory layout leaks into barebox because I do 2nd stage booting?
>>>
>>> Out of ideas at the moment. :-(
>>
>> Uwe,
>>
>> Nice comparison, but did you double check caches are disabled? There is
>> no support for Dcache on mvebu SoCs in barebox atm.
> I would expect that U-Boot disables caches on go. But I remember there
> was a bug in that area some time ago.

Why should U-Boot do anything on go except jumping to that location?

> Now I saw a different behaviour:

Let's start from scratch and change one thing at a time:

Can you try to UART boot barebox directly and try both eth interfaces?

If that already does not work we have to look at barebox only.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

On Thu, Nov 13, 2014 at 10:53:46AM +0100, Sebastian Hesselbarth wrote:
> On 11/13/2014 10:09 AM, Uwe Kleine-König wrote:
> >On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote:
> >>On 11/12/2014 11:56 AM, Uwe Kleine-König wrote:
> >>>Hello again,
> >>>
> >>>here come the recent insights.
> >>[...]
> >>>
> >>>It seems to be not possible to easily dump the register space in both
> >>>U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
> >>>somewhere in the middle.
> >>>
> >>>A difference between U-Boot and barebox is the location where the
> >>>internal registers are mapped. Maybe something that depends on U-Boot's
> >>>memory layout leaks into barebox because I do 2nd stage booting?
> >>>
> >>>Out of ideas at the moment. :-(
> >>
> >>Uwe,
> >>
> >>Nice comparison, but did you double check caches are disabled? There is
> >>no support for Dcache on mvebu SoCs in barebox atm.
> >I would expect that U-Boot disables caches on go. But I remember there
> >was a bug in that area some time ago.
> 
> Why should U-Boot do anything on go except jumping to that location?
> 
> >Now I saw a different behaviour:
> 
> Let's start from scratch and change one thing at a time:
> 
> Can you try to UART boot barebox directly and try both eth interfaces?
I don't manage to boot via UART. The usual outcome is:

Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  2 % [......................................................................]
  5 % [......................................................................]
  7 % [......................................................................]
 10 % [......................................................................]
 13 % [..................................xmodem: Connection timed out

If I try to boot a barebox-globalscale-mirabox.img (provided by
ezequielg in #mvlinux), I get:

$ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1 
Sending boot message. Please reboot the target...\
Sending boot image...
  0 % [......................................................................]
  5 % [......................................................................]
 10 % [......................................................................]
 14 % [......................................................................]
 19 % [......................................................................]
 24 % [.................................DDR3 Training Sequence - Ver 2.1.6 
DDR3 Training Sequence - Number of DIMMs detected: 1
+xmodem: Connection timed out

And funny enough, during testing I added

	select(fd + 1, &rfds, NULL, NULL, &tv);

to kwboot_tty_recv after the read, this results reproduibly into a
single NAK and "BootROM: Invalid header checksum".

When booting from nand (as shipped by Netgear) the output starts with:

------------------------

BootROM 1.08
Booting from NAND flash
DDR3 Training Sequence - Ver 2.1.7 
DDR3 Training Sequence - Ended Successfully 
BootROM: Image checksum verification PASSED
...
------------------------

> If that already does not work we have to look at barebox only.
That would be great, yes.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sebastian Hesselbarth]

On 11/13/2014 11:46 AM, Uwe Kleine-König wrote:
> On Thu, Nov 13, 2014 at 10:53:46AM +0100, Sebastian Hesselbarth wrote:
>> On 11/13/2014 10:09 AM, Uwe Kleine-König wrote:
>>> On Wed, Nov 12, 2014 at 12:22:22PM +0100, Sebastian Hesselbarth wrote:
>>>> On 11/12/2014 11:56 AM, Uwe Kleine-König wrote:
>>>>> Hello again,
>>>>>
>>>>> here come the recent insights.
>>>> [...]
>>>>>
>>>>> It seems to be not possible to easily dump the register space in both
>>>>> U-Boot and barebox for comparison. md 0xf1074000+0x4000 just hangs
>>>>> somewhere in the middle.
>>>>>
>>>>> A difference between U-Boot and barebox is the location where the
>>>>> internal registers are mapped. Maybe something that depends on U-Boot's
>>>>> memory layout leaks into barebox because I do 2nd stage booting?
>>>>>
>>>>> Out of ideas at the moment. :-(
>>>>
>>>> Uwe,
>>>>
>>>> Nice comparison, but did you double check caches are disabled? There is
>>>> no support for Dcache on mvebu SoCs in barebox atm.
>>> I would expect that U-Boot disables caches on go. But I remember there
>>> was a bug in that area some time ago.
>>
>> Why should U-Boot do anything on go except jumping to that location?
>>
>>> Now I saw a different behaviour:
>>
>> Let's start from scratch and change one thing at a time:
>>
>> Can you try to UART boot barebox directly and try both eth interfaces?
> I don't manage to boot via UART. The usual outcome is:
>
> Sending boot message. Please reboot the target...\
> Sending boot image...
>    0 % [......................................................................]
>    2 % [......................................................................]
>    5 % [......................................................................]
>    7 % [......................................................................]
>   10 % [......................................................................]
>   13 % [..................................xmodem: Connection timed out
>
> If I try to boot a barebox-globalscale-mirabox.img (provided by
> ezequielg in #mvlinux), I get:
>
> $ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1
> Sending boot message. Please reboot the target...\
> Sending boot image...
>    0 % [......................................................................]
>    5 % [......................................................................]
>   10 % [......................................................................]
>   14 % [......................................................................]
>   19 % [......................................................................]
>   24 % [.................................DDR3 Training Sequence - Ver 2.1.6
> DDR3 Training Sequence - Number of DIMMs detected: 1
> +xmodem: Connection timed out

That indeed is strange and indicates some general problem. Can you retry
with setting the baudrate to 115200 (-b 115200 IIRC).

> And funny enough, during testing I added
>
> 	select(fd + 1, &rfds, NULL, NULL, &tv);
>
> to kwboot_tty_recv after the read, this results reproduibly into a
> single NAK and "BootROM: Invalid header checksum".
>
> When booting from nand (as shipped by Netgear) the output starts with:

You need to set boot source byte to UART (0x52 IIRC). Otherwise the NAND
image will not boot from UART boot mode. Check out kwbimage, it should
show you where and how to modify the binary. I cannot recall if kwbimage
can convert it for you already, you also need to update the image header
CRC.

Sebastian

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hallo Sebastian,

On Thu, Nov 13, 2014 at 12:31:08PM +0100, Sebastian Hesselbarth wrote:
> >I don't manage to boot via UART. The usual outcome is:
> >
> >Sending boot message. Please reboot the target...\
> >Sending boot image...
> >   0 % [......................................................................]
> >   2 % [......................................................................]
> >   5 % [......................................................................]
> >   7 % [......................................................................]
> >  10 % [......................................................................]
> >  13 % [..................................xmodem: Connection timed out
> >
> >If I try to boot a barebox-globalscale-mirabox.img (provided by
> >ezequielg in #mvlinux), I get:
> >
> >$ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1
> >Sending boot message. Please reboot the target...\
> >Sending boot image...
> >   0 % [......................................................................]
> >   5 % [......................................................................]
> >  10 % [......................................................................]
> >  14 % [......................................................................]
> >  19 % [......................................................................]
> >  24 % [.................................DDR3 Training Sequence - Ver 2.1.6
> >DDR3 Training Sequence - Number of DIMMs detected: 1
> >+xmodem: Connection timed out
> 
> That indeed is strange and indicates some general problem. Can you retry
> with setting the baudrate to 115200 (-b 115200 IIRC).
Doesn't change anything. In fact the tty is already configured for
115200 Baud. And I would expect that on a mismatch it wouldn't always
die just after the header is uploaded.

Just noticed that my binary.0 was corrupted as I extraced it from a nand
dump that also included the oob area ...

With a proper image I get barebox up now.

> >And funny enough, during testing I added
> >
> >	select(fd + 1, &rfds, NULL, NULL, &tv);
> >
> >to kwboot_tty_recv after the read, this results reproduibly into a
> >single NAK and "BootROM: Invalid header checksum".
This is still not explained. I would have expected that this select
doesn't do anything noticable on the remote end.

> >When booting from nand (as shipped by Netgear) the output starts with:
> 
> You need to set boot source byte to UART (0x52 IIRC). Otherwise the NAND
Just for the log: UART = 0x69.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Sebastian Hesselbarth]

On 11/13/2014 07:44 PM, Uwe Kleine-König wrote:
> On Thu, Nov 13, 2014 at 12:31:08PM +0100, Sebastian Hesselbarth wrote:
>>> $ scripts/kwboot -b ../barebox-globalscale-mirabox.img -t /dev/ttyUSB1
>>> Sending boot message. Please reboot the target...\
>>> Sending boot image...
>>>    0 % [......................................................................]
>>>    5 % [......................................................................]
>>>   10 % [......................................................................]
>>>   14 % [......................................................................]
>>>   19 % [......................................................................]
>>>   24 % [.................................DDR3 Training Sequence - Ver 2.1.6
>>> DDR3 Training Sequence - Number of DIMMs detected: 1
>>> +xmodem: Connection timed out
>>
>> That indeed is strange and indicates some general problem. Can you retry
>> with setting the baudrate to 115200 (-b 115200 IIRC).
> Doesn't change anything. In fact the tty is already configured for
> 115200 Baud. And I would expect that on a mismatch it wouldn't always
> die just after the header is uploaded.
>
> Just noticed that my binary.0 was corrupted as I extraced it from a nand
> dump that also included the oob area ...
>
> With a proper image I get barebox up now.

Great, does that help with the ethernet issues you have been seeing
before?

>>> And funny enough, during testing I added
>>>
>>> 	select(fd + 1, &rfds, NULL, NULL, &tv);
>>>
>>> to kwboot_tty_recv after the read, this results reproduibly into a
>>> single NAK and "BootROM: Invalid header checksum".
> This is still not explained. I would have expected that this select
> doesn't do anything noticable on the remote end.

I cannot tell where you added that select nor can I tell why it breaks
uart boot mode. If you modifiy the code, I admit, you'll have to find
out yourself why it breaks.

Remember that the uart boot mode it neither well documented nor well
suited for "defined timings".. you'll have to hit some timing windows
otherwise it will fail.

>>> When booting from nand (as shipped by Netgear) the output starts with:
>>
>> You need to set boot source byte to UART (0x52 IIRC). Otherwise the NAND
> Just for the log: UART = 0x69.

Right.

Sebastian


_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 0/4] mvebu: Add network support for Armada 370/XP

[Uwe Kleine-König]

Hello Sebastian,

On Fri, Nov 14, 2014 at 09:21:00AM +0100, Sebastian Hesselbarth wrote:
> On 11/13/2014 07:44 PM, Uwe Kleine-König wrote:
> >With a proper image I get barebox up now.
> 
> Great, does that help with the ethernet issues you have been seeing
> before?
No, still having issues with ethernet. Without U-Boot nothing reaches my
router, not even broken packages. Sending packages now always ends in
"eth1: transmit error 3". Didn't debug further what this means, yet.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox