Patchwork Marvell 88E609x switch?

login
register
mail settings
Submitter Jesper Dangaard Brouer
Date March 2, 2009, 10:56 a.m.
Message ID <1235991382.30736.62.camel@localhost.localdomain>
Download mbox | patch
Permalink /patch/23931/
State RFC
Delegated to: David Miller
Headers show

Comments

Jesper Dangaard Brouer - March 2, 2009, 10:56 a.m.
On Fri, 2009-02-27 at 23:28 +0100, Lennert Buytenhek wrote:

> The main conclusion so far is that this write (net/dsa/mv88e6131.c):
> 
> 	/*
> 	 * MAC Forcing register: don't force link, speed, duplex
> 	 * or flow control state to any particular values.
> 	 */
>	REG_WRITE(addr, 0x01, 0x0003);

This sort of enables auto-detection of speed.

> isn't correct on ports that can either be CPU ports or external ports.

For external ports I had to enabled the PPU to allow the external PHYs
to negotiate.

Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to
register 0x1, PCS Control Register).  Which also enables inband
auto-negotiation, but I'm not sure this is necessary.


> Forcing the link up on the CPU port helps somewhat, but things aren't
> 100% working yet.

On the CPU port I force link-up and force speed+duplex setting.  I only
got 100Mbit/s to the CPU port...

/* CPU Port 10: Force 100Mbit Full-Duplex */
REG_WRITE( 0x1A , 0x01 , 0x003D );

You should write 0x003E ... see attached patch
Jesper Dangaard Brouer - March 2, 2009, 11:05 a.m.
On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:

> You should write 0x003E ... see attached patch

Ups, I see (from the thread) that you have already done/tried this...
Gary Thomas - March 2, 2009, 3:14 p.m.
Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
> 
>> You should write 0x003E ... see attached patch
> 
> Ups, I see (from the thread) that you have already done/tried this...
> 

Yes, although I think it will need some work in the future
(I've set it to 1000Mb connection, you said you used 100Mb, etc)

Question: I'm testing this by trying a ping out of my box.
Linux replies by sending an ARP packet out, and the destination
replies with an ARP packet in.  I can see from the ethtool stats
that the reply packets get into lan1.1 (the physical port I'm
using), but I don't see them get moved through the CPU port.
My understanding is that this should work via the VLAN map?
I checked that setup and it looks OK.

Any ideas where this might be going wrong?

Thanks
Gary Thomas - March 2, 2009, 3:22 p.m.
Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>
>>> You should write 0x003E ... see attached patch
>> Ups, I see (from the thread) that you have already done/tried this...
>>
> 
> Yes, although I think it will need some work in the future
> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
> 
> Question: I'm testing this by trying a ping out of my box.
> Linux replies by sending an ARP packet out, and the destination
> replies with an ARP packet in.  I can see from the ethtool stats
> that the reply packets get into lan1.1 (the physical port I'm
> using), but I don't see them get moved through the CPU port.
> My understanding is that this should work via the VLAN map?
> I checked that setup and it looks OK.
> 
> Any ideas where this might be going wrong?

I also just noticed that the ESA registers (Global 1,2,3)
aren't set at all.  I'm pretty sure that the way I'm using
the switch in my bootloader this doesn't matter as all packets
have a fixed routing and the ESA recognition happens at the
actual ethernet device.

Is this going to cause problems with the VLAN (+DSA) based
routing?
Jesper Dangaard Brouer - March 2, 2009, 10:05 p.m.
On Mon, 2 Mar 2009, Gary Thomas wrote:

> Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>>
>>>> You should write 0x003E ... see attached patch
>>> Ups, I see (from the thread) that you have already done/tried this...
>>>
>>
>> Yes, although I think it will need some work in the future
>> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
>>
>> Question: I'm testing this by trying a ping out of my box.
>> Linux replies by sending an ARP packet out, and the destination
>> replies with an ARP packet in.  I can see from the ethtool stats
>> that the reply packets get into lan1.1 (the physical port I'm
>> using), but I don't see them get moved through the CPU port.

Well, thats a break through :-) If I understand you correctly, the 
destination host actually receives the ARP packet and responds with a 
packet.

That should means that the outgoing DSA tagging is working.  Although I'm 
not sure about the incomming...

>> My understanding is that this should work via the VLAN map?

I think that the "VLAN map/table" has gotten a wrong name as it does not 
really determine the VLANs, it only says who can talk to whom.  The switch 
does support a real vlan setup, but its deactivated in Lennerts driver, as 
I guess he wants Linux to handle the VLANs.  (I use the real VLAN setup 
extensively in my driver).

>> I checked that setup and it looks OK.

I have also checked the different registers setting, and things looks 
quite alright.  Although I'm missing the register datasheets for the 6131 
chip, I found that I only have part 1 of 3 crap...

I did find that the 6095 and 6097 does differ in the way DSA handling is 
done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131 
driver looks like it does the right thing for the 6095.


>> Any ideas where this might be going wrong?

Is lan1.1 up and have you given it an IP address?
(could I get a 'ifconfig' output?)

Are you sending packets with VLAN tags?


> I also just noticed that the ESA registers (Global 1,2,3)
> aren't set at all.  I'm pretty sure that the way I'm using
> the switch in my bootloader this doesn't matter as all packets
> have a fixed routing and the ESA recognition happens at the
> actual ethernet device.

Don't think the switch needs a MAC address...

> Is this going to cause problems with the VLAN (+DSA) based
> routing?

Don't think so...

Hilsen
   Jesper Brouer

--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gary Thomas - March 2, 2009, 10:32 p.m.
Jesper Dangaard Brouer wrote:
> 
> 
> 
> On Mon, 2 Mar 2009, Gary Thomas wrote:
> 
>> Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Mon, 2009-03-02 at 11:56 +0100, Jesper Dangaard Brouer wrote:
>>>>
>>>>> You should write 0x003E ... see attached patch
>>>> Ups, I see (from the thread) that you have already done/tried this...
>>>>
>>>
>>> Yes, although I think it will need some work in the future
>>> (I've set it to 1000Mb connection, you said you used 100Mb, etc)
>>>
>>> Question: I'm testing this by trying a ping out of my box.
>>> Linux replies by sending an ARP packet out, and the destination
>>> replies with an ARP packet in.  I can see from the ethtool stats
>>> that the reply packets get into lan1.1 (the physical port I'm
>>> using), but I don't see them get moved through the CPU port.
> 
> Well, thats a break through :-) If I understand you correctly, the
> destination host actually receives the ARP packet and responds with a
> packet.
> 
> That should means that the outgoing DSA tagging is working.  Although
> I'm not sure about the incomming...
> 
>>> My understanding is that this should work via the VLAN map?
> 
> I think that the "VLAN map/table" has gotten a wrong name as it does not
> really determine the VLANs, it only says who can talk to whom.  The
> switch does support a real vlan setup, but its deactivated in Lennerts
> driver, as I guess he wants Linux to handle the VLANs.  (I use the real
> VLAN setup extensively in my driver).

I agree that the simple mode Lennert's code uses is not VLAN on
the hardware, just internal switch path routes.

>>> I checked that setup and it looks OK.
> 
> I have also checked the different registers setting, and things looks
> quite alright.  Although I'm missing the register datasheets for the
> 6131 chip, I found that I only have part 1 of 3 crap...
> 
> I did find that the 6095 and 6097 does differ in the way DSA handling is
> done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131
> driver looks like it does the right thing for the 6095.

I didn't look at the 6097 yet, but I have scoured the 6095 and 6131
data sheets and I can't see what's wrong.  The differences between
these two parts are extremely minor - basically the number of ports
and which one might be used for the CPU.

> 
>>> Any ideas where this might be going wrong?
> 
> Is lan1.1 up and have you given it an IP address?
> (could I get a 'ifconfig' output?)

Yes it's up.

> Are you sending packets with VLAN tags?

No VLAN tagging (by Linux), just normal IPv4 packets. Here's what I did:

root@ppc_target:~ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1180 (1.1 KiB)
          Base address:0x6000

root@ppc_target:~ ifconfig lan1.1 192.168.12.188 up
root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled

root@ppc_target:~ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1180 (1.1 KiB)
          Base address:0x6000

lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.188  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@ppc_target:~ ethtool -S lan1.1
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 2096784
     in_bad_octets: 0
     in_unicast: 3601
     in_broadcasts: 528
     in_multicasts: 70
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 230866
     out_unicast: 3595
     out_broadcasts: 3
     out_multicasts: 0
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3705
     hist_65_127bytes: 326
     hist_128_255bytes: 159
     hist_256_511bytes: 15
     hist_512_1023bytes: 3592
     hist_1024_max_bytes: 0
root@ppc_target:~ ethtool -S lan1.8
mv88e6131_get_ethtool_stats(7) => CPU
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 232054
     in_bad_octets: 0
     in_unicast: 3595
     in_broadcasts: 5
     in_multicasts: 0
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 2021576
     out_unicast: 3599
     out_broadcasts: 9
     out_multicasts: 1
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3600
     hist_65_127bytes: 9
     hist_128_255bytes: 0
     hist_256_511bytes: 4
     hist_512_1023bytes: 3596
     hist_1024_max_bytes: 0
root@ppc_target:~ ping -c 5 192.168.12.18
PING 192.168.12.18 (192.168.12.18): 56 data bytes

--- 192.168.12.18 ping statistics ---
5 packets transmitted, 0 packets received, 100% packet loss
root@ppc_target:~ ifconfig lan1.1
lan1.1    Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          inet addr:192.168.12.188  Bcast:192.168.12.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:252 (252.0 B)

root@ppc_target:~ ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:1D:11:81:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1180 (1.1 KiB)  TX bytes:1456 (1.4 KiB)
          Base address:0x6000

root@ppc_target:~ ethtool -S lan1.1
NIC statistics:
     tx_packets: 6
     tx_bytes: 252
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 2099816
     in_bad_octets: 0
     in_unicast: 3607
     in_broadcasts: 542
     in_multicasts: 71
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 231250
     out_unicast: 3595
     out_broadcasts: 9
     out_multicasts: 0
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3718
     hist_65_127bytes: 331
     hist_128_255bytes: 168
     hist_256_511bytes: 15
     hist_512_1023bytes: 3592
     hist_1024_max_bytes: 0
root@ppc_target:~ ethtool -S lan1.8
mv88e6131_get_ethtool_stats(7) => CPU
NIC statistics:
     tx_packets: 0
     tx_bytes: 0
     rx_packets: 0
     rx_bytes: 0
     in_good_octets: 232438
     in_bad_octets: 0
     in_unicast: 3595
     in_broadcasts: 11
     in_multicasts: 0
     in_pause: 0
     in_undersize: 0
     in_fragments: 0
     in_oversize: 0
     in_jabber: 0
     in_rx_error: 0
     in_fcs_error: 0
     out_octets: 2021576
     out_unicast: 3599
     out_broadcasts: 9
     out_multicasts: 1
     out_pause: 0
     excessive: 0
     collisions: 0
     deferred: 0
     single: 0
     multiple: 0
     out_fcs_error: 0
     late: 0
     hist_64bytes: 3606
     hist_65_127bytes: 9
     hist_128_255bytes: 0
     hist_256_511bytes: 4
     hist_512_1023bytes: 3596
     hist_1024_max_bytes: 0

You can see that lan1.1 "in_unicast" changed by 6 packets.  These
correspond to the ARP reply packets I see the destination host
(192.168.12.18) send out.

> 
>> I also just noticed that the ESA registers (Global 1,2,3)
>> aren't set at all.  I'm pretty sure that the way I'm using
>> the switch in my bootloader this doesn't matter as all packets
>> have a fixed routing and the ESA recognition happens at the
>> actual ethernet device.
> 
> Don't think the switch needs a MAC address...
> 
>> Is this going to cause problems with the VLAN (+DSA) based
>> routing?
> 
> Don't think so...

I added in the correct ESA on the switch and the lan1.1
incoming counters now track the unicode packets.  Since I
still can't get them through to the CPU port, I don't
know if this was important.

Any ideas how I might troubleshoot why packets that come
into lan1.1 (port 0) aren't being pushed to the CPU port?
Jesper Dangaard Brouer - March 3, 2009, 8:52 a.m.
On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> Any ideas how I might troubleshoot why packets that come
> into lan1.1 (port 0) aren't being pushed to the CPU port?

The switch supports port monitoring, with seperate ingress and egress
mapping, thus you could place another PC on another port and direct
traffic towards that, and by tcpdump inspecting ingress and egress on
the different physical ports... Thats how I debugged it once...

I also used/implemented the VLAN violation interrupt, while I debugged
the VLAN setup.   The switch also have a ATU (MAC-table) violation
interrupt, perhaps that might tell you something?
Jesper Dangaard Brouer - March 3, 2009, 9:04 a.m.
On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> > Any ideas how I might troubleshoot why packets that come
> > into lan1.1 (port 0) aren't being pushed to the CPU port?
> 
> The switch supports port monitoring, with seperate ingress and egress
> mapping, thus you could place another PC on another port and direct
> traffic towards that, and by tcpdump inspecting ingress and egress on
> the different physical ports... Thats how I debugged it once...
> 
> I also used/implemented the VLAN violation interrupt, while I debugged
> the VLAN setup.   The switch also have a ATU (MAC-table) violation
> interrupt, perhaps that might tell you something?

Another thing... An IXP425 specific change I had to make, was to disable
NPE_learning for the ixp400_eth driver.

 insmod ixp400_eth npe_learning=0

MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning &
Filtering feature will be enabled");

Perhaps the GIANFAR driver also has this kind of MAC address filtering?
Gary Thomas - March 3, 2009, 12:02 p.m.
Jesper Dangaard Brouer wrote:
> On Tue, 2009-03-03 at 09:52 +0100, Jesper Dangaard Brouer wrote:
>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>> Any ideas how I might troubleshoot why packets that come
>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>> The switch supports port monitoring, with seperate ingress and egress
>> mapping, thus you could place another PC on another port and direct
>> traffic towards that, and by tcpdump inspecting ingress and egress on
>> the different physical ports... Thats how I debugged it once...
>>
>> I also used/implemented the VLAN violation interrupt, while I debugged
>> the VLAN setup.   The switch also have a ATU (MAC-table) violation
>> interrupt, perhaps that might tell you something?
> 
> Another thing... An IXP425 specific change I had to make, was to disable
> NPE_learning for the ixp400_eth driver.
> 
>  insmod ixp400_eth npe_learning=0
> 
> MODULE_PARM_DESC(npe_learning, "If non-zero, NPE MAC Address Learning &
> Filtering feature will be enabled");
> 
> Perhaps the GIANFAR driver also has this kind of MAC address filtering?
> 

I don't think this is a problem; no packets are getting
[back] to the gianfar interface (based on RX interrupt counts)
Gary Thomas - March 3, 2009, 12:03 p.m.
Jesper Dangaard Brouer wrote:
> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>> Any ideas how I might troubleshoot why packets that come
>> into lan1.1 (port 0) aren't being pushed to the CPU port?
> 
> The switch supports port monitoring, with seperate ingress and egress
> mapping, thus you could place another PC on another port and direct
> traffic towards that, and by tcpdump inspecting ingress and egress on
> the different physical ports... Thats how I debugged it once...

I'm a bit fuzzy on this - could you explain in a bit more detail?

> I also used/implemented the VLAN violation interrupt, while I debugged
> the VLAN setup.   The switch also have a ATU (MAC-table) violation
> interrupt, perhaps that might tell you something?
> 

Thanks
Jesper Dangaard Brouer - March 3, 2009, 12:32 p.m.
On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
> > On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
> >> Any ideas how I might troubleshoot why packets that come
> >> into lan1.1 (port 0) aren't being pushed to the CPU port?
> > 
> > The switch supports port monitoring, with seperate ingress and egress
> > mapping, thus you could place another PC on another port and direct
> > traffic towards that, and by tcpdump inspecting ingress and egress on
> > the different physical ports... Thats how I debugged it once...
> 
> I'm a bit fuzzy on this - could you explain in a bit more detail?

You basically set the monitor destination port via REG_GLOBAL reg 0x1A
"Monitor Control".

/* Register: Monitor Control (0x1A)
   -------------------------
    bit 15:12= Ingress Monitor Dest
    bit 11:8 = Egress  Monitor Dest
    bit  7:4 = ARP Dest
    bit  3:0 = Reserved
*/

Then you configure the port register 0x08 "port control2", that this
port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.

/* Register: Port Control 2 (0x8)
   ------------------------
    bit 15    = IgnoreFSC: Force good FSC in frame
    bit 14    = VTU_prio_override   : VTU    setting overrides prio
    bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
    bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
    bit 11:10 = 802.1Q mode
     [00] = <Disabled>: use VLANtable only
     [01] = <Fallback>: fallback to VLANTable
     [10] = <Check>   : drop on miss (eq. not in VTU)
     [11] = <Secure>  : drop on miss and membership violation
    bit 9     = Discard Tagged
    bit 8     = Discard Untagged
    bit 7     = MapDA: Map using DA hits
    bit 6     = Default Forward (normal switch operation)
    bit 5     = Monitor egress
    bit 4     = Monitor ingress
    bit 3:0   = CPU port
*/


Reading through the "Monitor Control" register description, there is a
interesting description about the "ARPdest" setting... Could you try to
set it to the CPU port and see if that helps?
Gary Thomas - March 3, 2009, 1:25 p.m.
Jesper Dangaard Brouer wrote:
> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>> Any ideas how I might troubleshoot why packets that come
>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>> The switch supports port monitoring, with seperate ingress and egress
>>> mapping, thus you could place another PC on another port and direct
>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>> the different physical ports... Thats how I debugged it once...
>> I'm a bit fuzzy on this - could you explain in a bit more detail?
> 
> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
> "Monitor Control".
> 
> /* Register: Monitor Control (0x1A)
>    -------------------------
>     bit 15:12= Ingress Monitor Dest
>     bit 11:8 = Egress  Monitor Dest
>     bit  7:4 = ARP Dest
>     bit  3:0 = Reserved
> */
> 
> Then you configure the port register 0x08 "port control2", that this
> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
> 
> /* Register: Port Control 2 (0x8)
>    ------------------------
>     bit 15    = IgnoreFSC: Force good FSC in frame
>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>     bit 11:10 = 802.1Q mode
>      [00] = <Disabled>: use VLANtable only
>      [01] = <Fallback>: fallback to VLANTable
>      [10] = <Check>   : drop on miss (eq. not in VTU)
>      [11] = <Secure>  : drop on miss and membership violation
>     bit 9     = Discard Tagged
>     bit 8     = Discard Untagged
>     bit 7     = MapDA: Map using DA hits
>     bit 6     = Default Forward (normal switch operation)
>     bit 5     = Monitor egress
>     bit 4     = Monitor ingress
>     bit 3:0   = CPU port
> */
> 
> 
> Reading through the "Monitor Control" register description, there is a
> interesting description about the "ARPdest" setting... Could you try to
> set it to the CPU port and see if that helps?
> 

It's already set this way (sans bits 4&5)
	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);

I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
coming into that port, but it doesn't look right:

Here's the ARP going out:

13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
        0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
        0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
        0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12

Here's the ARP reply coming back:

13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
        0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
        0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
        0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
        0x0030:  0000 0000 0000 0000 0000 0000 0000 0000

I understand the 0x4000 DSA tag going out, but what's the 0x8004?
Gary Thomas - March 3, 2009, 1:30 p.m.
Gary Thomas wrote:
> Jesper Dangaard Brouer wrote:
>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>> Jesper Dangaard Brouer wrote:
>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>> Any ideas how I might troubleshoot why packets that come
>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>> The switch supports port monitoring, with seperate ingress and egress
>>>> mapping, thus you could place another PC on another port and direct
>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>> the different physical ports... Thats how I debugged it once...
>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>> "Monitor Control".
>>
>> /* Register: Monitor Control (0x1A)
>>    -------------------------
>>     bit 15:12= Ingress Monitor Dest
>>     bit 11:8 = Egress  Monitor Dest
>>     bit  7:4 = ARP Dest
>>     bit  3:0 = Reserved
>> */
>>
>> Then you configure the port register 0x08 "port control2", that this
>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>
>> /* Register: Port Control 2 (0x8)
>>    ------------------------
>>     bit 15    = IgnoreFSC: Force good FSC in frame
>>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>>     bit 11:10 = 802.1Q mode
>>      [00] = <Disabled>: use VLANtable only
>>      [01] = <Fallback>: fallback to VLANTable
>>      [10] = <Check>   : drop on miss (eq. not in VTU)
>>      [11] = <Secure>  : drop on miss and membership violation
>>     bit 9     = Discard Tagged
>>     bit 8     = Discard Untagged
>>     bit 7     = MapDA: Map using DA hits
>>     bit 6     = Default Forward (normal switch operation)
>>     bit 5     = Monitor egress
>>     bit 4     = Monitor ingress
>>     bit 3:0   = CPU port
>> */
>>
>>
>> Reading through the "Monitor Control" register description, there is a
>> interesting description about the "ARPdest" setting... Could you try to
>> set it to the CPU port and see if that helps?
>>
> 
> It's already set this way (sans bits 4&5)
> 	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
> 
> I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
> coming into that port, but it doesn't look right:
> 
> Here's the ARP going out:
> 
> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
>         0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
>         0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
>         0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12
> 
> Here's the ARP reply coming back:
> 
> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
>         0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
>         0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
>         0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
>         0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
> 
> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
> 

Note: without the extra monitor bit (#4), I don't see these packets
get back to my ethernet device.  Maybe the tag says something of why?

Any pointers on how I can test/debug the "VLAN" (internal routing) setup?
Gary Thomas - March 3, 2009, 9:52 p.m.
Gary Thomas wrote:
> Gary Thomas wrote:
>> Jesper Dangaard Brouer wrote:
>>> On Tue, 2009-03-03 at 05:03 -0700, Gary Thomas wrote:
>>>> Jesper Dangaard Brouer wrote:
>>>>> On Mon, 2009-03-02 at 15:32 -0700, Gary Thomas wrote:
>>>>>> Any ideas how I might troubleshoot why packets that come
>>>>>> into lan1.1 (port 0) aren't being pushed to the CPU port?
>>>>> The switch supports port monitoring, with seperate ingress and egress
>>>>> mapping, thus you could place another PC on another port and direct
>>>>> traffic towards that, and by tcpdump inspecting ingress and egress on
>>>>> the different physical ports... Thats how I debugged it once...
>>>> I'm a bit fuzzy on this - could you explain in a bit more detail?
>>> You basically set the monitor destination port via REG_GLOBAL reg 0x1A
>>> "Monitor Control".
>>>
>>> /* Register: Monitor Control (0x1A)
>>>    -------------------------
>>>     bit 15:12= Ingress Monitor Dest
>>>     bit 11:8 = Egress  Monitor Dest
>>>     bit  7:4 = ARP Dest
>>>     bit  3:0 = Reserved
>>> */
>>>
>>> Then you configure the port register 0x08 "port control2", that this
>>> port is to be monitored: bit5=monitor_egress and bit4=monitor_ingress.
>>>
>>> /* Register: Port Control 2 (0x8)
>>>    ------------------------
>>>     bit 15    = IgnoreFSC: Force good FSC in frame
>>>     bit 14    = VTU_prio_override   : VTU    setting overrides prio
>>>     bit 13    = ATU_SA_prio_overrite: ATU SA setting overrides prio
>>>     bit 12    = ATU_DA_prio_overrite: ATU DA setting overrides prio
>>>     bit 11:10 = 802.1Q mode
>>>      [00] = <Disabled>: use VLANtable only
>>>      [01] = <Fallback>: fallback to VLANTable
>>>      [10] = <Check>   : drop on miss (eq. not in VTU)
>>>      [11] = <Secure>  : drop on miss and membership violation
>>>     bit 9     = Discard Tagged
>>>     bit 8     = Discard Untagged
>>>     bit 7     = MapDA: Map using DA hits
>>>     bit 6     = Default Forward (normal switch operation)
>>>     bit 5     = Monitor egress
>>>     bit 4     = Monitor ingress
>>>     bit 3:0   = CPU port
>>> */
>>>
>>>
>>> Reading through the "Monitor Control" register description, there is a
>>> interesting description about the "ARPdest" setting... Could you try to
>>> set it to the CPU port and see if that helps?
>>>
>> It's already set this way (sans bits 4&5)
>> 	REG_WRITE(REG_GLOBAL, 0x1a, (ds->cpu_port * 0x1100) | 0x00f0);
>>
>> I tried turning on bit 4 on port 0 (lan1.1).  Now I can see what's
>> coming into that port, but it doesn't look right:
>>
>> Here's the ARP going out:
>>
>> 13:46:29.348449 00:1d:11:81:00:00 > ff:ff:ff:ff:ff:ff, ethertype Unknown (0x4000), length 46:
>>         0x0000:  ffff ffff ffff 001d 1181 0000 4000 0000
>>         0x0010:  0806 0001 0800 0604 0001 001d 1181 0000
>>         0x0020:  c0a8 0cbc 0000 0000 0000 c0a8 0c12
>>
>> Here's the ARP reply coming back:
>>
>> 13:46:29.348907 00:1e:c9:2f:73:6c > 00:1d:11:81:00:00, ethertype Unknown (0x8004), length 64:
>>         0x0000:  001d 1181 0000 001e c92f 736c 8004 0000
>>         0x0010:  0806 0001 0800 0604 0002 001e c92f 736c
>>         0x0020:  c0a8 0c12 001d 1181 0000 c0a8 0cbc 0000
>>         0x0030:  0000 0000 0000 0000 0000 0000 0000 0000
>>
>> I understand the 0x4000 DSA tag going out, but what's the 0x8004?
>>
> 
> Note: without the extra monitor bit (#4), I don't see these packets
> get back to my ethernet device.  Maybe the tag says something of why?

I found this tag in the 6131 manual - it basically says that it's
a copied packet which was received on VID 0.  Exactly as expected.

> Any pointers on how I can test/debug the "VLAN" (internal routing) setup?

Do you understand where (which register settings) cause packets
which come in on lan1.1 (VID=0 I think, port 0) to be sent on
to the CPU port (10) along with the TO_CPU tag?  I've been through
this document a dozen times and I still don't see where the mapping
that direction happens...
Lennert Buytenhek - March 10, 2009, 9:39 a.m.
On Mon, Mar 02, 2009 at 11:56:22AM +0100, Jesper Dangaard Brouer wrote:

> > The main conclusion so far is that this write (net/dsa/mv88e6131.c):
> > 
> > 	/*
> > 	 * MAC Forcing register: don't force link, speed, duplex
> > 	 * or flow control state to any particular values.
> > 	 */
> >	REG_WRITE(addr, 0x01, 0x0003);
> 
> This sort of enables auto-detection of speed.
> 
> > isn't correct on ports that can either be CPU ports or external ports.
> 
> For external ports I had to enabled the PPU to allow the external PHYs
> to negotiate.

The PPU should be re-enabled 10ms after the last MII access.


> Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to
> register 0x1, PCS Control Register).  Which also enables inband
> auto-negotiation, but I'm not sure this is necessary.

Not sure whether it is.  Gary?


> > Forcing the link up on the CPU port helps somewhat, but things aren't
> > 100% working yet.
> 
> On the CPU port I force link-up and force speed+duplex setting.  I only
> got 100Mbit/s to the CPU port...

I suppose the cpu port speed should be made into a platform data
config option in case there's only a 100 Mb/s link on a gigabit
capable switch?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lennert Buytenhek - March 10, 2009, 9:43 a.m.
On Mon, Mar 02, 2009 at 08:22:17AM -0700, Gary Thomas wrote:

> >>> You should write 0x003E ... see attached patch
> >> Ups, I see (from the thread) that you have already done/tried this...
> > 
> > Yes, although I think it will need some work in the future
> > (I've set it to 1000Mb connection, you said you used 100Mb, etc)
> > 
> > Question: I'm testing this by trying a ping out of my box.
> > Linux replies by sending an ARP packet out, and the destination
> > replies with an ARP packet in.  I can see from the ethtool stats
> > that the reply packets get into lan1.1 (the physical port I'm
> > using), but I don't see them get moved through the CPU port.
> > My understanding is that this should work via the VLAN map?
> > I checked that setup and it looks OK.
> > 
> > Any ideas where this might be going wrong?
> 
> I also just noticed that the ESA registers (Global 1,2,3)
> aren't set at all.

This is done by mv88e6xxx_set_addr_{in,}direct() in mv88e6xxx.c,
via the ->set_addr() callback.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Lennert Buytenhek - March 10, 2009, 9:56 a.m.
On Mon, Mar 02, 2009 at 11:05:29PM +0100, Jesper Dangaard Brouer wrote:

> >>My understanding is that this should work via the VLAN map?
> 
> I think that the "VLAN map/table" has gotten a wrong name as it does not 
> really determine the VLANs, it only says who can talk to whom.  The switch 
> does support a real vlan setup, but its deactivated in Lennerts driver, as 
> I guess he wants Linux to handle the VLANs.  (I use the real VLAN setup 
> extensively in my driver).

I have some patches that make use of this (see the earlier h/w
bridging patch I posted to netdev@ -- I've extended that to handle
VLANs as well).  Without those patches, each port will just have its
own address database.


> >>I checked that setup and it looks OK.
> 
> I have also checked the different registers setting, and things looks 
> quite alright.  Although I'm missing the register datasheets for the 6131 
> chip, I found that I only have part 1 of 3 crap...
> 
> I did find that the 6095 and 6097 does differ in the way DSA handling is 
> done, as the 6097 supports Ethertype DSA and 6095 don't.  But the 6131 
> driver looks like it does the right thing for the 6095.

For the gigabit switches, there are more or less two groups of
switches from a register programming point of view.

Group 1:
- models: 6045, 6045f, 6092, 6095, 6095f, 6121, 6122,
  6131, 6152, 6155, 6182, 6185
- Support Header and DSA tagging.
- MAC address programmed directly via global 1/2/3.
- PPU handling generally needed.

Group 2:
- models: 6046, 6046f, 6085, 6096 (FE), 6097, 6097f, 6123, 6161, 6165 
- Support Header, DSA and Ethertype DSA tagging.
- MAC address programmed indirectly via global 1/2.
- PPU handling generally not needed.
- Extended stats access via bits [8:5]

(And of course, various advanced queueing/filtering capabilities are
only available in the higher end switches, but we don't use those
capabilities for now.)

So the 6095 is in the first group and the 6097 in the second.

The 6131 driver can probably be very easily extended to handle all
switches in the first group, and the 6123/6161/6165 driver can probably
be easily extended to handle all switches in the second group.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Gary Thomas - March 10, 2009, 11:20 a.m.
Lennert Buytenhek wrote:
> On Mon, Mar 02, 2009 at 11:56:22AM +0100, Jesper Dangaard Brouer wrote:
> 
>>> The main conclusion so far is that this write (net/dsa/mv88e6131.c):
>>>
>>> 	/*
>>> 	 * MAC Forcing register: don't force link, speed, duplex
>>> 	 * or flow control state to any particular values.
>>> 	 */
>>> 	REG_WRITE(addr, 0x01, 0x0003);
>> This sort of enables auto-detection of speed.
>>
>>> isn't correct on ports that can either be CPU ports or external ports.
>> For external ports I had to enabled the PPU to allow the external PHYs
>> to negotiate.
> 
> The PPU should be re-enabled 10ms after the last MII access.
> 
> 
>> Also, on external PHYs ports 8 and 9, I write 0x0403 not 0x0003 (to
>> register 0x1, PCS Control Register).  Which also enables inband
>> auto-negotiation, but I'm not sure this is necessary.
> 
> Not sure whether it is.  Gary?
> 

I'm not sure either.  On my system, these ports are SERDES used to
cascade switches.  When we get that part working, we may learn if
these bits are important.

> 
>>> Forcing the link up on the CPU port helps somewhat, but things aren't
>>> 100% working yet.
>> On the CPU port I force link-up and force speed+duplex setting.  I only
>> got 100Mbit/s to the CPU port...
> 
> I suppose the cpu port speed should be made into a platform data
> config option in case there's only a 100 Mb/s link on a gigabit
> capable switch?

I agree.

Patch

diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c

index 374d46a..400473a 100644

--- a/net/dsa/mv88e6131.c

+++ b/net/dsa/mv88e6131.c

@@ -159,9 +159,13 @@  static int mv88e6131_setup_port(struct dsa_switch *ds, int p)

 
 	/*
 	 * MAC Forcing register: don't force link, speed, duplex
-	 * or flow control state to any particular values.

+	 * or flow control state to any particular values.  Unless

+	 * this is the CPU port, then force 1Gb/s and link-up.

 	 */
-	REG_WRITE(addr, 0x01, 0x0003);

+	if ((p == ds->cpu_port))

+		REG_WRITE(addr, 0x01, 0x003E);

+	else

+		REG_WRITE(addr, 0x01, 0x0003);

 
 	/*
 	 * Port Control: disable Core Tag, disable Drop-on-Lock,