login
Search
Is there support for this device anywhere? In particular, the M88E6095 switch. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Not at the moment, but it should be easy enough to add. If your board already runs on 2.6.28+, I can whip up some patches for you to try from the docs I have for that part. --
That would be much appreciated, thanks. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
I noticed that the 6095/6095F are quite similar to the 6131 as far
as the register set goes. So something along these lines (hacky
patch, breaks 6131, not for mainline) might just work to detect
single 6095s (cascading DSA chips is something that needs more work,
let's get the single-chip case working first).
The other thing you'll need to do is create dsa platform devices
for your switch chips, a la how it's done in arch/arm/mach-orion5x/
or arch/arm/mach-kirkwood/ for example -- you need to pass in a struct
device * for your network device, a struct device * for your mii bus,
the switch MII address on the MII bus, and names of the individual
ports (where you'll specify "cpu" for the port on the switch chip that
the CPU is connected to).
Let me know if this works.
diff --git a/net/dsa/mv88e6131.c b/net/dsa/mv88e6131.c
index 374d46a..d530e63 100644
--- a/net/dsa/mv88e6131.c
+++ b/net/dsa/mv88e6131.c
@@ -21,6 +21,8 @@ static char *mv88e6131_probe(struct mii_bus *bus, int sw_addr)
ret = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), 0x03);
if (ret >= 0) {
ret &= 0xfff0;
+ if (ret == 0x0950)
+ return "Marvell 88E6095/88E6095F";
if (ret == 0x1060)
return "Marvell 88E6131";
}
@@ -36,7 +38,7 @@ static int mv88e6131_switch_reset(struct dsa_switch *ds)
/*
* Set all ports to the disabled state.
*/
- for (i = 0; i < 8; i++) {
+ for (i = 0; i < 11; i++) {
ret = REG_READ(REG_PORT(i), 0x04);
REG_WRITE(REG_PORT(i), 0x04, ret & 0xfffc);
}
@@ -268,7 +270,7 @@ static int mv88e6131_setup(struct dsa_switch *ds)
if (ret < 0)
return ret;
- for (i = 0; i < 6; i++) {
+ for (i = 0; i < 11; i++) {
ret = mv88e6131_setup_port(ds, i);
if (ret < 0)
return ret;
@@ -279,7 +281,7 @@ static int mv88e6131_setup(struct dsa_switch *ds)
static int mv88e6131_port_to_phy_addr(int port)
{
- if (port >= 0 && port != 3 && port <= 7)
+ if (port >= 0 && port <= 11)
return port;
return -1;
}
--
Thanks, I'll give it a try. It will take a little effort to get setup as I have to work within the open firmware structure (that's how all the various components are specified). -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Right, we don't have OF bindings yet. I guess this would make sense to do generically at some point, since there are quite a few PPC platforms with DSA switch chips. --
Here's what I tried - (patch attached) - a trulyhorrible hack, but I've not figured out how to get the correct device pointers from the OF world yet. The boot log shows that it's trying, but I don't see the DSA layer (M88E690x driver) doing the MII indirection that's needed for this device. I'm probably not starting it up correctly, but I think I followed the examples you cited. Any ideas? Thanks =============== boot log =============================== Set gianfar_mdio = cf82fc08, mii_bus = cf9db400 gfar_mdio_read(cf9db400, 32, 2) = 0 gfar_mdio_read(cf9db400, 32, 3) = 0 gfar_mdio_read(cf9db400, 31, 2) = ffff gfar_mdio_read(cf9db400, 31, 3) = ffff gfar_mdio_read(cf9db400, 0, 2) = ffff gfar_mdio_read(cf9db400, 0, 3) = ffff gfar_mdio_read(cf9db400, 1, 2) = ffff gfar_mdio_read(cf9db400, 1, 3) = ffff gfar_mdio_read(cf9db400, 2, 2) = ffff gfar_mdio_read(cf9db400, 2, 3) = ffff gfar_mdio_read(cf9db400, 3, 2) = ffff gfar_mdio_read(cf9db400, 3, 3) = ffff gfar_mdio_read(cf9db400, 4, 2) = ffff gfar_mdio_read(cf9db400, 4, 3) = ffff gfar_mdio_read(cf9db400, 5, 2) = ffff gfar_mdio_read(cf9db400, 5, 3) = ffff gfar_mdio_read(cf9db400, 6, 2) = ffff gfar_mdio_read(cf9db400, 6, 3) = ffff gfar_mdio_read(cf9db400, 7, 2) = ffff gfar_mdio_read(cf9db400, 7, 3) = ffff gfar_mdio_read(cf9db400, 8, 2) = ffff gfar_mdio_read(cf9db400, 8, 3) = ffff gfar_mdio_read(cf9db400, 9, 2) = ffff gfar_mdio_read(cf9db400, 9, 3) = ffff gfar_mdio_read(cf9db400, 10, 2) = ffff gfar_mdio_read(cf9db400, 10, 3) = ffff gfar_mdio_read(cf9db400, 11, 2) = ffff gfar_mdio_read(cf9db400, 11, 3) = ffff gfar_mdio_read(cf9db400, 12, 2) = ffff gfar_mdio_read(cf9db400, 12, 3) = ffff gfar_mdio_read(cf9db400, 13, 2) = ffff gfar_mdio_read(cf9db400, 13, 3) = ffff gfar_mdio_read(cf9db400, 14, 2) = ffff gfar_mdio_read(cf9db400, 14, 3) = ffff gfar_mdio_read(cf9db400, 15, 2) = ffff gfar_mdio_read(cf9db400, 15, 3) = ffff gfar_mdio_read(cf9db400, 16, 2) = ffff gfar_mdio_read(cf9db400, 16, 3) = ffff gfar_mdio_read(cf9db400, ...
"indirection needed for this device" -- does that mean that your switch chip is configured to use the multi-chip addressing mode? (It looks like it, as most of the MII addresses return ffff in their ID registers.) If yes, you should set ->sw_addr to whatever MII address the chip has been assigned. --
Much better, my switch seems to be found now.
Distributed Switch Architecture driver version 0.1
gfar_mdio_read(cf9db400, 1, 0) = 1811
gfar_mdio_write(cf9db400, 1, 0, 9a03) = 0
gfar_mdio_read(cf9db400, 1, 0) = 1a03
gfar_mdio_read(cf9db400, 1, 1) = 953
mv88e6131_probe(cf9db400, 1) = 2387
eth0: detected a Marvell 88E6095/88E6095F switch
...
root@ppc_target:~ ls /sys/bus/mdio_bus/devices/
24520:01:00 24520:01:02 24520:01:04 24520:01:06
24520:01:01 24520:01:03 24520:01:05 24520:01:07
However, the network subsystem still can't locate it. It may be
a complication of the OF stuff and how the [gianfar] network
device knows what PHY to look at.
starting network interfaces...
24520:01 not found
eth0: Could not attach to PHY
Also, how do I specify the [implicit] route within the switch
that connects '24520:01:00' to the CPU port '24520:01:0A' (if
there was such a thing)? My boot loader has configured the
switch for this path - I've not looked through the log to see
what the DSA layer did.
Thanks for your help
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Trying the simple/obvious did not work so well: Distributed Switch Architecture driver version 0.1 mv88e6131_probe(cf9db400, 1) = 2387 eth0: detected a Marvell 88E6095/88E6095F switch dsa slave smi: probed lan1.2: 24520:01:00 already attached Unable to handle kernel paging request for data at address 0x00000024 Faulting instruction address: 0xc019e584 Oops: Kernel access of bad area, sig: 11 [#1] ASP8347E Modules linked in: NIP: c019e584 LR: c019e570 CTR: c018a734 REGS: cf821c40 TRAP: 0300 Not tainted (2.6.28-svn4872-dirty) MSR: 00009032 <EE,ME,IR,DR> CR: 22000024 XER: 20000000 DAR: 00000024, DSISR: 20000000 TASK = cf81f900[1] 'swapper' THREAD: cf820000 GPR00: 00000001 cf821cf0 cf81f900 cf9ff200 00001697 ffffffff c018aeec 00004000 GPR08: 00000001 00000000 00003fff cf9ff200 82000022 7e700000 00050000 00019edc GPR16: fffffffd 00050000 00043514 00044320 000434e8 c0362e88 c02f8f9c cf854800 GPR24: cf8549c0 00000001 00000001 c0362e88 cf854800 cf9ff3b8 cf9f9b80 cf9ff200 NIP [c019e584] phy_start_aneg+0x34/0xcc LR [c019e570] phy_start_aneg+0x20/0xcc Call Trace: [cf821cf0] [c019ff0c] phy_attach+0x140/0x148 (unreliable) [cf821d10] [c025ae3c] dsa_slave_create+0x16c/0x1ac [cf821d30] [c025aa9c] dsa_probe+0x428/0x454 [cf821d70] [c0193cc4] platform_drv_probe+0x20/0x30 [cf821d80] [c0192ae0] driver_probe_device+0xb4/0x1e8 [cf821da0] [c0192cb8] __driver_attach+0xa4/0xa8 [cf821dc0] [c0192278] bus_for_each_dev+0x5c/0xa4 [cf821df0] [c01928fc] driver_attach+0x24/0x34 [cf821e00] [c0191b90] bus_add_driver+0x1d8/0x24c [cf821e20] [c0192ed8] driver_register+0x70/0x160 [cf821e40] [c0193f94] platform_driver_register+0xac/0xbc [cf821e50] [c0339828] dsa_init_module+0x18/0x28 [cf821e60] [c0003874] do_one_initcall+0x38/0x194 [cf821fc0] [c031a178] kernel_init+0x94/0x100 [cf821ff0] [c0010df8] kernel_thread+0x4c/0x68 Ideas? -- ------------------------------------------------------------ Gary Thomas | ...
What did you do here? Also, can you show me what you're filling the dsa platform data structure with? --
I just tried to force it by making it probe '24520:01:00'
struct dsa_platform_data _switch_data = {
.port_names[0] = "lan1.1",
.port_names[1] = "lan1.2",
.port_names[2] = "lan1.3",
.port_names[3] = "lan1.4",
.port_names[4] = "lan1.5",
.port_names[5] = "lan1.6",
.port_names[6] = "lan1.7",
.port_names[7] = "lan1.8",
.port_names[10] = "cpu",
.sw_addr = 1,
};
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Just this should do the trick. So what's not working -- are the interfaces not showing up? Or packet RX/TX isn't working? Or something else? --
It won't let me bring up eth0 (my scripts try to run DHCP):
starting network interfaces...
24520:01 not found
eth0: Could not attach to PHY
ip: SIOCSIFFLAGS: No such device
As for the other devices, they do show up if I let eth0 try to
attach to the PHY:
root@ppc_target:~ cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compresse
d
lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
eth0: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
eth1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.1: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.2: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.3: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.4: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.5: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.6: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.7: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
lan1.8: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
OK. If you try to cheat the gianfar driver by having it attach to the PHY for lan1.1, and plug a network cable into lan1.1 so that the link goes up and gianfar thinks that the link on eth0 is up, does that enable you to pass packets over any of the switch interfaces? That should be working now in this stage. --
So, what name do I use when the gianfar is trying to attach? It makes this call: phydev = phy_connect(dev, phy_id, &adjust_link, 0, interface); where phy_id="24520:01". Using "24520:01:00" gets an error: eth0: 24520:01:00 already attached Maybe the DSA layer/driver needs to export a device "24520:01" which pretends all of the things that the gianfar wants (1000Mb/Full/Link)? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Well, this isn't DSA-specific -- e.g. if you'd hook your CPU's ethernet MAC up to an FPGA, you'd be in the same situation. Maybe there is some fake PHY you can instantiate -- the "Fixed" MDIO bus maybe? Can you try enabling CONFIG_FIXED_PHY and pointing it to that? --
OK, I did that: Sending discover... PHY: 0:01 - Link is Up - 1000/Full I now see the fixed PHY (pretender, configured at build time) and the 8 LAN sockets: root@ppc_target:~ ls /sys/bus/mdio_bus/devices/ 0:01 24520:01:01 24520:01:03 24520:01:05 24520:01:07 24520:01:00 24520:01:02 24520:01:04 24520:01:06 But nothing seems to get through the switch. Of course, I know that the switch and connections are working because that's the path I downloaded/booted the kernel from. Getting closer :-) Any ideas? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
being up, full duplex, etc? Something a la (from one of my boards): lan1: link up, 1000 Mb/s, full duplex, flow control disabled lan2: link up, 1000 Mb/s, full duplex, flow control disabled If yes, can you up the interfaces, and send some packets over them and see if the TX counters on eth0 increase? If yes, can you dump the packets sent out over eth0 using tcpdump? --
This does seem to work:
root@ppc_target:~ ifconfig lan1.1 up
root@ppc_target:~ lan1.1: link up, 100 Mb/s, full duplex, flow control disabled
When I try it on other ports:
root@ppc_target:~ ifconfig lan1.2 up
root@ppc_target:~ ifconfig lan1.3 up
Those ports aren't plugged (and I'm 6000 miles from them, literally,
I tried to ping out and into the box. Nothing seems to go anywhere:
root@ppc_target:~ ifconfig
eth0 Link encap:Ethernet HWaddr 00:1D:11:81:00:00
inet addr:192.168.12.189 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:17 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:1810 (1.7 KiB)
Base address:0x6000
lan1.1 Link encap:Ethernet HWaddr 00:1D:11:81:00:00
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)
Running tcpdump on the external network (192.168.12.x), I saw
no activity.
Do I need to do anything more than "ifconfig lan1.1 up"?
Maybe the "." is confusing things? I was just trying to
look ahead when I have 3 switches running.
Thanks
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
IP addresses should be attached to the lanX.X interfaces, not to eth0 -- eth0 will only be carrying specially tagged (DSA/EDSA) packets. So you should move the IP address to lan1.1. Can you trying pinging via lan1.1 and then seeing if there are That shouldn't be causing trouble as far as I can see. --
It looks like the packets are going out, but I don't see anything
on the wire. After a few ping attempts:
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:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2974 (2.9 KiB)
Base address:0x6000
lan1.1 Link encap:Ethernet HWaddr 00:1D:11:81:00:00
inet addr:192.168.12.189 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:39 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1638 (1.5 KiB)
The eth0 and lan1.1 counters are going up at more or less the
same rate.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Can you run tcpdump on eth0 to see what the packets look like? --
Locally (on the board with the switch)? That will take a while to set up as it's a 100% embedded system, runs from FLASH, etc. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
OK, do you have ethtool then? If yes, can you run ethtool on the lan1.1 interface to see if any of the hardware (switch chip) TX counters are increasing? --
Here's the result of 'tcpdump -i eth0' while pinging:
PING 192.168.12.18 (192.168.12.18): 56 data bytes
15:52:34.718207 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
0x0000: 0000 0806 0001 0800 0604 0001 001d 1181 ................
0x0010: 0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12 ................
15:52:35.717893 00:1d:11:81:00:00 (oui Unknown) > Broadcast, ethertype Unknown (0x4000), length 46:
0x0000: 0000 0806 0001 0800 0604 0001 001d 1181 ................
0x0010: 0000 c0a8 0ca8 0000 0000 0000 c0a8 0c12 ................
I also tried pinging in from the outside, but didn't see any
packets. I would assume that I'd see at least broadcast/ARP
I'm not familiar with that tool (I did install it). What
option (of the *many*) are you interested in?
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Can you dump the entire packet (-s 2000) including the ethernet "ethtool -S lan1.1", please. Perhaps we should take this off-list.. --
I'm still interrested... please Cc. me at jdb@comx.dk. Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- --
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); isn't correct on ports that can either be CPU ports or external ports. Forcing the link up on the CPU port helps somewhat, but things aren't 100% working yet. --
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 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 -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer
Ups, I see (from the thread) that you have already done/tried this... -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer --
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 | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
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? -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
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 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 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 Is lan1.1 up and have you given it an IP address? (could I get a 'ifconfig' output?) 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 ------------------------------------------------------------------- --
I agree that the simple mode Lennert's code uses is not VLAN on
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
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 ...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? -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer --
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? -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer --
I don't think this is a problem; no packets are getting [back] to the gianfar interface (based on RX interrupt counts) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Thanks -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
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?
--
Med venlig hilsen / Best regards
Jesper Brouer
ComX Networks A/S
Linux Network developer
Cand. Scient Datalog / MSc.
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
--
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 | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
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 | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
I found this tag in the 6131 manual - it basically says that it's 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... -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
After much experimentation, I finally found out what was wrong. Basically, the trunk masks have 8 bits on the 6131, but 11 bits on the 609x and this wasn't being handled. Once the trunk masks were reset by the init code, there was no path to the CPU port from the LAN ports :-( The attached patch is what I've ended up with. It works, at least for a single switch. Next, I need to get it to work with multiple switches (separate ethernet controllers, same/shared MII bus), as well as a cascaded switch. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Thats great! ... finally you discovered the difference :-) Once you are ready with a more final patch, I'll be happy to review it (and fixup any whitespace compliance stuff... which the attached patch Okay, I'll be happy to review any patches, but I don't have any experience with a multiple switch chip setup... -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer --
That should be easy -- the DSA driver only accesses MII buses via
phylib, and that does the required locking, etc. Also, we've
That's a bit trickier, but also not entirely hard:
- Instead of the CPU port concept, we'll have to use the port number
that brings us one hop closer to the CPU (i.e. the upstream port).
- Assign each chip a DSA device address (instead of always setting it
to zero).
- Populate the 'DSA device address -> port' mapping table for each
switch.
- Enable DSA tagging and flooding of unknown unicasts and multicasts
on all inter-switch links and not just on the CPU port on switch 0.
I don't think it makes sense to implement Dijkstra in the kernel, so
it's probably easiest to just pass in a precomputed NxN array of how
to go from which switch to which switch via which port, along with a
separate DSA port list for each switch chip.
I don't have multi-switch chip setups myself, or I would have
implemented this already. But I can whip up some patches to try..
commit 7dd5aedb30eb17db82dde8c8fe8bc0f0f11ad332
Author: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Tue Mar 10 11:08:46 2009 +0100
dsa: add support for the Marvell 88E6095/6095F switch chips
Add support for the Marvell 88E6095/6095F switch chips. These
chips are similar to the 88e6131, so we can add the support to
mv88e6131.c easily.
Thanks to Gary Thomas <gary@mlbassoc.com> and Jesper Dangaard
Brouer <hawk@diku.dk> for testing various patches.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
diff --git a/net/dsa/Kconfig b/net/dsa/Kconfig
index 49211b3..c51b554 100644
--- a/net/dsa/Kconfig
+++ b/net/dsa/Kconfig
@@ -41,13 +41,13 @@ config NET_DSA_MV88E6XXX_NEED_PPU
default n
config NET_DSA_MV88E6131
- bool "Marvell 88E6131 ethernet switch chip support"
+ bool "Marvell 88E6095/6095F/6131 ethernet switch chip support"
select NET_DSA_MV88E6XXX
select NET_DSA_MV88E6XXX_NEED_PPU
select NET_DSA_TAG_DSA
...This looks fine to me - is this part safe on the smaller parts
(6131, etc)? I wasn't sure about setting those "reserved" bits
That would be great. What I'd like to figure out is a
way to provide that mapping (static from the driver point
of view), much like the current "port_names[]" table now.
For my particular setup, there are two cases (on the same
board):
Switch 1 - ports 1..8
Switch 2 - ports 9..16
Switch 3 - ports 17..24 (cascaded off of Switch 2)
Thus, the only access to Switch 3 and its ports is indirect via
Switch 2.
Presumably, one could have a multiple cascade, so this structure
should be considered from the start.
Thanks for your help
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Something a la the attached patch should be enough from the
Switch 1 can correspond to its own DSA platform device as it is now.
And for switch 2/3 you'd then have something a la:
struct dsa_switch_data switches[] = {
{
.mii_bus = &blah,
.sw_addr = 2,
.port_names[0] = "p9",
.port_names[1] = "p10",
.port_names[2] = "p11",
.port_names[3] = "p12",
.port_names[4] = "p13",
.port_names[5] = "p14",
.port_names[6] = "p15",
.port_names[7] = "p16",
.port_names[9] = "dsa",
.port_names[10] = "cpu",
}, {
.mii_bus = &blah,
.sw_addr = 3,
.port_names[0] = "p17",
.port_names[1] = "p18",
.port_names[2] = "p19",
.port_names[3] = "p20",
.port_names[4] = "p21",
.port_names[5] = "p22",
.port_names[6] = "p23",
.port_names[7] = "p24",
.port_names[9] = "dsa",
},
};
struct dsa_platform_data switch23 = {
.netdev = &blah,
.nr_switches = 2,
.sw = switches,
.rtable = {
{ -1, 9 },
{ 9, -1 },
},
};
Or something along those lines.
Thoughts?
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 52e97bf..8bbf5ba 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -1,6 +1,6 @@
/*
* include/net/dsa.h - Driver for Distributed Switch Architecture switch chips
- * Copyright (c) 2008 Marvell Semiconductor
+ * Copyright (c) 2008-2009 Marvell Semiconductor
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -13,21 +13,44 @@
#define DSA_MAX_PORTS 12
+struct dsa_switch_data {
+ /*
+ * How to access the switch configuration registers.
+ */
+ struct device *mii_bus;
+ int sw_addr;
+
+ /*
+ * The names of the switch's ports. Use "cpu" to
+ * designate the switch port that the cpu is connected to,
+ * "dsa" to indicate that this port is a DSA link to
+ * another switch, NULL to indicate the port is unused,
+ * or any other string to indicate this is a physical port.
+ ...The setup looks good. Let me know when you have the rest of the patch ready to test (I'm all setup here) -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
OK, I hit a snag with my initial implementation (we can't put an array of dsa_switch in dsa_switch_tree as dsa_switch has driver-private data at the end, making it variable length), but I should hopefully have a patch by day end. --
Attached patch is what I came up with, and should implement full
cascaded DSA. It adds the DSA device ID to DSA/EDSA tags, should
be able to deal with trees of DSA switches, and should configure
inter-switch links for DSA tagging and the CPU port for DSA or
EDSA tagging depending on which one we want.
Basically, this should let you send DSA tagged FROM_CPU packets to
any switch because it sets up the device routing table in each switch
correctly, TO_CPU packets should be able to find the CPU because we
program the upstream port into each switch, and unknown unicasts/
multicasts should find the CPU because only to upstream ports can
unknown unicasts/multicasts be forwarded.
I don't have multi-chip devices to test with, but it seems to still
work (i.e. ping still works) on the main board I use for testing
(which has a 6165).
Can you see if it works for you?
Left to do:
- Perhaps enumerate switches in multiple passes: first forcibly
disable all ports, then configure all ports, and then re-enable
link, to prevent races where one end of an inter-switch link is
switched to DSA mode while the other end isn't yet.
- Re-port the HW bridging patch to go on top of this patch.
- Check if we need in-band autoneg and/or link speed forcing for
SERDES ports.
- Perhaps allow configuring the speed/duplex/etc of the CPU port.
- Split up the patch into smaller pieces.
commit 0aabe480fe99c02a6609bdd2d2cecb001e82a7c7
Author: Lennert Buytenhek <buytenh@wantstofly.org>
Date: Wed Mar 11 22:08:05 2009 +0100
dsa: add dsa cascading support
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
diff --git a/arch/arm/mach-kirkwood/common.c b/arch/arm/mach-kirkwood/common.c
index b3404b7..a2c8f6e 100644
--- a/arch/arm/mach-kirkwood/common.c
+++ b/arch/arm/mach-kirkwood/common.c
@@ -231,14 +231,17 @@ static struct platform_device kirkwood_switch_device = {
void __init kirkwood_ge00_switch_init(struct dsa_platform_data *d, int irq)
{
+ int i;
+
if (irq ...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 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. --
This is done by mv88e6xxx_set_addr_{in,}direct() in mv88e6xxx.c,
via the ->set_addr() callback.
--
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'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 I agree. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Hi Jesper, Lennert and I have been working on this and we have parts of it working (PowerPC GIANFAR 1000Mb driver). I can get the basic switch recognized and packets go out, but nothing seems to come back in. I'll continue to work on this and let you know of the progress. Lennert is away for a few days, so the actual progress may be a bit slow... -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ --
Strange behavior... If you will send me the current patches/code, then I'll use some time monday to look at the register settings to see if I can spot the problem, Thanks for keeping me in the loop :-) Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- --
I'm using the 6131 driver (which is mostly the same as the 6095). There are no other changes other than to force the link on the CPU port (10). Actual changes attached. Note: the HACK in the 'get_ethtool_stats' is so I can peek at the CPU port info, Thanks for any ideas you might have. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Looking through my old code I found this comment, which indicate that you should take care of PPU (Phy Polling Unit) state... I had to support both the 6095 and 6097 chip. Cite code: /*** Setup PHY's ***/ /* Accessing the PHY devices is special. Direct access to a PHY device requires that the PPU (Phy Polling Unit) has been disabled. The 6097 series support indirect access through SMI registers (GLOBAL_DEV2 registers 0x18 and 0x19). Disabling the PPU _here_ is not necessary, as the drivers R/W operation handles disabling the PPU or does indirect SMI access (if supported by the chip). Notice, that there is a catch with the 6097 SMI access, as it requires the PPU to be enabled (or else it will returns 0xFFFF). */ Thus, you should make sure that the PPU is disabled during setup of the PHYs. Well, I don't think this will solve all your issues... I'm still looking for the missing link... -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network developer Cand. Scient Datalog / MSc. Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer --
PPU disabling/enabling should be handled by the current code already, as it is also necessary for the 6131 (but not for the 6161/6165/etc). --
It's correct that eth0 should not associate with a PHY -- since the MAC connects to the switch chip over GMII/RGMII/SGMII, there is no PHY involved. Is the gianfar driver refusing to up the interface without a PHY? It shouldn't do that -- IMHO it's perfectly fine to not have a PHY Just specify "cpu" as the port name of port 10 in your dsa platform data (assuming that there's where your CPU is), that'll take care of it. Does it give you Linux network interfaces for the other switch chip ports (1-8)? thanks, Lennert --
Yes, but it's expecting to be able to talk to the PHYLIB layer
It seems so, yes. I tried disabling the PHY connection in the OF
Not sure I understand this question, there are no other network
interfaces listed:
root@ppc_target:~ cat /proc/net/dev
Inter-| Receive | Transmit
face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compresse
d
lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
gianfar authors/maintainers: is there a way of using gianfar purely as a (R)(G)MII transport, i.e. without it trying to talk to a PHY? Gary is trying to use it to just pass packets to another (R)(G)MII-speaking chip that doesn't have a PHY interface, but gianfar seems to bail out if you don't give it a PHY to talk to. --
You can use fixed-link property in the device tree, and CONFIG_FIXED_PHY driver. See arch/powerpc/boot/dts/mpc8349emitx.dts as an example, and Documentation/powerpc/dts-bindings/fsl/tsec.txt for the fixed-link's fields meaning. -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --
I have written a driver for the M88E6095F and M88E6097F switch, but only for an embedded 2.4.20 kernel device. I have written it from scratch, so its not covered by Marvell license. Although lately different marvell DSA support was added to kernel 2.6. Whats you usage? Hilsen Jesper Brouer -- ------------------------------------------------------------------- MSc. Master of Computer Science Dept. of Computer Science, University of Copenhagen Author of http://www.adsl-optimizer.dk ------------------------------------------------------------------- --
