01-20-2014 12:02 PM
Actually, I believe my testing methodology was wrong in the last post. Since eth0 and eth1 were on the same subnet, it is correct (?) behavior for the packet to be routed on either port.
I've since changed my testing to assign different subnets to each port so that all traffic on a specific subnet has to go to a specific port.
The problem still exists though. The first port eth0 works correctly and the second eth1 does not work. The system detects the cable being attached/deteched correctly onboth ports but no ping or packet transfer works on eth1...
I am beginning to believe it is a h/w issue...
05-12-2014 03:33 PM
Is there a resolution to this issue yet?
We are trying to bring up dual ethernet interfaces on a board with two Marvell 88E1512 PHYs. We can excercise each Ethernet interface by itself (new SDK and DTS for each test). Whichever ethernet is configured in Vivado as the one with MDIO works, but the other interface doesn't. The MDIO is shared for both Ethernets. I've probed the MDIO and the processor isn't even trying to talk to either PHY when I try to setup the other phy.
I'm on kernel version 2013.4.
05-14-2014 08:22 AM
We too having been struggling to get both Ethernet interfaces going reliably. The root of the problem seems to be the use of an integrated MDIO bus interface within each MAC routed to a shared bus through the MIO pin muxes. It seems that you either need to modify the driver to 'reuse' the 'master' MDIO bus interface or presumably you could modify the driver to dynamically reconfigure the MIO pin muxes to arbitrate between the two controllers. We have had some success based on the solution proposed by http://forums.xilinx.com/t5/Embedded-Linux/zynq-linux-dual-emacps-gem-problem/m-p/353919#M6814 which attempts to share the MDIO interface for eth0 between both MACs.
I don't believe this is a complete fix though; we found that although it allowed us to bring both interfaces up the OS would often hang when trying to take the interfaces back down, eg, as part of reboot. This is because as soon as eth0 is taken down the MDIO interface is helpfully disabled which means that the next MDIO access attempted by the driver for eth1 gets stuck! Not sure but we also wondered whether there was a small risk that, with the MDIO interface shared, the MDIO read/write functions could be reentered.
Anyway, we further modified the driver to NEVER disable the MDIO interface. We also added a spin lock to arbitrate access to the MDIO register.
Finally (and nothing to do with using both MACs) we tried using ifplugd to react to the cable being plugged in and out and found that taking the cable out cause ifplugd to go off on one bringing the interface up then down repeatedly. It seems that this was caused by an unconditional call to netif_carrier_on() at the end of xemacps_open(); on our board the MDIO interface is polled so there is a short period between enabling the interface and checking the link status during which the carrier is erroneously reported as being present. Touchwood we have fixed this by now testing the link status and calling netif_carrier_on() or netif_carrier_off() as appropriate.
Our patch file is below if it helps. (We're using xilinx_emacps.c downloaded from Xilinx git hub 14 April 2014.)
05-19-2014 02:16 AM
UPDATE: Unfortunately our solution is still not 100% as our Ethernet interfaces occasionally fail to come up properly (and subsequently connecting via serial port and using, eg, ifconfig or ethtool, the terminal locks up and the call never returns). Thought it might be our use of a spin lock to arbitrate access to the MDIO register so have replaced with a semaphore (updated patch attached) but this still does not appear to have completely fixed it.
05-28-2014 02:38 PM
I'm now working on this problem also and I like your cleaned up patch as it removes part of the patch that seemed un-necessary to me (changing the mii bus id from the emac base addr to 0).
All the stuff you added makes sense to me, but I'm continuing to review and dig to see if I can find anything else that might be causing issues.
05-29-2014 05:03 PM
I found some interesting stuff today as I debugged on it some. I found that lockup during ifconfig also and figured out there are some PM issues with this patch. If I disable PM_RUN_TIME (think that's the spelling) in the kernel config it removes that lockup issue.
I also found that on my system I have a clocking issue in the device tree. The 2nd EMAC clocking was causing the clock to be set to 0 Hz when ifconfig was done. I swapped to the clock of the 1st EMAC on the 2nd EMAC in the device tree and that problem seems better. I don't have real hardware so my testing is limited.
05-30-2014 12:13 AM
Thanks for your feedback. It's interesting to hear about you findings re CONFIG_PM_RUNTIME, we'll certainly give that a go if we continue to get problems with locking up. I've not got to grips with the power management options for the Zynq; we don't have a programmable power supply but presumably we might be able to control the speed of the CPU in response to load; our Zynq seems to get pretty hot so it would be a shame to disable all PM options. The CONFIG_PM_RUNTIME help snippet suggests this option is related to IO devices. Do you know if this means that we can disable this without disabling any PM options for the CPU itself?
Re the clock we don't appear to have a persistent problem here as when both MACs are up we can communicate on both and operate them at different rates. What was the symptom of your clock bug?
Thanks for your help.
05-30-2014 12:36 PM
All the power management and clocking is not totally obvious to me yet either. I see in the kernel configuration that I can turn on CPU frequency scaling without the PM being on. It stilll boots fine but I have not tried to test Ethernet while changing the CPU frequency as I don't remember how to do it. Soren may comment on that more.
My issue with the 2nd EMAC clock was exhibited by "Set clk to 0 Hz" message when bringing up the interface. This was really just an issue with my h/w setup and device tree.
In my digging I notice that the PHYs are probed early during the 1st EMAC probe such that when you bring the interface up and it shows the PHY info that's not actually talking to the PHY at that point. This can be deceiving when debugging. If you don't get a status showing the link is up or down then the driver is not really talking to the PHY.
05-30-2014 05:23 PM
cpufreq, cpuidle and runtime PM are all separated from each other you can enable/disable them independently.
07-09-2014 08:38 PM
07-10-2014 07:30 AM
I am experiencing an interesting problem with our dual NIC environment. It appears that outbound packets are getting routed to a disconnected NIC.
I have a program that periodically sends a multicast packet outbound. When only eth0 is enabled, all packets are sent correctly and received at the destination. Then I enable eth1using:
ifconfig eth1 down
ifconfig eth1 hw ether 00:80:01:02:03:04
ifconfig eth1 192.168.1.78 netmask 255.255.255.0 up
route add default gw 192.168.1.1 dev eth1
If a cable is connected to both eth0 and eth1, the multicast packets are received by the destination correctly. However, if a cable is not connected to eth1 when I run the above commands, approximately half of the multicast packets are lost and never received at the destination.
So, it appears that Linux is routing some of the multicast packets to eth1 even though the cable is not connected.
Has anyone observed anything similar? Surely this is not correct behavior. Is there a different /better way to bring up eth1?
Linux does detect a cable insertion / extraction on either NIC correctly, i.e. the cable connect/disconnect message is routed to the console.
Thanks for any suggestions.
09-24-2014 05:16 PM
Please check this iisue on zynq linux :https://github.com/Xilinx/linux-xlnx/issues/7
Zynq does not work with 2 ethernet interfaces currently, and it is still an open issue.
We have to wait until it is resolved by xilinx.
Or, we fix it.
10-11-2014 03:41 AM
Please check following site:
I think xilinx has fixed this issue, yet not released currently.
The patch is applied in master-next branch.
03-03-2015 10:21 AM
2014.4 seems to have fixed it all, we have
2x ETH on PS MIO pins, shared MDIO
2x ETH AXI_ethernet inside PL, separate MDIO
all 4 eth interfaces get their MDIO buses correctly.
10-09-2015 07:39 PM
You seem to have solved "2x ETH on PS MIO pins, shared MDIO".
Can you tell me how to config the hardware in Vivado Project, and how to write the dts file?
and my dts is below:
ethernet1 = &gem1;
local-mac-address = [00 0a 35 00 c0 12];
phy-handle = <&phy0>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,88e1116r";
device_type = "ethernet-phy";
reg = <7>;
enet-reset = <&gpio0 15 0>;
local-mac-address = [00 0a 35 00 c0 13];
phy-handle = <&phy1>;
status = "okay";
compatible = "marvell,88e1116r";
device_type = "ethernet-phy";
reg = <6>;
10-21-2015 12:19 PM
I'm having problems getting multiple ethernet working with a configuration similar to yours. Could you share your relevant portion of your device tree? We have the standard Zynq gigabit port (as found on the ZC702 system) along with 2 AXI Ethernet Lite inside PL with their own MDIO. When I configure them with 2014.4, they all configure, but I can't ping any of them. I get different results with 2015.2 and 2015.2.1.
10-22-2015 12:16 PM
It turns out we had a configuration problem, and it does indeed work fine under 2014.4. I haven't tried it with 2015.2 yet.