Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
DDR3 RAM - 256 MB
Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
2.4GHz - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
5GHz x 2 - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
Ports - 8 Ports, 1 WAN Ports
Antennas - 8 Antennas
Serial Port - @J6 [GND,TX,RX] (VCC NC) 115200 8n1
I was able to test this with Lede with following quirks.
- Broadcom 4366c0 wireless chip is used and it's firmware package doesn't
exist yet. I was able to test it with firmware that came buried in the
router's dhd.ko
- CPU is connected to port 5
- It has two switches in order to support 8 lan ports. Internal switch is
BCM53012. The external switch BCM53125 currently works as "dumb switch"
- Using 8 bit ECC gives errors, switching to 1 bit ECC solved the issue
- It uses dual firmware (trx) copies for failsafe purposes.
Installation
------------
Linksys gpg-signs their firmware for this router, hence it is not
possible to install using Factory UI.
This router needs serial cable hooked up to J6. Then interrupt the boot
process by Ctrl+C to enter CFE prompt
From there execute:
`flash -noheader 192.168.1.10:/lede.trx nflash0.trx`
where 192.168.1.10 is where your tftp server should is running.
You may want to reset partial boots using
`nvram set partialboot=0 && nvram commit' while at CFE prompt.
TODO
----
- Add BCM53125 (secondary switch) to dts
- Add robo_reset gpio (pin# 10 active low) to dts
Signed-off-by: Vivek Unune <[email protected]>
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 97 ++++++++++++++++++++++++-
1 file changed, 96 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index b6750f7..75537ed 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -7,7 +7,7 @@
/dts-v1/;
#include "bcm47094.dtsi"
-#include "bcm5301x-nand-cs0-bch8.dtsi"
+#include "bcm5301x-nand-cs0-bch1.dtsi"
/ {
compatible = "linksys,panamera", "brcm,bcm47094", "brcm,bcm4708";
@@ -32,5 +32,100 @@
linux,code = <KEY_WPS_BUTTON>;
gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
};
+
+ rfkill {
+ label = "WiFi";
+ linux,code = <KEY_RFKILL>;
+ gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
+ };
+
+ reset {
+ label = "Reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wps {
+ label = "bcm53xx:white:wps";
+ gpios = <&chipcommon 22 GPIO_ACTIVE_LOW>;
+ };
+
+ usb2 {
+ label = "bcm53xx:green:usb2";
+ gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
+ };
+
+ usb3 {
+ label = "bcm53xx:green:usb3";
+ gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
+ };
+
+ power {
+ label = "bcm53xx:white:power";
+ gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi-disabled {
+ label = "bcm53xx:amber:wifi-disabled";
+ gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-enabled {
+ label = "bcm53xx:white:wifi-enabled";
+ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar1 {
+ label = "bcm53xx:white:bluebar1";
+ gpios = <&chipcommon 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar2 {
+ label = "bcm53xx:white:bluebar2";
+ gpios = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar3 {
+ label = "bcm53xx:white:bluebar3";
+ gpios = <&chipcommon 15 GPIO_ACTIVE_LOW>;
+ };
+
+ bluebar4 {
+ label = "bcm53xx:white:bluebar4";
+ gpios = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar5 {
+ label = "bcm53xx:white:bluebar5";
+ gpios = <&chipcommon 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar6 {
+ label = "bcm53xx:white:bluebar6";
+ gpios = <&chipcommon 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar7 {
+ label = "bcm53xx:white:bluebar7";
+ gpios = <&chipcommon 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar8 {
+ label = "bcm53xx:white:bluebar8";
+ gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
+ };
+
};
};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
+};
--
2.7.4
Hi Vivek
> - It has two switches in order to support 8 lan ports. Internal switch is
> BCM53012. The external switch BCM53125 currently works as "dumb switch"
Do you know how the second switch is connected? Is it cascaded off the
internal switch? Or does it have a dedicated Ethernet interface?
Thanks
Andrew
Andrew,
I'm not entirely sure. But here is what I observed.
Bootloader sets up both the switches. And I can use all 8 ports of the
router when I boot Lede. Only the internal switch is detected and
configurable via swconfig tool
Internal switch is connected to CPU via port 5 same as Netgear R8000.
The other bit here is that I looked through the GPL source and gpio
pin 10 is labeled as EA9500_RST2LANSW_GPIO10_PIN/ResetSwitch. So when
I performed a robo reset of the pin and 5 ports (labeled 1 thru 5 on
the unit) of the 8 physical ports stopped working (no packets).
If the external switch were to be connect via dedicated ethernet
interface it should have shown up during the probe. Is in't it?
Unfortunately my understanding about network devices limits me to
investigate this further.
I'll be more than happy to perform any tests if needed.
Thanks,
Vivek
P.S sorry for duplicate email if you did get this first time around.
I've turned off HTML formatting.
>
>
> On Wed, Mar 15, 2017 at 2:52 PM Andrew Lunn <[email protected]> wrote:
>>
>> Hi Vivek
>>
>> > - It has two switches in order to support 8 lan ports. Internal switch is
>> > BCM53012. The external switch BCM53125 currently works as "dumb switch"
>>
>> Do you know how the second switch is connected? Is it cascaded off the
>> internal switch? Or does it have a dedicated Ethernet interface?
>>
>> Thanks
>> Andrew
On 03/15/2017 12:34 PM, Vivek Unune wrote:
> Andrew,
>
> I'm not entirely sure. But here is what I observed.
>
> Boot loader sets up both the switches. And I can use all 8 ports of the
> router when I boot Lede. Only the internal swich is detected and
> configurable via swconfig tool
> Internal switch is connected to CPU via port 5 same as Netgear R8000.
> The other bit here is that I looked through the GPL source and gpio pin
> 10 is labeled as EA9500_RST2LANSW_GPIO10_PIN/ResetSwitch. So when I
> performed a robo reset of the pin and 5 (labeled 1 thru 5 on the unit)
> of the 8 physical ports stopped working (no packets).
>
> If the external switch were to be connect via dedicated ethernet
> interface it should have shown up during the probe. Is in't it?
Not necessarily, and probably not with LEDE which would treat the
external 53125 as a dumb switch and not even see it. With a mainline
kernel and the B53 DSA driver you would be able to represent both
switches in Device Tree and describe how they are cascading from each other.
The potential Device Tree changes could look like this (based on your
explanation, but I am not sure) for your platform, assuming the 53125 is
actually exposing the front panel ports and that we did introduce a
"mdio" node which would be required to expose the external BCM53125 switch.
/* There is no MDIO node, there should be one */
&mdio {
status = "okay";
switch@30 {
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&gpio 10>;
reset-names = "robo_reset";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan2";
};
port@2 {
reg = <2>;
label = "lan3";
};
port@3 {
reg = <3>;
label = "lan1";
};
port@4 {
reg = <4>;
label = "wan";
};
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&sw0port8>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
&srab {
status = "okay";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@5 {
reg = <5>;
label = "cpu";
ethernet = <&gmac0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
sw0port8: port@8 {
reg = <8>;
label = "extswitch";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
>
> Thanks,
>
> Vivek
>
>
> On Wed, Mar 15, 2017 at 2:52 PM Andrew Lunn <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Vivek
>
> > - It has two switches in order to support 8 lan ports. Internal
> switch is
> > BCM53012. The external switch BCM53125 currently works as "dumb
> switch"
>
> Do you know how the second switch is connected? Is it cascaded off the
> internal switch? Or does it have a dedicated Ethernet interface?
>
> Thanks
> Andrew
>
--
Florian
Thanks Florian.
Let me try this out. First I'll try to figure out how to add a mdio node.
Over the weekend I was trying enable DSA driver, but did not see DSA
under network. I'm using LEDE source with kernel 4.9. Nor did I see it
when I tried 'make kernel_menuconfig'
Thanks again.
On Wed, Mar 15, 2017 at 3:49 PM, Florian Fainelli
<[email protected]> wrote:
> On 03/15/2017 12:34 PM, Vivek Unune wrote:
>> Andrew,
>>
>> I'm not entirely sure. But here is what I observed.
>>
>> Boot loader sets up both the switches. And I can use all 8 ports of the
>> router when I boot Lede. Only the internal swich is detected and
>> configurable via swconfig tool
>> Internal switch is connected to CPU via port 5 same as Netgear R8000.
>> The other bit here is that I looked through the GPL source and gpio pin
>> 10 is labeled as EA9500_RST2LANSW_GPIO10_PIN/ResetSwitch. So when I
>> performed a robo reset of the pin and 5 (labeled 1 thru 5 on the unit)
>> of the 8 physical ports stopped working (no packets).
>>
>> If the external switch were to be connect via dedicated ethernet
>> interface it should have shown up during the probe. Is in't it?
>
> Not necessarily, and probably not with LEDE which would treat the
> external 53125 as a dumb switch and not even see it. With a mainline
> kernel and the B53 DSA driver you would be able to represent both
> switches in Device Tree and describe how they are cascading from each other.
>
> The potential Device Tree changes could look like this (based on your
> explanation, but I am not sure) for your platform, assuming the 53125 is
> actually exposing the front panel ports and that we did introduce a
> "mdio" node which would be required to expose the external BCM53125 switch.
>
>
> /* There is no MDIO node, there should be one */
> &mdio {
> status = "okay";
>
> switch@30 {
> #address-cells = <1>;
> #size-cells = <0>;
> reset-gpios = <&gpio 10>;
> reset-names = "robo_reset";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> label = "lan1";
> };
>
> port@1 {
> reg = <1>;
> label = "lan2";
> };
>
> port@2 {
> reg = <2>;
> label = "lan3";
> };
>
> port@3 {
> reg = <3>;
> label = "lan1";
> };
>
> port@4 {
> reg = <4>;
> label = "wan";
> };
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <&sw0port8>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> };
> };
> };
>
> &srab {
> status = "okay";
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <&gmac0>;
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
>
> sw0port8: port@8 {
> reg = <8>;
> label = "extswitch";
>
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> };
> };
>
>>
>> Thanks,
>>
>> Vivek
>>
>>
>> On Wed, Mar 15, 2017 at 2:52 PM Andrew Lunn <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Vivek
>>
>> > - It has two switches in order to support 8 lan ports. Internal
>> switch is
>> > BCM53012. The external switch BCM53125 currently works as "dumb
>> switch"
>>
>> Do you know how the second switch is connected? Is it cascaded off the
>> internal switch? Or does it have a dedicated Ethernet interface?
>>
>> Thanks
>> Andrew
>>
>
>
> --
> Florian
On 03/15/2017 01:18 PM, Vivek Unune wrote:
> Thanks Florian.
>
> Let me try this out. First I'll try to figure out how to add a mdio node.
>
> Over the weekend I was trying enable DSA driver, but did not see DSA
> under network. I'm using LEDE source with kernel 4.9. Nor did I see it
> when I tried 'make kernel_menuconfig'
(please don't top post on public mailing lists)
You need to enable SWITCHDEV to have DSA. AFAIR SWITCHDEV may depend on
EXPERT/EXPERIMENTAL as of 4.9 (or that was before).
>
> Thanks again.
>
> On Wed, Mar 15, 2017 at 3:49 PM, Florian Fainelli
> <[email protected]> wrote:
>> On 03/15/2017 12:34 PM, Vivek Unune wrote:
>>> Andrew,
>>>
>>> I'm not entirely sure. But here is what I observed.
>>>
>>> Boot loader sets up both the switches. And I can use all 8 ports of the
>>> router when I boot Lede. Only the internal swich is detected and
>>> configurable via swconfig tool
>>> Internal switch is connected to CPU via port 5 same as Netgear R8000.
>>> The other bit here is that I looked through the GPL source and gpio pin
>>> 10 is labeled as EA9500_RST2LANSW_GPIO10_PIN/ResetSwitch. So when I
>>> performed a robo reset of the pin and 5 (labeled 1 thru 5 on the unit)
>>> of the 8 physical ports stopped working (no packets).
>>>
>>> If the external switch were to be connect via dedicated ethernet
>>> interface it should have shown up during the probe. Is in't it?
>>
>> Not necessarily, and probably not with LEDE which would treat the
>> external 53125 as a dumb switch and not even see it. With a mainline
>> kernel and the B53 DSA driver you would be able to represent both
>> switches in Device Tree and describe how they are cascading from each other.
>>
>> The potential Device Tree changes could look like this (based on your
>> explanation, but I am not sure) for your platform, assuming the 53125 is
>> actually exposing the front panel ports and that we did introduce a
>> "mdio" node which would be required to expose the external BCM53125 switch.
>>
>>
>> /* There is no MDIO node, there should be one */
>> &mdio {
>> status = "okay";
>>
>> switch@30 {
>> #address-cells = <1>;
>> #size-cells = <0>;
>> reset-gpios = <&gpio 10>;
>> reset-names = "robo_reset";
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@0 {
>> reg = <0>;
>> label = "lan1";
>> };
>>
>> port@1 {
>> reg = <1>;
>> label = "lan2";
>> };
>>
>> port@2 {
>> reg = <2>;
>> label = "lan3";
>> };
>>
>> port@3 {
>> reg = <3>;
>> label = "lan1";
>> };
>>
>> port@4 {
>> reg = <4>;
>> label = "wan";
>> };
>>
>> port@5 {
>> reg = <5>;
>> label = "cpu";
>> ethernet = <&sw0port8>;
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>> };
>> };
>> };
>> };
>>
>> &srab {
>> status = "okay";
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@5 {
>> reg = <5>;
>> label = "cpu";
>> ethernet = <&gmac0>;
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>> };
>>
>> sw0port8: port@8 {
>> reg = <8>;
>> label = "extswitch";
>>
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>> };
>> };
>> };
>>
>>>
>>> Thanks,
>>>
>>> Vivek
>>>
>>>
>>> On Wed, Mar 15, 2017 at 2:52 PM Andrew Lunn <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi Vivek
>>>
>>> > - It has two switches in order to support 8 lan ports. Internal
>>> switch is
>>> > BCM53012. The external switch BCM53125 currently works as "dumb
>>> switch"
>>>
>>> Do you know how the second switch is connected? Is it cascaded off the
>>> internal switch? Or does it have a dedicated Ethernet interface?
>>>
>>> Thanks
>>> Andrew
>>>
>>
>>
>> --
>> Florian
--
Florian
On Wed, Mar 15, 2017 at 5:19 PM, Florian Fainelli
<[email protected]> wrote:
> On 03/15/2017 01:18 PM, Vivek Unune wrote:
>> Thanks Florian.
>>
>> Let me try this out. First I'll try to figure out how to add a mdio node.
>>
>> Over the weekend I was trying enable DSA driver, but did not see DSA
>> under network. I'm using LEDE source with kernel 4.9. Nor did I see it
>> when I tried 'make kernel_menuconfig'
>
> (please don't top post on public mailing lists)
>
> You need to enable SWITCHDEV to have DSA. AFAIR SWITCHDEV may depend on
> EXPERT/EXPERIMENTAL as of 4.9 (or that was before).
>
Florian,
I have managed to use DSA driver and was able detect both internal and
external switches. However, I only get packets flowing only through the
internal switch. I have used the ip & bridge commands to setup the vlan
101 & 102 for lan and wan respectively.
VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101
VLAN102 = wan eth0.102
Reading configs from the factory firmware, I'm sure that sw0port0 and
sw1port8 are connected. Excerpt from the same:
port_numbers=0 2 4 2 1 3 1 3
port_switch_id=1 1 1 0 1 1 0 0
port_names=port0 port1 port2 port3 port4 port5 port6 port7
cpu_port_number=5 7 8
cpu_port_switch_id=0 0 0
hidden_port_numbers=0 8
hidden_port_switch_id=0 1
Below is my updated device tree.
Thanks,
Vivek
&srab {
compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
status = "okay";
dsa,member = <0 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@1 {
reg = <1>;
label = "lan7";
};
port@2 {
reg = <2>;
label = "lan4";
};
port@3 {
reg = <3>;
label = "lan8";
};
port@4 {
reg = <4>;
label = "wan";
};
port@5 {
reg = <5>;
ethernet = <&gmac0>;
label = "cpu";
fixed-link {
speed = <1000>;
full-duplex;
};
};
sw0port0: port@0 {
reg = <0>;
label = "extswitch";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
&mdiomux {
mdio-slave@0 {
reg = <0x00>;
address-cells = <1>;
size-cells = <0>;
switch@0 {
compatible = "brcm,bcm53125";
#address-cells = <1>;
#size-cells = <0>;
reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
reset-names = "robo_reset";
reg = <0>;
dsa,member = <1 0>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "lan1";
};
port@1 {
reg = <1>;
label = "lan5";
};
port@2 {
reg = <2>;
label = "lan2";
};
port@3 {
reg = <3>;
label = "lan6";
};
port@4 {
reg = <4>;
label = "lan3";
};
sw1port8:port@8 {
reg = <8>;
ethernet = <&sw0port0>;
label = "cpu";
phy-mode = "rgmii-txid";
fixed-link {
speed = <1000>;
full-duplex;
};
};
};
};
};
};
Hi Vivek,
On 06/27/2017 10:03 AM, Vivek Unune wrote:
> On Wed, Mar 15, 2017 at 5:19 PM, Florian Fainelli
> <[email protected]> wrote:
>> On 03/15/2017 01:18 PM, Vivek Unune wrote:
>>> Thanks Florian.
>>>
>>> Let me try this out. First I'll try to figure out how to add a mdio node.
>>>
>>> Over the weekend I was trying enable DSA driver, but did not see DSA
>>> under network. I'm using LEDE source with kernel 4.9. Nor did I see it
>>> when I tried 'make kernel_menuconfig'
>>
>> (please don't top post on public mailing lists)
>>
>> You need to enable SWITCHDEV to have DSA. AFAIR SWITCHDEV may depend on
>> EXPERT/EXPERIMENTAL as of 4.9 (or that was before).
>>
>
> Florian,
>
> I have managed to use DSA driver and was able detect both internal and
> external switches. However, I only get packets flowing only through the
> internal switch. I have used the ip & bridge commands to setup the vlan
> 101 & 102 for lan and wan respectively.
>
> VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101
That looks reasonable although keep in mind that the IMP/CPU interfaces
of the switch are configured with VLAN tags (see commit [1]), so you may
need to make sure that port 0 of the internal switch is not accidentally
configured back to untagged since that would cause problem when
terminating the VLAN tag on the SW side.
So here are a few things that you want to check:
- read the MIB counters from the "extswitch" interface and see if
packets flow through in both directions with no errors
- check the "extswitch" VLAN configuration on both the internal switch
side (port 0) and on the external switch side ("cpu", port 8, not visible)
- see if you can get traffic end-to-end from eth0 all the way through
one of the external switch port. If that's the case, that means that the
configuration of internal switch port 0, internal switch CPU port, and
external switch external port is working and operational
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d
> VLAN102 = wan eth0.102
>
> Reading configs from the factory firmware, I'm sure that sw0port0 and> sw1port8 are connected. Excerpt from the same:
>
> port_numbers=0 2 4 2 1 3 1 3
> port_switch_id=1 1 1 0 1 1 0 0
> port_names=port0 port1 port2 port3 port4 port5 port6 port7
Is 0 the identifier for the external or internal switch? If 0 is
internal switch identifier and 1 is the external switch identifier, your
mapping looks correct to me with one exception below:
> cpu_port_number=5 7 8
> cpu_port_switch_id=0 0 0
> hidden_port_numbers=0 8
> hidden_port_switch_id=0 1
>
> Below is my updated device tree.
>
> Thanks,
>
> Vivek
>
> &srab {
> compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
> status = "okay";
> dsa,member = <0 0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@1 {
> reg = <1>;
> label = "lan7";
> };
>
> port@2 {
> reg = <2>;
> label = "lan4";
> };
>
> port@3 {
> reg = <3>;
> label = "lan8";
> };
>
> port@4 {
> reg = <4>;
> label = "wan";
> };
>
> port@5 {
> reg = <5>;
> ethernet = <&gmac0>;
> label = "cpu";
>
> fixed-link {
>
> speed = <1000>;
> full-duplex;
> };
> };
I think this is meant to be port 8 here based on the hidden_port_number
value. This actually matters for VLAN configuration because B53 is not
(unfortunately, to be fixed) consistently using dst->cpu_port (whatever
is configured in Device Tree) vs. dev->cpu_port (hardcoded to 8 for this
class of switch).
PS: on that front, we will have to rework that when we bring multiple
CPU port support in DSA/B53/bcm_sf2 and so for now what we could do is
just check that the configured CPU port in Device Tree is a valid CPU
port for that switch (typically 5, 7 or 8), and if not, just issue a
warning.
>
> sw0port0: port@0 {
> reg = <0>;
> label = "extswitch";
>
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
There might be some additional configuration needed here for this port,
because by default, the port will most likely try to use its built-in
PHY and maybe that's what they did, they wired the built-in PHY directly
to the IMP port of the external switch.
> };
> };
> };
>
> &mdiomux {
> mdio-slave@0 {
> reg = <0x00>;
> address-cells = <1>;
> size-cells = <0>;
>
> switch@0 {
> compatible = "brcm,bcm53125";
> #address-cells = <1>;
> #size-cells = <0>;
> reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
> reset-names = "robo_reset";
> reg = <0>;
> dsa,member = <1 0>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> label = "lan1";
> };
>
> port@1 {
> reg = <1>;
> label = "lan5";
> };
>
> port@2 {
> reg = <2>;
> label = "lan2";
> };
>
> port@3 {
> reg = <3>;
> label = "lan6";
> };
>
> port@4 {
> reg = <4>;
> label = "lan3";
> };
>
> sw1port8:port@8 {
> reg = <8>;
> ethernet = <&sw0port0>;
> label = "cpu";
> phy-mode = "rgmii-txid";
>
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> };
> };
> };
> };
>
--
Florian
Florian,
>> I have managed to use DSA driver and was able detect both internal and
>> external switches. However, I only get packets flowing only through the
>> internal switch. I have used the ip & bridge commands to setup the vlan
>> 101 & 102 for lan and wan respectively.
>>
>> VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101
>
> That looks reasonable although keep in mind that the IMP/CPU interfaces
> of the switch are configured with VLAN tags (see commit [1]), so you may
> need to make sure that port 0 of the internal switch is not accidentally
> configured back to untagged since that would cause problem when
> terminating the VLAN tag on the SW side.
>
> So here are a few things that you want to check:
>
> - read the MIB counters from the "extswitch" interface and see if
> packets flow through in both directions with no errors
lan4 is on internal switch, lan1 on external. I cannot ping router from lan1
Inter- | Receive | Transmit
face |bytes packets errs drop|bytes packets errs drop
br-lan: 168590 1726 0 0 190542 753 0 0
extswitch: 0 0 0 0 101012 1221 0 0
lan1: 0 0 0 0 5382 111 0 0
lan4: 0 0 0 0 1306680 13909 0 0
eth0: 3276924 5539 0 0 1106135 5084 0 0
eth0.101: 169338 1732 0 0 190256 750 0 0
eth0.102: 2959522 3274 0 0 587248 1094 0 0
lo: 39390 502 0 0 39390 502 0 0
br-wan: 2956822 3254 0 0 587248 1094 0 0
>
> - check the "extswitch" VLAN configuration on both the internal switch
> side (port 0) and on the external switch side ("cpu", port 8, not visible)
#bridge vlan show
port vlan ids
extswitch None
extswitch
lan7 101 PVID Egress Untagged
lan7 101 PVID Egress Untagged
lan4 101 PVID Egress Untagged
lan4 101 PVID Egress Untagged
lan8 101 PVID Egress Untagged
lan8 101 PVID Egress Untagged
wan 102 PVID Egress Untagged
wan 102 PVID Egress Untagged
lan1 101 PVID Egress Untagged
lan1 101 PVID Egress Untagged
lan5 101 PVID Egress Untagged
lan5 101 PVID Egress Untagged
lan2 101 PVID Egress Untagged
lan2 101 PVID Egress Untagged
lan6 101 PVID Egress Untagged
lan6 101 PVID Egress Untagged
lan3 101 PVID Egress Untagged
lan3 101 PVID Egress Untagged
br-lan None
eth0.101 101 PVID Egress Untagged
eth0.101
br-wan None
eth0.102 102 PVID Egress Untagged
eth0.102
>
> - see if you can get traffic end-to-end from eth0 all the way through
> one of the external switch port. If that's the case, that means that the
> configuration of internal switch port 0, internal switch CPU port, and
> external switch external port is working and operational
>
> [1]:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d
>
>> VLAN102 = wan eth0.102
>>
>> Reading configs from the factory firmware, I'm sure that sw0port0 and> sw1port8 are connected. Excerpt from the same:
>>
>> port_numbers=0 2 4 2 1 3 1 3
>> port_switch_id=1 1 1 0 1 1 0 0
>> port_names=port0 port1 port2 port3 port4 port5 port6 port7
>
> Is 0 the identifier for the external or internal switch? If 0 is
> internal switch identifier and 1 is the external switch identifier, your
> mapping looks correct to me with one exception below:
0 is internal here.
>
>> cpu_port_number=5 7 8
>> cpu_port_switch_id=0 0 0
>> hidden_port_numbers=0 8
>> hidden_port_switch_id=0 1
>>
>> Below is my updated device tree.
>>
>> Thanks,
>>
>> Vivek
>>
>> &srab {
>> compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
>> status = "okay";
>> dsa,member = <0 0>;
>>
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> port@1 {
>> reg = <1>;
>> label = "lan7";
>> };
>>
>> port@2 {
>> reg = <2>;
>> label = "lan4";
>> };
>>
>> port@3 {
>> reg = <3>;
>> label = "lan8";
>> };
>>
>> port@4 {
>> reg = <4>;
>> label = "wan";
>> };
>>
>> port@5 {
>> reg = <5>;
>> ethernet = <&gmac0>;
>> label = "cpu";
>>
>> fixed-link {
>>
>> speed = <1000>;
>> full-duplex;
>> };
>> };
>
> I think this is meant to be port 8 here based on the hidden_port_number
> value. This actually matters for VLAN configuration because B53 is not
> (unfortunately, to be fixed) consistently using dst->cpu_port (whatever
> is configured in Device Tree) vs. dev->cpu_port (hardcoded to 8 for this
> class of switch).
When I connect to port 8 I receive no packets on internal switch.
>
> PS: on that front, we will have to rework that when we bring multiple
> CPU port support in DSA/B53/bcm_sf2 and so for now what we could do is
> just check that the configured CPU port in Device Tree is a valid CPU
> port for that switch (typically 5, 7 or 8), and if not, just issue a
> warning.
>
>>
>> sw0port0: port@0 {
>> reg = <0>;
>> label = "extswitch";
>>
>> fixed-link {
>> speed = <1000>;
>> full-duplex;
>> };
>
> There might be some additional configuration needed here for this port,
> because by default, the port will most likely try to use its built-in
> PHY and maybe that's what they did, they wired the built-in PHY directly
> to the IMP port of the external switch.
Do you know what that configuration might be?
Thanks,
Vivek
Florian,
On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune <[email protected]> wrote:
> Florian,
>
>>> I have managed to use DSA driver and was able detect both internal and
>>> external switches. However, I only get packets flowing only through the
>>> internal switch. I have used the ip & bridge commands to setup the vlan
>>> 101 & 102 for lan and wan respectively.
>>>
>>> VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101
>>
>> That looks reasonable although keep in mind that the IMP/CPU interfaces
>> of the switch are configured with VLAN tags (see commit [1]), so you may
>> need to make sure that port 0 of the internal switch is not accidentally
>> configured back to untagged since that would cause problem when
>> terminating the VLAN tag on the SW side.
>>
>> So here are a few things that you want to check:
>>
>> - read the MIB counters from the "extswitch" interface and see if
>> packets flow through in both directions with no errors
>
> lan4 is on internal switch, lan1 on external. I cannot ping router from lan1
>
> Inter- | Receive | Transmit
> face |bytes packets errs drop|bytes packets errs drop
> br-lan: 168590 1726 0 0 190542 753 0 0
> extswitch: 0 0 0 0 101012 1221 0 0
> lan1: 0 0 0 0 5382 111 0 0
> lan4: 0 0 0 0 1306680 13909 0 0
> eth0: 3276924 5539 0 0 1106135 5084 0 0
> eth0.101: 169338 1732 0 0 190256 750 0 0
> eth0.102: 2959522 3274 0 0 587248 1094 0 0
> lo: 39390 502 0 0 39390 502 0 0
> br-wan: 2956822 3254 0 0 587248 1094 0 0
>
Please ignore above mib counters. I noticed that I see lot of RxFCSErrors
and RxSymbolErrors for extswitch. The count for both counters always
remain same.
root@LEDE:/# ethtool -S extswitch
NIC statistics:
tx_packets: 212
tx_bytes: 19179
rx_packets: 0
rx_bytes: 0
TxOctets: 14403
TxDropPkts: 0
TxBroadcastPkts: 24
TxMulticastPkts: 122
TxUnicastPkts: 0
TxCollisions: 0
TxSingleCollision: 0
TxMultipleCollision: 0
TxDeferredTransmit: 0
TxLateCollision: 0
TxExcessiveCollision: 0
TxPausePkts: 0
RxOctets: 3593
RxUndersizePkts: 0
RxPausePkts: 0
Pkts64Octets: 0
Pkts65to127Octets: 36
Pkts128to255Octets: 1
Pkts256to511Octets: 0
Pkts512to1023Octets: 0
Pkts1024to1522Octets: 0
RxOversizePkts: 0
RxJabbers: 0
RxAlignmentErrors: 0
RxFCSErrors: 37
RxGoodOctets: 0
RxDropPkts: 0
RxUnicastPkts: 0
RxMulticastPkts: 0
RxBroadcastPkts: 0
RxSAChanges: 0
RxFragments: 0
RxJumboPkts: 0
RxSymbolErrors: 37
RxDiscarded: 0
p08_TxOctets: 47537
p08_TxDropPkts: 0
p08_TxBroadcastPkts: 163
p08_TxMulticastPkts: 319
p08_TxUnicastPkts: 0
p08_TxCollisions: 0
p08_TxSingleCollision: 0
p08_TxMultipleCollision: 0
p08_TxDeferredTransmit: 0
p08_TxLateCollision: 0
p08_TxExcessiveCollision: 0
p08_TxPausePkts: 0
p08_RxOctets: 14403
p08_RxUndersizePkts: 0
p08_RxPausePkts: 0
p08_Pkts64Octets: 25
p08_Pkts65to127Octets: 102
p08_Pkts128to255Octets: 17
p08_Pkts256to511Octets: 2
p08_Pkts512to1023Octets: 0
p08_Pkts1024to1522Octets: 0
p08_RxOversizePkts: 0
p08_RxJabbers: 0
p08_RxAlignmentErrors: 0
p08_RxFCSErrors: 0
p08_RxGoodOctets: 14403
p08_RxDropPkts: 0
p08_RxUnicastPkts: 0
p08_RxMulticastPkts: 122
p08_RxBroadcastPkts: 24
p08_RxSAChanges: 40
p08_RxFragments: 0
p08_RxJumboPkts: 0
p08_RxSymbolErrors: 0
p08_RxDiscarded: 146
>>
>> - check the "extswitch" VLAN configuration on both the internal switch
>> side (port 0) and on the external switch side ("cpu", port 8, not visible)
>
> #bridge vlan show
> port vlan ids
> extswitch None
> extswitch
> lan7 101 PVID Egress Untagged
> lan7 101 PVID Egress Untagged
> lan4 101 PVID Egress Untagged
> lan4 101 PVID Egress Untagged
> lan8 101 PVID Egress Untagged
> lan8 101 PVID Egress Untagged
> wan 102 PVID Egress Untagged
> wan 102 PVID Egress Untagged
> lan1 101 PVID Egress Untagged
> lan1 101 PVID Egress Untagged
> lan5 101 PVID Egress Untagged
> lan5 101 PVID Egress Untagged
> lan2 101 PVID Egress Untagged
> lan2 101 PVID Egress Untagged
> lan6 101 PVID Egress Untagged
> lan6 101 PVID Egress Untagged
> lan3 101 PVID Egress Untagged
> lan3 101 PVID Egress Untagged
> br-lan None
> eth0.101 101 PVID Egress Untagged
> eth0.101
> br-wan None
> eth0.102 102 PVID Egress Untagged
> eth0.102
>
>>
>> - see if you can get traffic end-to-end from eth0 all the way through
>> one of the external switch port. If that's the case, that means that the
>> configuration of internal switch port 0, internal switch CPU port, and
>> external switch external port is working and operational
>>
>> [1]:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d
>>
>>> VLAN102 = wan eth0.102
>>>
>>> Reading configs from the factory firmware, I'm sure that sw0port0 and> sw1port8 are connected. Excerpt from the same:
>>>
>>> port_numbers=0 2 4 2 1 3 1 3
>>> port_switch_id=1 1 1 0 1 1 0 0
>>> port_names=port0 port1 port2 port3 port4 port5 port6 port7
>>
>> Is 0 the identifier for the external or internal switch? If 0 is
>> internal switch identifier and 1 is the external switch identifier, your
>> mapping looks correct to me with one exception below:
>
> 0 is internal here.
>
>>
>>> cpu_port_number=5 7 8
>>> cpu_port_switch_id=0 0 0
>>> hidden_port_numbers=0 8
>>> hidden_port_switch_id=0 1
>>>
>>> Below is my updated device tree.
>>>
>>> Thanks,
>>>
>>> Vivek
>>>
>>> &srab {
>>> compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
>>> status = "okay";
>>> dsa,member = <0 0>;
>>>
>>> ports {
>>> #address-cells = <1>;
>>> #size-cells = <0>;
>>>
>>> port@1 {
>>> reg = <1>;
>>> label = "lan7";
>>> };
>>>
>>> port@2 {
>>> reg = <2>;
>>> label = "lan4";
>>> };
>>>
>>> port@3 {
>>> reg = <3>;
>>> label = "lan8";
>>> };
>>>
>>> port@4 {
>>> reg = <4>;
>>> label = "wan";
>>> };
>>>
>>> port@5 {
>>> reg = <5>;
>>> ethernet = <&gmac0>;
>>> label = "cpu";
>>>
>>> fixed-link {
>>>
>>> speed = <1000>;
>>> full-duplex;
>>> };
>>> };
>>
>> I think this is meant to be port 8 here based on the hidden_port_number
>> value. This actually matters for VLAN configuration because B53 is not
>> (unfortunately, to be fixed) consistently using dst->cpu_port (whatever
>> is configured in Device Tree) vs. dev->cpu_port (hardcoded to 8 for this
>> class of switch).
>
> When I connect to port 8 I receive no packets on internal switch.
I'm able to now use sw0port8 <-> eth2 (i.e use cpu port 8 to connect to gmac2).
For this I had to modify net/dsa/b53/b53_common.c (see below). This is how
it is setup in net/phy/b53/b53_common.c. Also need to set
cpu_port = B53_CPU_PORT for 53012 sw instead of B53_CPU_PORT_25
@@ -357,9 +357,11 @@ static void b53_enable_vlan(struct b53_d
b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL5, &vc5);
}
- mgmt &= ~SM_SW_FWD_MODE;
if (enable) {
+
+ mgmt |= SM_SW_FWD_MODE;
+
vc0 |= VC0_VLAN_EN | VC0_VID_CHK_EN | VC0_VID_HASH_VID;
vc1 |= VC1_RX_MCST_UNTAG_EN | VC1_RX_MCST_FWD_EN;
vc4 &= ~VC4_ING_VID_CHECK_MASK;
>
>>
>> PS: on that front, we will have to rework that when we bring multiple
>> CPU port support in DSA/B53/bcm_sf2 and so for now what we could do is
>> just check that the configured CPU port in Device Tree is a valid CPU
>> port for that switch (typically 5, 7 or 8), and if not, just issue a
>> warning.
>>
>>>
>>> sw0port0: port@0 {
>>> reg = <0>;
>>> label = "extswitch";
>>>
>>> fixed-link {
>>> speed = <1000>;
>>> full-duplex;
>>> };
>>
>> There might be some additional configuration needed here for this port,
>> because by default, the port will most likely try to use its built-in
>> PHY and maybe that's what they did, they wired the built-in PHY directly
>> to the IMP port of the external switch.
>
> Do you know what that configuration might be?
Given that I see RxFCSErrors and RxSymbolErrors errors wrt extswitch.
configuration definitely needs tweaking. I tried setting the phy-mode to
rgmii and rgmii-txid but no go.
Thanks,
Vivek
On 08/13/2017 09:44 PM, Vivek Unune wrote:
> Florian,
>
> On Thu, Jun 29, 2017 at 5:04 PM, Vivek Unune <[email protected]> wrote:
>> Florian,
>>
>>>> I have managed to use DSA driver and was able detect both internal and
>>>> external switches. However, I only get packets flowing only through the
>>>> internal switch. I have used the ip & bridge commands to setup the vlan
>>>> 101 & 102 for lan and wan respectively.
>>>>
>>>> VLAN101 = lan1 lan2 lan3 lan4 lan5 lan6 lan7 lan8 eth0.101
>>>
>>> That looks reasonable although keep in mind that the IMP/CPU interfaces
>>> of the switch are configured with VLAN tags (see commit [1]), so you may
>>> need to make sure that port 0 of the internal switch is not accidentally
>>> configured back to untagged since that would cause problem when
>>> terminating the VLAN tag on the SW side.
>>>
>>> So here are a few things that you want to check:
>>>
>>> - read the MIB counters from the "extswitch" interface and see if
>>> packets flow through in both directions with no errors
>>
>> lan4 is on internal switch, lan1 on external. I cannot ping router from lan1
>>
>> Inter- | Receive | Transmit
>> face |bytes packets errs drop|bytes packets errs drop
>> br-lan: 168590 1726 0 0 190542 753 0 0
>> extswitch: 0 0 0 0 101012 1221 0 0
>> lan1: 0 0 0 0 5382 111 0 0
>> lan4: 0 0 0 0 1306680 13909 0 0
>> eth0: 3276924 5539 0 0 1106135 5084 0 0
>> eth0.101: 169338 1732 0 0 190256 750 0 0
>> eth0.102: 2959522 3274 0 0 587248 1094 0 0
>> lo: 39390 502 0 0 39390 502 0 0
>> br-wan: 2956822 3254 0 0 587248 1094 0 0
>>
>
> Please ignore above mib counters. I noticed that I see lot of RxFCSErrors
> and RxSymbolErrors for extswitch. The count for both counters always
> remain same.
Yes that is not exactly good, it means that the RGMII interface between
the internal and external switches is not properly configured.
>
> root@LEDE:/# ethtool -S extswitch
> NIC statistics:
> tx_packets: 212
> tx_bytes: 19179
> rx_packets: 0
> rx_bytes: 0
> TxOctets: 14403
> TxDropPkts: 0
> TxBroadcastPkts: 24
> TxMulticastPkts: 122
> TxUnicastPkts: 0
> TxCollisions: 0
> TxSingleCollision: 0
> TxMultipleCollision: 0
> TxDeferredTransmit: 0
> TxLateCollision: 0
> TxExcessiveCollision: 0
> TxPausePkts: 0
> RxOctets: 3593
> RxUndersizePkts: 0
> RxPausePkts: 0
> Pkts64Octets: 0
> Pkts65to127Octets: 36
> Pkts128to255Octets: 1
> Pkts256to511Octets: 0
> Pkts512to1023Octets: 0
> Pkts1024to1522Octets: 0
> RxOversizePkts: 0
> RxJabbers: 0
> RxAlignmentErrors: 0
> RxFCSErrors: 37
> RxGoodOctets: 0
> RxDropPkts: 0
> RxUnicastPkts: 0
> RxMulticastPkts: 0
> RxBroadcastPkts: 0
> RxSAChanges: 0
> RxFragments: 0
> RxJumboPkts: 0
> RxSymbolErrors: 37
> RxDiscarded: 0
> p08_TxOctets: 47537
> p08_TxDropPkts: 0
> p08_TxBroadcastPkts: 163
> p08_TxMulticastPkts: 319
> p08_TxUnicastPkts: 0
> p08_TxCollisions: 0
> p08_TxSingleCollision: 0
> p08_TxMultipleCollision: 0
> p08_TxDeferredTransmit: 0
> p08_TxLateCollision: 0
> p08_TxExcessiveCollision: 0
> p08_TxPausePkts: 0
> p08_RxOctets: 14403
> p08_RxUndersizePkts: 0
> p08_RxPausePkts: 0
> p08_Pkts64Octets: 25
> p08_Pkts65to127Octets: 102
> p08_Pkts128to255Octets: 17
> p08_Pkts256to511Octets: 2
> p08_Pkts512to1023Octets: 0
> p08_Pkts1024to1522Octets: 0
> p08_RxOversizePkts: 0
> p08_RxJabbers: 0
> p08_RxAlignmentErrors: 0
> p08_RxFCSErrors: 0
> p08_RxGoodOctets: 14403
> p08_RxDropPkts: 0
> p08_RxUnicastPkts: 0
> p08_RxMulticastPkts: 122
> p08_RxBroadcastPkts: 24
> p08_RxSAChanges: 40
> p08_RxFragments: 0
> p08_RxJumboPkts: 0
> p08_RxSymbolErrors: 0
> p08_RxDiscarded: 146
>
>
>>>
>>> - check the "extswitch" VLAN configuration on both the internal switch
>>> side (port 0) and on the external switch side ("cpu", port 8, not visible)
>>
>> #bridge vlan show
>> port vlan ids
>> extswitch None
>> extswitch
>> lan7 101 PVID Egress Untagged
>> lan7 101 PVID Egress Untagged
>> lan4 101 PVID Egress Untagged
>> lan4 101 PVID Egress Untagged
>> lan8 101 PVID Egress Untagged
>> lan8 101 PVID Egress Untagged
>> wan 102 PVID Egress Untagged
>> wan 102 PVID Egress Untagged
>> lan1 101 PVID Egress Untagged
>> lan1 101 PVID Egress Untagged
>> lan5 101 PVID Egress Untagged
>> lan5 101 PVID Egress Untagged
>> lan2 101 PVID Egress Untagged
>> lan2 101 PVID Egress Untagged
>> lan6 101 PVID Egress Untagged
>> lan6 101 PVID Egress Untagged
>> lan3 101 PVID Egress Untagged
>> lan3 101 PVID Egress Untagged
>> br-lan None
>> eth0.101 101 PVID Egress Untagged
>> eth0.101
>> br-wan None
>> eth0.102 102 PVID Egress Untagged
>> eth0.102
>>
>>>
>>> - see if you can get traffic end-to-end from eth0 all the way through
>>> one of the external switch port. If that's the case, that means that the
>>> configuration of internal switch port 0, internal switch CPU port, and
>>> external switch external port is working and operational
>>>
>>> [1]:
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e47112d9d6009bf6b7438cedc0270316d6b0370d
>>>
>>>> VLAN102 = wan eth0.102
>>>>
>>>> Reading configs from the factory firmware, I'm sure that sw0port0 and> sw1port8 are connected. Excerpt from the same:
>>>>
>>>> port_numbers=0 2 4 2 1 3 1 3
>>>> port_switch_id=1 1 1 0 1 1 0 0
>>>> port_names=port0 port1 port2 port3 port4 port5 port6 port7
>>>
>>> Is 0 the identifier for the external or internal switch? If 0 is
>>> internal switch identifier and 1 is the external switch identifier, your
>>> mapping looks correct to me with one exception below:
>>
>> 0 is internal here.
>>
>>>
>>>> cpu_port_number=5 7 8
>>>> cpu_port_switch_id=0 0 0
>>>> hidden_port_numbers=0 8
>>>> hidden_port_switch_id=0 1
>>>>
>>>> Below is my updated device tree.
>>>>
>>>> Thanks,
>>>>
>>>> Vivek
>>>>
>>>> &srab {
>>>> compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
>>>> status = "okay";
>>>> dsa,member = <0 0>;
>>>>
>>>> ports {
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> port@1 {
>>>> reg = <1>;
>>>> label = "lan7";
>>>> };
>>>>
>>>> port@2 {
>>>> reg = <2>;
>>>> label = "lan4";
>>>> };
>>>>
>>>> port@3 {
>>>> reg = <3>;
>>>> label = "lan8";
>>>> };
>>>>
>>>> port@4 {
>>>> reg = <4>;
>>>> label = "wan";
>>>> };
>>>>
>>>> port@5 {
>>>> reg = <5>;
>>>> ethernet = <&gmac0>;
>>>> label = "cpu";
>>>>
>>>> fixed-link {
>>>>
>>>> speed = <1000>;
>>>> full-duplex;
>>>> };
>>>> };
>>>
>>> I think this is meant to be port 8 here based on the hidden_port_number
>>> value. This actually matters for VLAN configuration because B53 is not
>>> (unfortunately, to be fixed) consistently using dst->cpu_port (whatever
>>> is configured in Device Tree) vs. dev->cpu_port (hardcoded to 8 for this
>>> class of switch).
>>
>> When I connect to port 8 I receive no packets on internal switch.
>
> I'm able to now use sw0port8 <-> eth2 (i.e use cpu port 8 to connect to gmac2).
> For this I had to modify net/dsa/b53/b53_common.c (see below). This is how
> it is setup in net/phy/b53/b53_common.c. Also need to set
> cpu_port = B53_CPU_PORT for 53012 sw instead of B53_CPU_PORT_25
I actually plan to remove the use cpu_port entirely, or actually only
use it as a "hint" of which CPU ports are capable of supporting Broadcom
tags. A better change for now would be not to use dev->cpu_port, but
instead use ds->dst->cpu_dp->index like what b53_br_join() does.
>
> @@ -357,9 +357,11 @@ static void b53_enable_vlan(struct b53_d
> b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL5, &vc5);
> }
>
> - mgmt &= ~SM_SW_FWD_MODE;
>
> if (enable) {
> +
> + mgmt |= SM_SW_FWD_MODE;
> +
Humm, that I don't really understand because this is turning on managed
mode which only influences how multicast addresses are processed, it
should not make a different for non-MC traffic AFAICT.
> vc0 |= VC0_VLAN_EN | VC0_VID_CHK_EN | VC0_VID_HASH_VID;
> vc1 |= VC1_RX_MCST_UNTAG_EN | VC1_RX_MCST_FWD_EN;
> vc4 &= ~VC4_ING_VID_CHECK_MASK;
>
>>
>>>
>>> PS: on that front, we will have to rework that when we bring multiple
>>> CPU port support in DSA/B53/bcm_sf2 and so for now what we could do is
>>> just check that the configured CPU port in Device Tree is a valid CPU
>>> port for that switch (typically 5, 7 or 8), and if not, just issue a
>>> warning.
>>>
>>>>
>>>> sw0port0: port@0 {
>>>> reg = <0>;
>>>> label = "extswitch";
>>>>
>>>> fixed-link {
>>>> speed = <1000>;
>>>> full-duplex;
>>>> };
>>>
>>> There might be some additional configuration needed here for this port,
>>> because by default, the port will most likely try to use its built-in
>>> PHY and maybe that's what they did, they wired the built-in PHY directly
>>> to the IMP port of the external switch.
>>
>> Do you know what that configuration might be?
>
> Given that I see RxFCSErrors and RxSymbolErrors errors wrt extswitch.
> configuration definitely needs tweaking. I tried setting the phy-mode to
> rgmii and rgmii-txid but no go.
Configuration may have to be tuned on both switches unfortunately
because both RGMII interfaces would have the ability to configure
delays. Do you have a way to dump what the original firmware settings
for the register that b53_adjust_link() modifies such that we can see
what was previous configured?
Thanks!
--
Florian
On Mon, Aug 14, 2017 at 12:37 PM, Florian Fainelli <[email protected]> wrote:
>>
>> Please ignore above mib counters. I noticed that I see lot of RxFCSErrors
>> and RxSymbolErrors for extswitch. The count for both counters always
>> remain same.
>
> Yes that is not exactly good, it means that the RGMII interface between
> the internal and external switches is not properly configured.
It appears that I do not need to set any phy-mode on internal sw's
port 0 or external sw's port 8. Also, you were right about internal port 0 to
be configured as tagged member of the vlan. It was indeed set to untagged!
LEDE lacks aw way to configure this. But I can do this via a post script.
After making above changes I was able to ping the router using physical port on
external switch. However, the ping dies out after few seconds. I'm try to figure
out the cause for this. Al least, I have some connectivity!
>
>>
>> root@LEDE:/# ethtool -S extswitch
>> NIC statistics:
>> tx_packets: 212
>> tx_bytes: 19179
>> rx_packets: 0
>> rx_bytes: 0
>> TxOctets: 14403
>> TxDropPkts: 0
>> TxBroadcastPkts: 24
>> TxMulticastPkts: 122
>> TxUnicastPkts: 0
>> TxCollisions: 0
>> TxSingleCollision: 0
>> TxMultipleCollision: 0
>> TxDeferredTransmit: 0
>> TxLateCollision: 0
>> TxExcessiveCollision: 0
>> TxPausePkts: 0
>> RxOctets: 3593
>> RxUndersizePkts: 0
>> RxPausePkts: 0
>> Pkts64Octets: 0
>> Pkts65to127Octets: 36
>> Pkts128to255Octets: 1
>> Pkts256to511Octets: 0
>> Pkts512to1023Octets: 0
>> Pkts1024to1522Octets: 0
>> RxOversizePkts: 0
>> RxJabbers: 0
>> RxAlignmentErrors: 0
>> RxFCSErrors: 37
>> RxGoodOctets: 0
>> RxDropPkts: 0
>> RxUnicastPkts: 0
>> RxMulticastPkts: 0
>> RxBroadcastPkts: 0
>> RxSAChanges: 0
>> RxFragments: 0
>> RxJumboPkts: 0
>> RxSymbolErrors: 37
>> RxDiscarded: 0
>> p08_TxOctets: 47537
>> p08_TxDropPkts: 0
>> p08_TxBroadcastPkts: 163
>> p08_TxMulticastPkts: 319
>> p08_TxUnicastPkts: 0
>> p08_TxCollisions: 0
>> p08_TxSingleCollision: 0
>> p08_TxMultipleCollision: 0
>> p08_TxDeferredTransmit: 0
>> p08_TxLateCollision: 0
>> p08_TxExcessiveCollision: 0
>> p08_TxPausePkts: 0
>> p08_RxOctets: 14403
>> p08_RxUndersizePkts: 0
>> p08_RxPausePkts: 0
>> p08_Pkts64Octets: 25
>> p08_Pkts65to127Octets: 102
>> p08_Pkts128to255Octets: 17
>> p08_Pkts256to511Octets: 2
>> p08_Pkts512to1023Octets: 0
>> p08_Pkts1024to1522Octets: 0
>> p08_RxOversizePkts: 0
>> p08_RxJabbers: 0
>> p08_RxAlignmentErrors: 0
>> p08_RxFCSErrors: 0
>> p08_RxGoodOctets: 14403
>> p08_RxDropPkts: 0
>> p08_RxUnicastPkts: 0
>> p08_RxMulticastPkts: 122
>> p08_RxBroadcastPkts: 24
>> p08_RxSAChanges: 40
>> p08_RxFragments: 0
>> p08_RxJumboPkts: 0
>> p08_RxSymbolErrors: 0
>> p08_RxDiscarded: 146
>>
>>
>>
>> I'm able to now use sw0port8 <-> eth2 (i.e use cpu port 8 to connect to gmac2).
>> For this I had to modify net/dsa/b53/b53_common.c (see below). This is how
>> it is setup in net/phy/b53/b53_common.c. Also need to set
>> cpu_port = B53_CPU_PORT for 53012 sw instead of B53_CPU_PORT_25
>
> I actually plan to remove the use cpu_port entirely, or actually only
> use it as a "hint" of which CPU ports are capable of supporting Broadcom
> tags. A better change for now would be not to use dev->cpu_port, but
> instead use ds->dst->cpu_dp->index like what b53_br_join() does.
This will be quite helpful as current implementation creates some confusion
when there are more than one cpu ports.
>
>>
>> @@ -357,9 +357,11 @@ static void b53_enable_vlan(struct b53_d
>> b53_read8(dev, B53_VLAN_PAGE, B53_VLAN_CTRL5, &vc5);
>> }
>>
>> - mgmt &= ~SM_SW_FWD_MODE;
>>
>> if (enable) {
>> +
>> + mgmt |= SM_SW_FWD_MODE;
>> +
>
> Humm, that I don't really understand because this is turning on managed
> mode which only influences how multicast addresses are processed, it
> should not make a different for non-MC traffic AFAICT.
I tried to remove setting of SM_SW_FWD_MODE but no go. Even GPL source
sets it for 53012. For now I'll leave it until I get back to it.
> Configuration may have to be tuned on both switches unfortunately
> because both RGMII interfaces would have the ability to configure
> delays. Do you have a way to dump what the original firmware settings
> for the register that b53_adjust_link() modifies such that we can see
> what was previous configured?
>
> Thanks!
> --
> Florian
Thanks for your time!!
Vivek
Hardware Info
-------------
Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
DDR3 RAM - 256 MB
Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
2.4GHz - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
5GHz x 2 - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
Ports - 8 Ports, 1 WAN Ports
Antennas - 8 Antennas
Serial Port - @J6 [GND,TX,RX] (VCC NC) 115200 8n1
Tested with OpenWrt built with DSA driver and Kernel v4.14
Note:
"make sure that port 0 of the internal switch is not accidentally
configured back to untagged since that would cause problem when
terminating the VLAN tag on the SW side." - Florian Fainelli [1]
This can be ensured by running following command in OpenWrt:
bridge vlan add vid 1 dev extsw pvid tagged
[1] https://www.spinics.net/lists/arm-kernel/msg590992.html
Signed-off-by: Vivek Unune <[email protected]>
---
Changes in v2:
- Properly define mdio mux, internal mdio, external mdio, mii bus
- Now we define usb3 phy as a mdio node connected to internal mdio,
thanks to work done by Rafał Miłecki on the bcm usb3 phy mdio driver
- Define external SW as a mdio-mii node connected to external mdio
---
arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 239 +++++++++++++++++++++++-
arch/arm/boot/dts/bcm47094.dtsi | 6 +-
arch/arm/boot/dts/bcm5301x.dtsi | 55 +++++-
3 files changed, 288 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
index b6750f7..5f53207 100644
--- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
+++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
@@ -7,7 +7,7 @@
/dts-v1/;
#include "bcm47094.dtsi"
-#include "bcm5301x-nand-cs0-bch8.dtsi"
+#include "bcm5301x-nand-cs0-bch1.dtsi"
/ {
compatible = "linksys,panamera", "brcm,bcm47094", "brcm,bcm4708";
@@ -32,5 +32,242 @@
linux,code = <KEY_WPS_BUTTON>;
gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
};
+
+ rfkill {
+ label = "WiFi";
+ linux,code = <KEY_RFKILL>;
+ gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
+ };
+
+ reset {
+ label = "Reset";
+ linux,code = <KEY_RESTART>;
+ gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wps {
+ label = "bcm53xx:white:wps";
+ gpios = <&chipcommon 22 GPIO_ACTIVE_LOW>;
+ };
+
+ usb2 {
+ label = "bcm53xx:green:usb2";
+ gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port2>, <&ehci_port2>;
+ linux,default-trigger = "usbport";
+ };
+
+ usb3 {
+ label = "bcm53xx:green:usb3";
+ gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&ohci_port1>, <&ehci_port1>,
+ <&xhci_port1>;
+ linux,default-trigger = "usbport";
+ };
+
+ power {
+ label = "bcm53xx:white:power";
+ gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi-disabled {
+ label = "bcm53xx:amber:wifi-disabled";
+ gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-enabled {
+ label = "bcm53xx:white:wifi-enabled";
+ gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar1 {
+ label = "bcm53xx:white:bluebar1";
+ gpios = <&chipcommon 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar2 {
+ label = "bcm53xx:white:bluebar2";
+ gpios = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar3 {
+ label = "bcm53xx:white:bluebar3";
+ gpios = <&chipcommon 15 GPIO_ACTIVE_LOW>;
+ };
+
+ bluebar4 {
+ label = "bcm53xx:white:bluebar4";
+ gpios = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar5 {
+ label = "bcm53xx:white:bluebar5";
+ gpios = <&chipcommon 19 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar6 {
+ label = "bcm53xx:white:bluebar6";
+ gpios = <&chipcommon 20 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar7 {
+ label = "bcm53xx:white:bluebar7";
+ gpios = <&chipcommon 21 GPIO_ACTIVE_HIGH>;
+ };
+
+ bluebar8 {
+ label = "bcm53xx:white:bluebar8";
+ gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+&usb2 {
+ vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
+};
+
+&usb3 {
+ vcc-gpio = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
+};
+
+&mdio_mii_mux {
+ status = "okay";
+};
+
+&mdio_ext {
+ status = "okay";
+};
+
+&srab {
+ compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
+ status = "okay";
+ dsa,member = <0 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+ label = "lan7";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan4";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan8";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "wan";
+ };
+
+ port@5 {
+ reg = <5>;
+ ethernet = <&gmac0>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@7 {
+ reg = <7>;
+ ethernet = <&gmac1>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ port@8 {
+ reg = <8>;
+ ethernet = <&gmac2>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+
+ sw0_p0: port@0 {
+ reg = <0>;
+ label = "extsw";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
};
};
+
+&mdio_mii {
+ status = "okay";
+
+ switch@0 {
+ compatible = "brcm,bcm53125";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
+ reset-names = "robo_reset";
+ reg = <0>;
+ dsa,member = <1 0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "lan1";
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan5";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+
+ port@3 {
+ reg = <3>;
+ label = "lan6";
+ };
+
+ port@4 {
+ reg = <4>;
+ label = "lan3";
+ };
+
+ sw1_p8: port@8 {
+ reg = <8>;
+ ethernet = <&sw0_p0>;
+ label = "cpu";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
+ };
+ };
+ };
+};
+
diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
index 4840a78..8f3ec57 100644
--- a/arch/arm/boot/dts/bcm47094.dtsi
+++ b/arch/arm/boot/dts/bcm47094.dtsi
@@ -6,10 +6,8 @@
#include "bcm4708.dtsi"
-/ {
- usb3_phy: usb3-phy {
- compatible = "brcm,ns-bx-usb3-phy";
- };
+&usb3_phy {
+ compatible = "brcm,ns-bx-usb3-phy";
};
&uart0 {
diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
index 9a076c4..9e4386a 100644
--- a/arch/arm/boot/dts/bcm5301x.dtsi
+++ b/arch/arm/boot/dts/bcm5301x.dtsi
@@ -154,13 +154,6 @@
clock-names = "phy-ref-clk";
};
- usb3_phy: usb3-phy {
- compatible = "brcm,ns-ax-usb3-phy";
- reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
- reg-names = "dmp", "ccb-mii";
- #phy-cells = <0>;
- };
-
axi@18000000 {
compatible = "brcm,bus-axi";
reg = <0x18000000 0x1000>;
@@ -359,7 +352,55 @@
reg = <0x18003000 0x8>;
#size-cells = <1>;
#address-cells = <0>;
+ };
+
+ mdio-bus-mux {
+ compatible = "mdio-mux-mmioreg";
+ mdio-parent-bus = <&mdio>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x18003000 0x4>;
+ mux-mask = <0x200>;
+
+ mdio_int: mdio@0 { /* BIT(9) = 0 => internal mdio */
+ reg = <0x0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usb3_phy: usb3-phy@10 {
+ compatible = "brcm,ns-ax-usb3-phy";
+ reg = <0x10>;
+ usb3-dmp-syscon = <&usb3_dmp>;
+ #phy-cells = <0>;
+ };
+ };
+
+ mdio_ext: mdio@200 { /* BIT(9) = 1 => external mdio */
+ reg = <0x200>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+ };
+
+ mdio_mii_mux: mdio-mii-mux {
+ compatible = "mdio-mux-mmioreg";
+ mdio-parent-bus = <&mdio_ext>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x1800c1c0 0x4>;
+ mux-mask = <0xc0>; /* BIT(6) = mdc, BIT(7) = mdio */
status = "disabled";
+
+ mdio_mii: mdio-mii@0 {
+ reg = <0x0>; /* Enable mii function */
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+ };
+
+ usb3_dmp: syscon@18105000 {
+ reg = <0x18105000 0x1000>;
};
i2c0: i2c@18009000 {
--
2.9.3
Hi Vivek,
On 03/02/2018 11:41 AM, Vivek Unune wrote:
> Hardware Info
> -------------
>
> Processor - Broadcom BCM4709C0KFEBG dual-core @ 1.4 GHz
> Switch - BCM53012 in BCM4709C0KFEBG & external BCM53125
> DDR3 RAM - 256 MB
> Flash - 128 MB (Toshiba TC58BVG0S3HTA00)
> 2.4GHz - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
> Power Amp - Skyworks SE2623L 2.4 GHz power amp (x4)
> 5GHz x 2 - BCM4366 4×4 2.4/5G single chip 802.11ac SoC
> Power Amp - PLX Technology PEX8603 3-lane, 3-port PCIe switch
> Ports - 8 Ports, 1 WAN Ports
> Antennas - 8 Antennas
> Serial Port - @J6 [GND,TX,RX] (VCC NC) 115200 8n1
>
> Tested with OpenWrt built with DSA driver and Kernel v4.14
>
> Note:
>
> "make sure that port 0 of the internal switch is not accidentally
> configured back to untagged since that would cause problem when
> terminating the VLAN tag on the SW side." - Florian Fainelli [1]
>
> This can be ensured by running following command in OpenWrt:
>
> bridge vlan add vid 1 dev extsw pvid tagged
>
> [1] https://www.spinics.net/lists/arm-kernel/msg590992.html
Glad you got it working finally! Out of curiosity, I am assuming you
have Broadcom tags enabled on the internal switch and disabled on the
external BCM53125 switch, is that correct?
Just a few nits below.
>
> Signed-off-by: Vivek Unune <[email protected]>
> ---
> Changes in v2:
> - Properly define mdio mux, internal mdio, external mdio, mii bus
> - Now we define usb3 phy as a mdio node connected to internal mdio,
> thanks to work done by Rafał Miłecki on the bcm usb3 phy mdio driver
> - Define external SW as a mdio-mii node connected to external mdio
> ---
> arch/arm/boot/dts/bcm47094-linksys-panamera.dts | 239 +++++++++++++++++++++++-
> arch/arm/boot/dts/bcm47094.dtsi | 6 +-
> arch/arm/boot/dts/bcm5301x.dtsi | 55 +++++-
> 3 files changed, 288 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
> index b6750f7..5f53207 100644
> --- a/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
> +++ b/arch/arm/boot/dts/bcm47094-linksys-panamera.dts
> @@ -7,7 +7,7 @@
> /dts-v1/;
>
> #include "bcm47094.dtsi"
> -#include "bcm5301x-nand-cs0-bch8.dtsi"
> +#include "bcm5301x-nand-cs0-bch1.dtsi"
This sounds like an independent bugfix, can you submit that separately?
>
> / {
> compatible = "linksys,panamera", "brcm,bcm47094", "brcm,bcm4708";
> @@ -32,5 +32,242 @@
> linux,code = <KEY_WPS_BUTTON>;
> gpios = <&chipcommon 3 GPIO_ACTIVE_LOW>;
> };
> +
> + rfkill {
> + label = "WiFi";
> + linux,code = <KEY_RFKILL>;
> + gpios = <&chipcommon 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + reset {
> + label = "Reset";
> + linux,code = <KEY_RESTART>;
> + gpios = <&chipcommon 17 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + wps {
> + label = "bcm53xx:white:wps";
> + gpios = <&chipcommon 22 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb2 {
> + label = "bcm53xx:green:usb2";
> + gpios = <&chipcommon 1 GPIO_ACTIVE_LOW>;
> + trigger-sources = <&ohci_port2>, <&ehci_port2>;
> + linux,default-trigger = "usbport";
> + };
> +
> + usb3 {
> + label = "bcm53xx:green:usb3";
> + gpios = <&chipcommon 2 GPIO_ACTIVE_LOW>;
> + trigger-sources = <&ohci_port1>, <&ehci_port1>,
> + <&xhci_port1>;
> + linux,default-trigger = "usbport";
> + };
> +
> + power {
> + label = "bcm53xx:white:power";
> + gpios = <&chipcommon 4 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wifi-disabled {
> + label = "bcm53xx:amber:wifi-disabled";
> + gpios = <&chipcommon 0 GPIO_ACTIVE_LOW>;
> + };
> +
> + wifi-enabled {
> + label = "bcm53xx:white:wifi-enabled";
> + gpios = <&chipcommon 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar1 {
> + label = "bcm53xx:white:bluebar1";
> + gpios = <&chipcommon 11 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar2 {
> + label = "bcm53xx:white:bluebar2";
> + gpios = <&chipcommon 12 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar3 {
> + label = "bcm53xx:white:bluebar3";
> + gpios = <&chipcommon 15 GPIO_ACTIVE_LOW>;
> + };
> +
> + bluebar4 {
> + label = "bcm53xx:white:bluebar4";
> + gpios = <&chipcommon 18 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar5 {
> + label = "bcm53xx:white:bluebar5";
> + gpios = <&chipcommon 19 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar6 {
> + label = "bcm53xx:white:bluebar6";
> + gpios = <&chipcommon 20 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar7 {
> + label = "bcm53xx:white:bluebar7";
> + gpios = <&chipcommon 21 GPIO_ACTIVE_HIGH>;
> + };
> +
> + bluebar8 {
> + label = "bcm53xx:white:bluebar8";
> + gpios = <&chipcommon 8 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +};
> +
> +&usb2 {
> + vcc-gpio = <&chipcommon 13 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&usb3 {
> + vcc-gpio = <&chipcommon 14 GPIO_ACTIVE_HIGH>;
> +};
> +
> +&mdio_mii_mux {
> + status = "okay";
> +};
> +
> +&mdio_ext {
> + status = "okay";
> +};
> +
> +&srab {
> + compatible = "brcm,bcm53012-srab", "brcm,bcm5301x-srab";
> + status = "okay";
> + dsa,member = <0 0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + reg = <1>;
> + label = "lan7";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan4";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan8";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "wan";
> + };
> +
> + port@5 {
> + reg = <5>;
> + ethernet = <&gmac0>;
> + label = "cpu";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> +
> + port@7 {
> + reg = <7>;
> + ethernet = <&gmac1>;
> + label = "cpu";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> +
> + port@8 {
> + reg = <8>;
> + ethernet = <&gmac2>;
> + label = "cpu";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
None of this is wrong, but DSA effectively will take the first port
specified with a "cpu" label and declare it as the one and only CPU port
it supports. If the architecture on Northstar is similar to what is done
on Northstar Plus, port 5 can be either internal or external PHY, port 7
is indeed gmac1, and port 8 is connected to the flow accelerator, which
should be in "bypass" mode by default. We can always change that later
on if we have to anyway.
> +
> + sw0_p0: port@0 {
switch0port0 would be a nicer label and unit name to use.
> + reg = <0>;
> + label = "extsw";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> };
> };
> +
> +&mdio_mii {
> + status = "okay";
> +
> + switch@0 {
> + compatible = "brcm,bcm53125";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + reset-gpios = <&chipcommon 10 GPIO_ACTIVE_LOW>;
> + reset-names = "robo_reset";
> + reg = <0>;
> + dsa,member = <1 0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + label = "lan1";
> + };
> +
> + port@1 {
> + reg = <1>;
> + label = "lan5";
> + };
> +
> + port@2 {
> + reg = <2>;
> + label = "lan2";
> + };
> +
> + port@3 {
> + reg = <3>;
> + label = "lan6";
> + };
> +
> + port@4 {
> + reg = <4>;
> + label = "lan3";
> + };
> +
> + sw1_p8: port@8 {
Similarly, this would be better with switch1port8?
> + reg = <8>;
> + ethernet = <&sw0_p0>;
> + label = "cpu";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> + };
> + };
> + };
> +};
> +
> diff --git a/arch/arm/boot/dts/bcm47094.dtsi b/arch/arm/boot/dts/bcm47094.dtsi
> index 4840a78..8f3ec57 100644
> --- a/arch/arm/boot/dts/bcm47094.dtsi
> +++ b/arch/arm/boot/dts/bcm47094.dtsi
> @@ -6,10 +6,8 @@
>
> #include "bcm4708.dtsi"
>
> -/ {
> - usb3_phy: usb3-phy {
> - compatible = "brcm,ns-bx-usb3-phy";
> - };
> +&usb3_phy {
> + compatible = "brcm,ns-bx-usb3-phy";
> };
I would probably create a separate commit which explains why yuo are
relocating the USB 3.0 PHY into the mdiomux node, and then only add
support for the EA9500 model.
>
> &uart0 {
> diff --git a/arch/arm/boot/dts/bcm5301x.dtsi b/arch/arm/boot/dts/bcm5301x.dtsi
> index 9a076c4..9e4386a 100644
> --- a/arch/arm/boot/dts/bcm5301x.dtsi
> +++ b/arch/arm/boot/dts/bcm5301x.dtsi
> @@ -154,13 +154,6 @@
> clock-names = "phy-ref-clk";
> };
>
> - usb3_phy: usb3-phy {
> - compatible = "brcm,ns-ax-usb3-phy";
> - reg = <0x18105000 0x1000>, <0x18003000 0x1000>;
> - reg-names = "dmp", "ccb-mii";
> - #phy-cells = <0>;
> - };
Same here.
--
Florian
Date: Fri, 9 Mar 2018 16:56:11 -0500
From: Vivek Unune <[email protected]>
To: Florian Fainelli <[email protected]>
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected],
[email protected], Jon Mason <[email protected]>
Subject: Re: [PATCH v2] ARM: dts: BCM5301X: Add support for Linksys EA9500
Message-ID: <20180309215611.ip7uvnpwfkfwfmx3@osboxes>
References: <[email protected]>
<[email protected]>
<[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[email protected]>
User-Agent: NeoMutt/20170113 (1.7.2)
Hi Florian,
On Fri, Mar 09, 2018 at 11:17:21AM -0800, Florian Fainelli wrote:
>
> Glad you got it working finally! Out of curiosity, I am assuming you
> have Broadcom tags enabled on the internal switch and disabled on the
> external BCM53125 switch, is that correct?
No, I did not enable tagging, as I thought this might have undesired effect
with internal switch enabled and external disabled. I understand that
BCM53125 needs additional plumbing and it's tagging is disabled in mainline.
> >
> > #include "bcm47094.dtsi"
> > -#include "bcm5301x-nand-cs0-bch8.dtsi"
> > +#include "bcm5301x-nand-cs0-bch1.dtsi"
>
> This sounds like an independent bugfix, can you submit that separately?
Will do.
> > +
> > + port@5 {
> > + reg = <5>;
> > + ethernet = <&gmac0>;
> > + label = "cpu";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
> > +
> > + port@7 {
> > + reg = <7>;
> > + ethernet = <&gmac1>;
> > + label = "cpu";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
> > +
> > + port@8 {
> > + reg = <8>;
> > + ethernet = <&gmac2>;
> > + label = "cpu";
> > +
> > + fixed-link {
> > + speed = <1000>;
> > + full-duplex;
> > + };
> > + };
>
> None of this is wrong, but DSA effectively will take the first port
> specified with a "cpu" label and declare it as the one and only CPU port
> it supports. If the architecture on Northstar is similar to what is done
> on Northstar Plus, port 5 can be either internal or external PHY, port 7
> is indeed gmac1, and port 8 is connected to the flow accelerator, which
> should be in "bypass" mode by default. We can always change that later
> on if we have to anyway.
From what I understand from the source is that gmac0 and gmac1 in NorthStar
are connected to FA while gmac2 is connected to port8
Although I could be completely wrong :)
Snippet from GPL source [1]:
* A typical GMAC configuration is:
* GMAC#0 - port#5 - fwd0 <---> wl0 (radio 0) on CPU core0
* GMAC#1 - port#7 - fwd1 <---> wl1 (radio 1) on CPU core1
*
* GMAC#2 - port#8 - eth0 <--- vlan1 ---> br0
Note: EA9500 has three radios, fwd0 is connected to even numbered radios
While odd numbered radios are connected to fwd1. Also, fw0,fw1 and eth0
listed above are devices created by the factory firmware.
> > +
> > + sw0_p0: port@0 {
>
> switch0port0 would be a nicer label and unit name to use.
>
>
> Similarly, this would be better with switch1port8?
Will do.
> >
> > -/ {
> > - usb3_phy: usb3-phy {
> > - compatible = "brcm,ns-bx-usb3-phy";
> > - };
> > +&usb3_phy {
> > + compatible = "brcm,ns-bx-usb3-phy";
> > };
>
> I would probably create a separate commit which explains why yuo are
> relocating the USB 3.0 PHY into the mdiomux node, and then only add
> support for the EA9500 model.
>
Will do.
Thanks,
Vivek
[1] https://github.com/RMerl/asuswrt-merlin/blob/master/release/src-rt-7.x.main/src/include/hndfwd.h
Hi Florian,
On Fri, Mar 9, 2018 at 5:05 PM, Vivek Unune <[email protected]> wrote:
>> > +
>> > + port@5 {
>> > + reg = <5>;
>> > + ethernet = <&gmac0>;
>> > + label = "cpu";
>> > +
>> > + fixed-link {
>> > + speed = <1000>;
>> > + full-duplex;
>> > + };
>> > + };
>> > +
>> > + port@7 {
>> > + reg = <7>;
>> > + ethernet = <&gmac1>;
>> > + label = "cpu";
>> > +
>> > + fixed-link {
>> > + speed = <1000>;
>> > + full-duplex;
>> > + };
>> > + };
>> > +
>> > + port@8 {
>> > + reg = <8>;
>> > + ethernet = <&gmac2>;
>> > + label = "cpu";
>> > +
>> > + fixed-link {
>> > + speed = <1000>;
>> > + full-duplex;
>> > + };
>> > + };
>>
>> None of this is wrong, but DSA effectively will take the first port
>> specified with a "cpu" label and declare it as the one and only CPU port
>> it supports. If the architecture on Northstar is similar to what is done
>> on Northstar Plus, port 5 can be either internal or external PHY, port 7
>> is indeed gmac1, and port 8 is connected to the flow accelerator, which
>> should be in "bypass" mode by default. We can always change that later
>> on if we have to anyway.
>
> From what I understand from the source is that gmac0 and gmac1 in NorthStar
> are connected to FA while gmac2 is connected to port8
> Although I could be completely wrong :)
>
> Snippet from GPL source [1]:
>
> * A typical GMAC configuration is:
> * GMAC#0 - port#5 - fwd0 <---> wl0 (radio 0) on CPU core0
> * GMAC#1 - port#7 - fwd1 <---> wl1 (radio 1) on CPU core1
> *
> * GMAC#2 - port#8 - eth0 <--- vlan1 ---> br0
>
> Note: EA9500 has three radios, fwd0 is connected to even numbered radios
> While odd numbered radios are connected to fwd1. Also, fw0,fw1 and eth0
> listed above are devices created by the factory firmware.
Correction: Port 5 and port 7 act as forwarders and are not connected to
flow accelerator. And you are right, port 8 is connected to flow accelerator.
Although, it seems it is not enabled in Linksys factory firmware.
Some more excerpt from GPL source:
* Northstar router includes 3 GMAC ports from the integrated switch to the Host
* (single or dual core) CPU. The integrated switch provides advanced ethernet
* hardware switching functions, similar to that of a Linux software bridge.
* In Northstar, this integrated HW switch is responsible for bridging packets
* between the 4 LAN ports. All LAN ports are seen by the ethernet network
* device driver as a single "vlan1" interface. This single vlan1 interface
* represents the collection of physical LAN ports on the switch, without
* having to create a seperate interface per LAN port and adding each one of
* these LAN interfaces to the default Linux software LAN bridge "br0".
* The hardware switch allows the LAN ports to be segregated into multiple
* bridges using VLAN (Independent VLAN Learning Mode). Again, each subset of
* physical LAN ports are represented by a single interface, namely "vlanX".
*
* The 3 GMAC configuration treats the primary WLAN interface as just another
* LAN interface (albeit with a WLAN 802.11 MAC as opposed to an Ethernet 802.3
* MAC). Two of the three GMACs are dedicated for binding the primary WLAN
* interfaces to the HW switch which performs the LAN to WLAN bridging function.
* These two GMACs are referred to as Forwarding GMACs.
* The third GMAC is used to connect the switch to the Linux router network
* stack, by making all LAN and WLAN ports appear as a single vlan1 interface
* that is added to the software Linux bridge "br0". This GMAC is referred to
* as the Networking GMAC.
*
* Similar to LAN to WAN routing, where LAN originated packets would be flooded
* to the WAN port via the br0, likewise, WLAN originated packets would re-enter
* Linux network stack via the 3rd GMAC. Software Cut-Through-Forwarding CTF
* will accelerate WLAN <-> WAN traffic. When the hardware Flow Accelerator is
* enabled, WLAN <-> WAN traffic need not re-enter the host CPU, other than the
* first few packets that are needed to establish the flows in the FA, post
* DPI or Security related flow classification functions.