[PATCH 0/6] Firestone patches

[PATCH 0/6] Firestone patches

[Cyril Bur]

Did some work getting openbmc running on a Firestone. These should
also work for a Garrison, the firestone.dts is probably good for that
too.

Thanks very much to Gavin for getting networking going.

These patches are the outcome based on dev-4.4.

Cyril Bur (2):
  arm/dts: Set I2C_TEN_BIT_ADDRESS in Firestone BMC board i2c addresses
  arm/dts: Remove mac hardware checksum from Firestone BMC Board

Gavin Shan (1):
  net/phy: Expose 100base-T capability only

Joel Stanley (3):
  phy/broadcom: Add support for the BCM54210E
  arm/dts/aspeed: Move mac nsci properties
  arm/dts: Add Firestone BMC board

 arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts |   5 +
 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 136 +++++++++++++++++++++++++
 arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts  |   5 +
 arch/arm/boot/dts/ast2400.dtsi                 |   6 +-
 drivers/net/phy/broadcom.c                     |  13 +++
 include/linux/brcmphy.h                        |   2 +
 6 files changed, 165 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts

-- 
2.8.2

[PATCH 1/6] phy/broadcom: Add support for the BCM54210E

[Cyril Bur]

From: Joel Stanley <joel@jms.id.au>

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 drivers/net/phy/broadcom.c | 13 +++++++++++++
 include/linux/brcmphy.h    |  2 ++
 2 files changed, 15 insertions(+)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3ce5d95..3743164 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -604,6 +604,18 @@ static struct phy_driver broadcom_drivers[] = {
 	.ack_interrupt	= brcm_fet_ack_interrupt,
 	.config_intr	= brcm_fet_config_intr,
 	.driver		= { .owner = THIS_MODULE },
+}, {
+	.phy_id		= PHY_ID_BCM54210E,
+	.phy_id_mask	= 0xfffffff0,
+	.name		= "Broadcom BCM54210E",
+	.features	= PHY_GBIT_FEATURES |
+			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+	.flags		= PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+	.config_init	= bcm54xx_config_init,
+	.config_aneg	= genphy_config_aneg,
+	.read_status	= genphy_read_status,
+	.ack_interrupt	= bcm_phy_ack_intr,
+	.config_intr	= bcm_phy_config_intr,
 } };
 
 module_phy_driver(broadcom_drivers);
@@ -621,6 +633,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
 	{ PHY_ID_BCM57780, 0xfffffff0 },
 	{ PHY_ID_BCMAC131, 0xfffffff0 },
 	{ PHY_ID_BCM5241, 0xfffffff0 },
+	{ PHY_ID_BCM54210E, 0xfffffff0},
 	{ }
 };
 
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 59f4a73..3d644da 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -32,6 +32,8 @@
 
 #define PHY_ID_BCM_CYGNUS		0xae025200
 
+#define PHY_ID_BCM54210E		0x600d84a0
+
 #define PHY_BCM_OUI_MASK		0xfffffc00
 #define PHY_BCM_OUI_1			0x00206000
 #define PHY_BCM_OUI_2			0x0143bc00
-- 
2.8.2

[PATCH 2/6] arm/dts/aspeed: Move mac nsci properties

[Cyril Bur]

From: Joel Stanley <joel@jms.id.au>

We have boards that don't use nsci, so make this specific to the
palmetto and barreleyes.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts | 5 +++++
 arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts  | 5 +++++
 arch/arm/boot/dts/ast2400.dtsi                 | 2 --
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts b/arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts
index 143292b6..a06252a 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-barreleye.dts
@@ -7,6 +7,11 @@
 	model = "Barrelye BMC";
 	compatible = "rackspace,barreleye-bmc", "aspeed,ast2400";
 	ahb {
+		mac0: ethernet@1e660000 {
+			use-nc-si;
+			no-hw-checksum;
+		};
+
 		fmc@1e620000 {
 			reg = < 0x1e620000 0x94
 				0x20000000 0x02000000 >;
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
index c78a2f5..cde194e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
@@ -8,6 +8,11 @@
 	compatible = "tyan,palmetto-bmc", "aspeed,ast2400";
 
 	ahb {
+		mac0: ethernet@1e660000 {
+			use-nc-si;
+			no-hw-checksum;
+		};
+
 		fmc@1e620000 {
 			reg = < 0x1e620000 0x94
 				0x20000000 0x02000000 >;
diff --git a/arch/arm/boot/dts/ast2400.dtsi b/arch/arm/boot/dts/ast2400.dtsi
index 49516fd..e1100f0 100644
--- a/arch/arm/boot/dts/ast2400.dtsi
+++ b/arch/arm/boot/dts/ast2400.dtsi
@@ -69,8 +69,6 @@
 			compatible = "faraday,ftgmac100", "aspeed,ast2400-mac";
 			reg = <0x1e660000 0x180>;
 			interrupts = <2>;
-			use-nc-si;
-			no-hw-checksum;
 		};
 
 		apb {
-- 
2.8.2

[PATCH 3/6] arm/dts: Add Firestone BMC board

[Cyril Bur]

From: Joel Stanley <joel@jms.id.au>

The Firestone is an IBM made OpenPower machine that uses the ast2400
BMC.

Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 133 +++++++++++++++++++++++++
 arch/arm/boot/dts/ast2400.dtsi                 |   4 +
 2 files changed, 137 insertions(+)
 create mode 100644 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
new file mode 100644
index 0000000..2b988e7
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
@@ -0,0 +1,133 @@
+/dts-v1/;
+
+#include "ast2400.dtsi"
+
+/ {
+	model = "Firestone BMC";
+	compatible = "ibm,firestone-bmc", "aspeed,ast2400";
+
+	aliases {
+		serial0 = &uart5;
+	};
+
+	chosen {
+		stdout-path = &uart5;
+		bootargs = "console=ttyS4,38400";
+	};
+
+	memory {
+		reg = < 0x40000000 0x20000000 >;
+	};
+
+	ahb {
+		fmc@1e620000 {
+			reg = < 0x1e620000 0x94
+				0x20000000 0x02000000 >;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "aspeed,fmc";
+			flash@0 {
+				reg = < 0 >;
+				compatible = "jedec,spi-nor" ;
+				/*
+				 * Possibly required props:
+				 * spi-max-frequency = <>
+				 * spi-tx-bus-width = <>
+				 * spi-rx-bus-width  = <>
+				 * m25p,fast-read
+				 * spi-cpol if inverse clock polarity (CPOL)
+				 * spi-cpha if shifted clock phase (CPHA)
+				 */
+#include "aspeed-bmc-opp-flash-layout.dtsi"
+			};
+		};
+		spi@1e630000 {
+			reg = < 0x1e630000 0x18
+				0x30000000 0x02000000 >;
+			#address-cells = <1>;
+			#size-cells = <0>;
+			compatible = "aspeed,smc";
+			flash {
+				reg = < 0 >;
+				compatible = "jedec,spi-nor" ;
+				label = "pnor";
+				/* spi-max-frequency = <>; */
+				/* m25p,fast-read; */
+			};
+		};
+		apb {
+			i2c: i2c@1e78a040 {
+				i2c0: i2c-bus@40 {
+					// grounded
+				};
+				i2c1: i2c-bus@80 {
+					// grounded
+				};
+				i2c2: i2c-bus@c0 {
+					// i2c mux
+				};
+				i2c3: i2c-bus@100 {
+					// i2c hub PCA9516A
+				};
+				i2c4: i2c-bus@140 {
+					// turismo
+				};
+				i2c5: i2c-bus@180 {
+					tmp423@98 {
+						compatible = "ti,tmp423";
+						reg = <0x98>;
+					};
+				};
+				i2c6: i2c-bus@1c0 {
+					// nc
+				};
+				i2c7: i2c-bus@300 {
+					// nc
+				};
+				i2c8: i2c-bus@340 {
+					// FSI
+					status = "disabled";
+				};
+				i2c9: i2c-bus@380 {
+					// 4 way mux
+				};
+				i2c10: i2c-bus@3c0 {
+					// 4 way mux
+				};
+				i2c11: i2c-bus@400 {
+					status = "okay";
+					leds@c0 {
+						compatible = "pca,pca9552led";
+						reg = <0xc0>;
+						// led9 - led_fault_n
+						// led10 - pwr_led_n
+						// led11 - rear_id_led_n
+					};
+					rtc@d0 {
+						compatible = "dallas,ds3231";
+						reg = <0xd0>;
+					};
+					si5338a@e2 {
+						// SiLabs clock generator
+						reg =<0xe2>;
+					};
+
+					idt@d6 {
+						// IDT 9DBV0641 clock buffer
+						reg = <0xd6>;
+					};
+
+					tpm@a3 {
+						reg = <0xa3>;
+					};
+				};
+				i2c12: i2c-bus@440 {
+					// i2c hub PCA9516A
+				};
+				i2c13: i2c-bus@480 {
+					// i2c hub PCA9516A
+				};
+			};
+		};
+	};
+};
diff --git a/arch/arm/boot/dts/ast2400.dtsi b/arch/arm/boot/dts/ast2400.dtsi
index e1100f0..62fab71 100644
--- a/arch/arm/boot/dts/ast2400.dtsi
+++ b/arch/arm/boot/dts/ast2400.dtsi
@@ -213,6 +213,8 @@
 				};
 
 				i2c10: i2c-bus@3c0 {
+					#address-cells = <1>;
+					#size-cells = <0>;
 					reg = <0x380 0x40>;
 					compatible = "aspeed,ast2400-i2c-bus";
 					bus = <10>;
@@ -222,6 +224,8 @@
 				};
 
 				i2c11: i2c-bus@400 {
+					#address-cells = <1>;
+					#size-cells = <0>;
 					reg = <0x400 0x40>;
 					compatible = "aspeed,ast2400-i2c-bus";
 					bus = <11>;
-- 
2.8.2

[PATCH 4/6] arm/dts: Set I2C_TEN_BIT_ADDRESS in Firestone BMC board i2c addresses

[Cyril Bur]

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
index 2b988e7..379b561 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
@@ -75,7 +75,7 @@
 				i2c5: i2c-bus@180 {
 					tmp423@98 {
 						compatible = "ti,tmp423";
-						reg = <0x98>;
+						reg = <0x80000098>;
 					};
 				};
 				i2c6: i2c-bus@1c0 {
@@ -98,27 +98,27 @@
 					status = "okay";
 					leds@c0 {
 						compatible = "pca,pca9552led";
-						reg = <0xc0>;
+						reg = <0x800000c0>;
 						// led9 - led_fault_n
 						// led10 - pwr_led_n
 						// led11 - rear_id_led_n
 					};
 					rtc@d0 {
 						compatible = "dallas,ds3231";
-						reg = <0xd0>;
+						reg = <0x800000d0>;
 					};
 					si5338a@e2 {
 						// SiLabs clock generator
-						reg =<0xe2>;
+						reg =<0x800000e2>;
 					};
 
 					idt@d6 {
 						// IDT 9DBV0641 clock buffer
-						reg = <0xd6>;
+						reg = <0x800000d6>;
 					};
 
 					tpm@a3 {
-						reg = <0xa3>;
+						reg = <0x800000a3>;
 					};
 				};
 				i2c12: i2c-bus@440 {
-- 
2.8.2

[PATCH 5/6] arm/dts: Remove mac hardware checksum from Firestone BMC Board

[Cyril Bur]

Hardware checksumming doesn't work.

Without this patch pings work but more complex network interactions like SSH
fail.

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
index 379b561..51b03b7 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
@@ -41,6 +41,9 @@
 #include "aspeed-bmc-opp-flash-layout.dtsi"
 			};
 		};
+		mac0: ethernet@1e660000 {
+			no-hw-checksum;
+		};
 		spi@1e630000 {
 			reg = < 0x1e630000 0x18
 				0x30000000 0x02000000 >;
-- 
2.8.2

[PATCH 6/6] net/phy: Expose 100base-T capability only

[Cyril Bur]

From: Gavin Shan <gwshan@linux.vnet.ibm.com>

I don't know the specific PHY model deployed on Firestone BMC, but
currently used one (PHY_ID_BCM54210E) isn't correct. BCM54210E
supports 1000base-T but the PHY on Firestone BMC shouldn't support
that mode as uboot uses 100base-T mode.

When exposing 1000base-T capability, the MAC is forced to have the
same mode though the PHY is working in 100base-T mode in fact. It
causes the mode mismatch between PHY/MAC and the ethernet network
doesn't work.

It's a temporary fix. After the PHY model is confirmed, we need
to enable the correct PHY driver instead current one for BCM54210E.

Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>

[Cyril]
The plot thickens, it does appear that this IS the correct PHY on
firestones. This patch is definitely required for networking to be
functional though.

Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
---
 drivers/net/phy/broadcom.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 3743164..95208b0 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -608,7 +608,7 @@ static struct phy_driver broadcom_drivers[] = {
 	.phy_id		= PHY_ID_BCM54210E,
 	.phy_id_mask	= 0xfffffff0,
 	.name		= "Broadcom BCM54210E",
-	.features	= PHY_GBIT_FEATURES |
+	.features	= PHY_BASIC_FEATURES |
 			  SUPPORTED_Pause | SUPPORTED_Asym_Pause,
 	.flags		= PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
 	.config_init	= bcm54xx_config_init,
-- 
2.8.2

Re: [PATCH 4/6] arm/dts: Set I2C_TEN_BIT_ADDRESS in Firestone BMC board i2c addresses

[Joel Stanley]

On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com> wrote:

Did you work out why we needed this, and why it fixes things?

Should we be doing it for all the device trees?

> Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
> ---
>  arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> index 2b988e7..379b561 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> @@ -75,7 +75,7 @@
>                                 i2c5: i2c-bus@180 {
>                                         tmp423@98 {
>                                                 compatible = "ti,tmp423";
> -                                               reg = <0x98>;
> +                                               reg = <0x80000098>;
>                                         };
>                                 };
>                                 i2c6: i2c-bus@1c0 {
> @@ -98,27 +98,27 @@
>                                         status = "okay";
>                                         leds@c0 {
>                                                 compatible = "pca,pca9552led";
> -                                               reg = <0xc0>;
> +                                               reg = <0x800000c0>;
>                                                 // led9 - led_fault_n
>                                                 // led10 - pwr_led_n
>                                                 // led11 - rear_id_led_n
>                                         };
>                                         rtc@d0 {
>                                                 compatible = "dallas,ds3231";
> -                                               reg = <0xd0>;
> +                                               reg = <0x800000d0>;
>                                         };
>                                         si5338a@e2 {
>                                                 // SiLabs clock generator
> -                                               reg =<0xe2>;
> +                                               reg =<0x800000e2>;
>                                         };
>
>                                         idt@d6 {
>                                                 // IDT 9DBV0641 clock buffer
> -                                               reg = <0xd6>;
> +                                               reg = <0x800000d6>;
>                                         };
>
>                                         tpm@a3 {
> -                                               reg = <0xa3>;
> +                                               reg = <0x800000a3>;
>                                         };
>                                 };
>                                 i2c12: i2c-bus@440 {
> --
> 2.8.2
>
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: [PATCH 1/6] phy/broadcom: Add support for the BCM54210E

[Joel Stanley]

On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com> wrote:
> From: Joel Stanley <joel@jms.id.au>

Are you happy that this is correct? I will submit it upstream if so.

>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
> ---
>  drivers/net/phy/broadcom.c | 13 +++++++++++++
>  include/linux/brcmphy.h    |  2 ++
>  2 files changed, 15 insertions(+)

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Joel Stanley]

On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com> wrote:
> From: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
> I don't know the specific PHY model deployed on Firestone BMC, but
> currently used one (PHY_ID_BCM54210E) isn't correct. BCM54210E
> supports 1000base-T but the PHY on Firestone BMC shouldn't support
> that mode as uboot uses 100base-T mode.
>
> When exposing 1000base-T capability, the MAC is forced to have the
> same mode though the PHY is working in 100base-T mode in fact. It
> causes the mode mismatch between PHY/MAC and the ethernet network
> doesn't work.
>
> It's a temporary fix. After the PHY model is confirmed, we need
> to enable the correct PHY driver instead current one for BCM54210E.
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>
> [Cyril]
> The plot thickens, it does appear that this IS the correct PHY on
> firestones. This patch is definitely required for networking to be
> functional though.

We should get someone in Austin to boot a firestone without this patch
and see what it does. You shouldn't need a pdu as long as you get it
right the first time :)

Joel

Re: [PATCH 0/6] Firestone patches

[Joel Stanley]

On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com> wrote:
> Did some work getting openbmc running on a Firestone. These should
> also work for a Garrison, the firestone.dts is probably good for that
> too.
>
> Thanks very much to Gavin for getting networking going.
>
> These patches are the outcome based on dev-4.4.

Great work! I've commented on some of the patches, but I'll merge these as-is.

Cheers,

Joel

Re: [PATCH 4/6] arm/dts: Set I2C_TEN_BIT_ADDRESS in Firestone BMC board i2c addresses

[Benjamin Herrenschmidt]

On Thu, 2016-05-05 at 22:51 +0930, Joel Stanley wrote:
> On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com>
> wrote:
> 
> Did you work out why we needed this, and why it fixes things?
> 
> Should we be doing it for all the device trees?

That's weird indeed... Is there a 10-bit device on that bus ? Otherwise
we shouldn't emit 10-bit addresses. In general, 10-bit addresses stuff
doesn't work, in my experience at least. We might be papering over some
other problem...

> > 
> > Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
> > ---
> >  arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > index 2b988e7..379b561 100644
> > --- a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > @@ -75,7 +75,7 @@
> >                                 i2c5: i2c-bus@180 {
> >                                         tmp423@98 {
> >                                                 compatible =
> > "ti,tmp423";
> > -                                               reg = <0x98>;
> > +                                               reg = <0x80000098>;
> >                                         };
> >                                 };
> >                                 i2c6: i2c-bus@1c0 {
> > @@ -98,27 +98,27 @@
> >                                         status = "okay";
> >                                         leds@c0 {
> >                                                 compatible =
> > "pca,pca9552led";
> > -                                               reg = <0xc0>;
> > +                                               reg = <0x800000c0>;
> >                                                 // led9 -
> > led_fault_n
> >                                                 // led10 -
> > pwr_led_n
> >                                                 // led11 -
> > rear_id_led_n
> >                                         };
> >                                         rtc@d0 {
> >                                                 compatible =
> > "dallas,ds3231";
> > -                                               reg = <0xd0>;
> > +                                               reg = <0x800000d0>;
> >                                         };
> >                                         si5338a@e2 {
> >                                                 // SiLabs clock
> > generator
> > -                                               reg =<0xe2>;
> > +                                               reg =<0x800000e2>;
> >                                         };
> > 
> >                                         idt@d6 {
> >                                                 // IDT 9DBV0641
> > clock buffer
> > -                                               reg = <0xd6>;
> > +                                               reg = <0x800000d6>;
> >                                         };
> > 
> >                                         tpm@a3 {
> > -                                               reg = <0xa3>;
> > +                                               reg = <0x800000a3>;
> >                                         };
> >                                 };
> >                                 i2c12: i2c-bus@440 {
> > --
> > 2.8.2
> > 
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Benjamin Herrenschmidt]

On Thu, 2016-05-05 at 22:55 +0930, Joel Stanley wrote:
> On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com>
> wrote:
> > 
> > From: Gavin Shan <gwshan@linux.vnet.ibm.com>
> > 
> > I don't know the specific PHY model deployed on Firestone BMC, but
> > currently used one (PHY_ID_BCM54210E) isn't correct. BCM54210E
> > supports 1000base-T but the PHY on Firestone BMC shouldn't support
> > that mode as uboot uses 100base-T mode.
> > 
> > When exposing 1000base-T capability, the MAC is forced to have the
> > same mode though the PHY is working in 100base-T mode in fact. It
> > causes the mode mismatch between PHY/MAC and the ethernet network
> > doesn't work.
> > 
> > It's a temporary fix. After the PHY model is confirmed, we need
> > to enable the correct PHY driver instead current one for BCM54210E.
> > 
> > Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> > 
> > [Cyril]
> > The plot thickens, it does appear that this IS the correct PHY on
> > firestones. This patch is definitely required for networking to be
> > functional though.
> We should get someone in Austin to boot a firestone without this
> patch
> and see what it does. You shouldn't need a pdu as long as you get it
> right the first time :)

The MAC in the ast2400 is a gigabit MAC. So it should all work normally
at 1000bT. If not, then something is wrong that needs to be
investigated:

	- Either the interface between MAC and PHY isn't wired
correctly (RGMII vs. RMII, RGMII uses more pins and a diff. clock)

	- Or we don't set a setting or strap somewhere to switch
between those modes (hardware strapping bit[7:6], SCU[A0], ...)

	- Both ?

If we are indeed limited to 100bT, then we should expose that one way
or another in the device-tree in order to limit the advertized speed in
the PHY driver.

Cheers,
Ben.

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Benjamin Herrenschmidt]

On Thu, 2016-05-05 at 11:27 +1000, Cyril Bur wrote:
> 
> [Cyril]
> The plot thickens, it does appear that this IS the correct PHY on
> firestones. This patch is definitely required for networking to be
> functional though.

You can't just change the broadcom driver that way. If we really need
to force it down, we need some kind of way to tell the driver at
runtime otherwise it won't be acceptable upstream.

Via some kind of DT property maybe ?

Ben.

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Cyril Bur]

On Fri, 06 May 2016 11:00:02 +1000
Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:

> On Thu, 2016-05-05 at 22:55 +0930, Joel Stanley wrote:
> > On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com>
> > wrote:  
> > > 
> > > From: Gavin Shan <gwshan@linux.vnet.ibm.com>
> > > 
> > > I don't know the specific PHY model deployed on Firestone BMC, but
> > > currently used one (PHY_ID_BCM54210E) isn't correct. BCM54210E
> > > supports 1000base-T but the PHY on Firestone BMC shouldn't support
> > > that mode as uboot uses 100base-T mode.
> > > 
> > > When exposing 1000base-T capability, the MAC is forced to have the
> > > same mode though the PHY is working in 100base-T mode in fact. It
> > > causes the mode mismatch between PHY/MAC and the ethernet network
> > > doesn't work.
> > > 
> > > It's a temporary fix. After the PHY model is confirmed, we need
> > > to enable the correct PHY driver instead current one for BCM54210E.
> > > 
> > > Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
> > > 
> > > [Cyril]
> > > The plot thickens, it does appear that this IS the correct PHY on
> > > firestones. This patch is definitely required for networking to be
> > > functional though.  
> > We should get someone in Austin to boot a firestone without this
> > patch
> > and see what it does. You shouldn't need a pdu as long as you get it
> > right the first time :)  
> 
> The MAC in the ast2400 is a gigabit MAC. So it should all work normally
> at 1000bT. If not, then something is wrong that needs to be
> investigated:
> 
> 	- Either the interface between MAC and PHY isn't wired
> correctly (RGMII vs. RMII, RGMII uses more pins and a diff. clock)
> 
> 	- Or we don't set a setting or strap somewhere to switch
> between those modes (hardware strapping bit[7:6], SCU[A0], ...)
> 
> 	- Both ?
> 

This is something I'm trying to confirm. The firestones I and Gavin have access
to appear to be prerelease, so anythings possible.

I am struggling to get access to a release firestone, when I do I'll check if
Gavins patch is necessary there. If so, then we'll have to start asking those
sorts of questions.

> If we are indeed limited to 100bT, then we should expose that one way
> or another in the device-tree in order to limit the advertized speed in
> the PHY driver.
> 

That is probably going to be the way to go if it turns out there's this issue
on all firestones.


Thanks,

Cyril

> Cheers,
> Ben.
> 

Re: [PATCH 4/6] arm/dts: Set I2C_TEN_BIT_ADDRESS in Firestone BMC board i2c addresses

[Cyril Bur]

On Fri, 06 May 2016 10:53:45 +1000
Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:

> On Thu, 2016-05-05 at 22:51 +0930, Joel Stanley wrote:
> > On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com>
> > wrote:
> > 
> > Did you work out why we needed this, and why it fixes things?
> > 
> > Should we be doing it for all the device trees?  
> 

I changed the ones that caused the kernel to barf, the reason for the barf
boiled mostly down to that...

> That's weird indeed... Is there a 10-bit device on that bus ? Otherwise
> we shouldn't emit 10-bit addresses. In general, 10-bit addresses stuff
> doesn't work, in my experience at least. We might be papering over some
> other problem...
> 

This is entirely possible, what and how, I have no idea.

Do you have any other ideas?


> > > 
> > > Signed-off-by: Cyril Bur <cyrilbur@gmail.com>
> > > ---
> > >  arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts | 12 ++++++------
> > >  1 file changed, 6 insertions(+), 6 deletions(-)
> > > 
> > > diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > > b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > > index 2b988e7..379b561 100644
> > > --- a/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > > +++ b/arch/arm/boot/dts/aspeed-bmc-opp-firestone.dts
> > > @@ -75,7 +75,7 @@
> > >                                 i2c5: i2c-bus@180 {
> > >                                         tmp423@98 {
> > >                                                 compatible =
> > > "ti,tmp423";
> > > -                                               reg = <0x98>;
> > > +                                               reg = <0x80000098>;
> > >                                         };
> > >                                 };
> > >                                 i2c6: i2c-bus@1c0 {
> > > @@ -98,27 +98,27 @@
> > >                                         status = "okay";
> > >                                         leds@c0 {
> > >                                                 compatible =
> > > "pca,pca9552led";
> > > -                                               reg = <0xc0>;
> > > +                                               reg = <0x800000c0>;
> > >                                                 // led9 -
> > > led_fault_n
> > >                                                 // led10 -
> > > pwr_led_n
> > >                                                 // led11 -
> > > rear_id_led_n
> > >                                         };
> > >                                         rtc@d0 {
> > >                                                 compatible =
> > > "dallas,ds3231";
> > > -                                               reg = <0xd0>;
> > > +                                               reg = <0x800000d0>;
> > >                                         };
> > >                                         si5338a@e2 {
> > >                                                 // SiLabs clock
> > > generator
> > > -                                               reg =<0xe2>;
> > > +                                               reg =<0x800000e2>;
> > >                                         };
> > > 
> > >                                         idt@d6 {
> > >                                                 // IDT 9DBV0641
> > > clock buffer
> > > -                                               reg = <0xd6>;
> > > +                                               reg = <0x800000d6>;
> > >                                         };
> > > 
> > >                                         tpm@a3 {
> > > -                                               reg = <0xa3>;
> > > +                                               reg = <0x800000a3>;
> > >                                         };
> > >                                 };
> > >                                 i2c12: i2c-bus@440 {
> > > --
> > > 2.8.2
> > > 
> > > _______________________________________________
> > > openbmc mailing list
> > > openbmc@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/openbmc  
> > _______________________________________________
> > openbmc mailing list
> > openbmc@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/openbmc  
> 

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Gavin Shan]

On Fri, May 06, 2016 at 11:00:02AM +1000, Benjamin Herrenschmidt wrote:
>On Thu, 2016-05-05 at 22:55 +0930, Joel Stanley wrote:
>> On Thu, May 5, 2016 at 10:57 AM, Cyril Bur <cyrilbur@gmail.com>
>> wrote:
>> > 
>> > From: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> > 
>> > I don't know the specific PHY model deployed on Firestone BMC, but
>> > currently used one (PHY_ID_BCM54210E) isn't correct. BCM54210E
>> > supports 1000base-T but the PHY on Firestone BMC shouldn't support
>> > that mode as uboot uses 100base-T mode.
>> > 
>> > When exposing 1000base-T capability, the MAC is forced to have the
>> > same mode though the PHY is working in 100base-T mode in fact. It
>> > causes the mode mismatch between PHY/MAC and the ethernet network
>> > doesn't work.
>> > 
>> > It's a temporary fix. After the PHY model is confirmed, we need
>> > to enable the correct PHY driver instead current one for BCM54210E.
>> > 
>> > Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
>> > 
>> > [Cyril]
>> > The plot thickens, it does appear that this IS the correct PHY on
>> > firestones. This patch is definitely required for networking to be
>> > functional though.
>> We should get someone in Austin to boot a firestone without this
>> patch
>> and see what it does. You shouldn't need a pdu as long as you get it
>> right the first time :)
>
>The MAC in the ast2400 is a gigabit MAC. So it should all work normally
>at 1000bT. If not, then something is wrong that needs to be
>investigated:
>
>	- Either the interface between MAC and PHY isn't wired
>correctly (RGMII vs. RMII, RGMII uses more pins and a diff. clock)
>
>	- Or we don't set a setting or strap somewhere to switch
>between those modes (hardware strapping bit[7:6], SCU[A0], ...)
>
>	- Both ?
>
>If we are indeed limited to 100bT, then we should expose that one way
>or another in the device-tree in order to limit the advertized speed in
>the PHY driver.
>

Ben, thanks for review. Yeah, it's a temporary (tentative) fixup. The
BCM54210E driver isn't used by farady driver only, it's not reasonable
to limit the capability in the PHY driver as it's going to affect other
driver. As you suggested in another thread, the best option would be
removing the 1000BASE-T capability in farady driver after the PHY is
probed, before it's started (connected) when it's asked by device tree.

I will investigate it when getting a chance. It seems Pin multiplexing
isn't configured correctly for RGMII in uboot. I dumped the MAC control
register (offset: 0x50). We have 100Mb mode there in uboot.

Thanks,
Gavin

>Cheers,
>Ben.
>

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Benjamin Herrenschmidt]

On Fri, 2016-05-06 at 11:32 +1000, Cyril Bur wrote:
> 
> This is something I'm trying to confirm. The firestones I and Gavin
> have access to appear to be prerelease, so anythings possible.
>
> I am struggling to get access to a release firestone, when I do I'll
> check if Gavins patch is necessary there. If so, then we'll have to
> start asking those sorts of questions.

So I talked to Sertac and he'll get you access to a GA level Firestone
next week. It should be wired as proper RGMII, ie, it shoul work...

Cheers,
Ben.

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Benjamin Herrenschmidt]

On Fri, 2016-05-06 at 21:19 +1000, Gavin Shan wrote:
> I will investigate it when getting a chance. It seems Pin multiplexing
> isn't configured correctly for RGMII in uboot. I dumped the MAC control
> register (offset: 0x50). We have 100Mb mode there in uboot.

Can we fix this or is this dependent on the straps ? What is the straps
settings ? Can it be changed in SW ?

Cheers,
Ben.

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Sertac Cakici]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

Ragu has let us borrow his system. It's GA level HW.

BMC: fr999.aus.stglabs.ibm.com
Ubuntu: fr999p01.aus.stglabs.ibm.com

Sertaç
史塔奇




From:   Benjamin Herrenschmidt <benh@au1.ibm.com>
To:     Cyril Bur <cyrilbur@gmail.com>
Cc:     Joel Stanley <joel@jms.id.au>, OpenBMC Maillist 
<openbmc@lists.ozlabs.org>, Gavin Shan <gwshan@linux.vnet.ibm.com>, Sertac 
Cakici/Austin/IBM@IBMUS
Date:   05/06/2016 06:42 PM
Subject:        Re: [PATCH 6/6] net/phy: Expose 100base-T capability only



On Fri, 2016-05-06 at 11:32 +1000, Cyril Bur wrote:
> 
> This is something I'm trying to confirm. The firestones I and Gavin
> have access to appear to be prerelease, so anythings possible.
>
> I am struggling to get access to a release firestone, when I do I'll
> check if Gavins patch is necessary there. If so, then we'll have to
> start asking those sorts of questions.

So I talked to Sertac and he'll get you access to a GA level Firestone
next week. It should be wired as proper RGMII, ie, it shoul work...

Cheers,
Ben.





[-- Attachment #2: Type: text/html, Size: 1960 bytes --]

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Cyril Bur]

On Mon, 9 May 2016 14:51:00 -0500
"Sertac Cakici" <cakici@us.ibm.com> wrote:

Hi Sertac,

I got access to fr112 and only managed to get tftp booting going on it
yesterday, all good though, I've tested what I need. Interestingly on that
machine networking behaves as we expected and Gavins workaround isn't needed.

I know this is a long shot but do you know how our firestones in Canberra (which
are clearly pre GA) might differ?

Thanks,

Cyril

> Ragu has let us borrow his system. It's GA level HW.
> 
> BMC: fr999.aus.stglabs.ibm.com
> Ubuntu: fr999p01.aus.stglabs.ibm.com
> 
> Sertaç
> 史塔奇
> 
> 
> 
> 
> From:   Benjamin Herrenschmidt <benh@au1.ibm.com>
> To:     Cyril Bur <cyrilbur@gmail.com>
> Cc:     Joel Stanley <joel@jms.id.au>, OpenBMC Maillist 
> <openbmc@lists.ozlabs.org>, Gavin Shan <gwshan@linux.vnet.ibm.com>, Sertac 
> Cakici/Austin/IBM@IBMUS
> Date:   05/06/2016 06:42 PM
> Subject:        Re: [PATCH 6/6] net/phy: Expose 100base-T capability only
> 
> 
> 
> On Fri, 2016-05-06 at 11:32 +1000, Cyril Bur wrote:
> > 
> > This is something I'm trying to confirm. The firestones I and Gavin
> > have access to appear to be prerelease, so anythings possible.
> >
> > I am struggling to get access to a release firestone, when I do I'll
> > check if Gavins patch is necessary there. If so, then we'll have to
> > start asking those sorts of questions.  
> 
> So I talked to Sertac and he'll get you access to a GA level Firestone
> next week. It should be wired as proper RGMII, ie, it shoul work...
> 
> Cheers,
> Ben.
> 
> 
> 
> 

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Benjamin Herrenschmidt]

On Tue, 2016-05-10 at 10:38 +1000, Cyril Bur wrote:
> I got access to fr112 and only managed to get tftp booting going on it
> yesterday, all good though, I've tested what I need. Interestingly on that
> machine networking behaves as we expected and Gavins workaround isn't needed.
> 
> I know this is a long shot but do you know how our firestones in Canberra (which
> are clearly pre GA) might differ?

Cyril, could it just be a different uBoot messing with the pin/strap
config ?

Ben.

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Cyril Bur]

On Tue, 10 May 2016 12:33:26 +1000
Benjamin Herrenschmidt <benh@au1.ibm.com> wrote:

> On Tue, 2016-05-10 at 10:38 +1000, Cyril Bur wrote:
> > I got access to fr112 and only managed to get tftp booting going on it
> > yesterday, all good though, I've tested what I need. Interestingly on that
> > machine networking behaves as we expected and Gavins workaround isn't needed.
> > 
> > I know this is a long shot but do you know how our firestones in Canberra (which
> > are clearly pre GA) might differ?  
> 
> Cyril, could it just be a different uBoot messing with the pin/strap
> config ?
> 

I can't find any difference between the u-boot config registers on fstn2 and
fr112. Joel did suggest the PHY might have strapping difference but I can't
find anything that suggests it can be changed in software.

I will try putting identical versions of AMI firmware (ours is slightly old),
maybe they updated their u-boot to do something special.

> Ben.
> 
> _______________________________________________
> openbmc mailing list
> openbmc@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc

Re: [PATCH 6/6] net/phy: Expose 100base-T capability only

[Chris Austen]

[-- Attachment #1: Type: text/html, Size: 3402 bytes --]