UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
9,849 Views
Registered: ‎07-09-2012

Re: zynq linux - dual emacps(gem) problem

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...

0 Kudos
Visitor mwales
Visitor
9,489 Views
Registered: ‎11-07-2013

Re: zynq linux - dual emacps(gem) problem

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.

0 Kudos
Observer tnjames
Observer
9,457 Views
Registered: ‎07-08-2013

Re: zynq linux - dual emacps(gem) problem

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.)

 

Cheers

 

Tim

0 Kudos
Observer tnjames
Observer
9,410 Views
Registered: ‎07-08-2013

Re: zynq linux - dual emacps(gem) problem

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.

 

Tim

0 Kudos
Xilinx Employee
Xilinx Employee
9,340 Views
Registered: ‎09-10-2008

Re: zynq linux - dual emacps(gem) problem

Hi Tim,

 

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.

 

Thanks,
John

0 Kudos
Xilinx Employee
Xilinx Employee
9,320 Views
Registered: ‎09-10-2008

Re: zynq linux - dual emacps(gem) problem

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.

 

Thanks.

0 Kudos
Observer tnjames
Observer
9,316 Views
Registered: ‎07-08-2013

Re: zynq linux - dual emacps(gem) problem

Hi John

 

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.

 

Tim

0 Kudos
Xilinx Employee
Xilinx Employee
9,301 Views
Registered: ‎09-10-2008

Re: zynq linux - dual emacps(gem) problem

Hi Tim,

 

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.

 

Thanks

John

0 Kudos
Xilinx Employee
Xilinx Employee
9,297 Views
Registered: ‎03-13-2012

Re: zynq linux - dual emacps(gem) problem

cpufreq, cpuidle and runtime PM are all separated from each other you can enable/disable them independently.

0 Kudos
Visitor punnaia
Visitor
8,888 Views
Registered: ‎07-09-2014

Re: zynq linux - dual emacps(gem) problem

We have a patch implemented for the usecase single mac manages two phys. But, unfortunately we dont have the setup for testing this usecase. could some one try this patch and let us know the feedback for any further enhancements?

0 Kudos
Explorer
Explorer
6,727 Views
Registered: ‎07-09-2012

Re: zynq linux - dual emacps(gem) problem

Hello,

 

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.

 

- Dave

 

 

 

0 Kudos
Contributor
Contributor
6,237 Views
Registered: ‎12-24-2013

Re: zynq linux - dual emacps(gem) problem

Hi, all.

 

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.

0 Kudos
Contributor
Contributor
6,141 Views
Registered: ‎12-24-2013

Re: zynq linux - dual emacps(gem) problem

Please check following site:

https://github.com/Xilinx/linux-xlnx/commit/2c5f2b5845f143faeb6aafd06db745af25adedf4#diff-71add37d9f86798e9c59c37708858558

 

I think xilinx has fixed this issue, yet not released currently.

The patch is applied in master-next branch.

0 Kudos
Scholar trenz-al
Scholar
5,360 Views
Registered: ‎11-09-2013

Re: zynq linux - dual emacps(gem) problem

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.

0 Kudos
Observer hansonyh
Observer
3,974 Views
Registered: ‎01-10-2009

Re: zynq linux - dual emacps(gem) problem

Hi 

/dts-v1/;
/include/ "system-conf.dtsi"
/ {
aliases {

ethernet1 = &gem1;
};
};
&gem0 {
local-mac-address = [00 0a 35 00 c0 12];
phy-handle = <&phy0>;
phy-mode ="rgmii-id";
status = "okay";


mdio {
#address-cells = <1>;
#size-cells = <0>;

phy0:phy@7 {
compatible = "marvell,88e1116r";
device_type = "ethernet-phy";
reg = <7>;
};

 

};
};
&gem1 {
enet-reset = <&gpio0 15 0>;
local-mac-address = [00 0a 35 00 c0 13];
phy-handle = <&phy1>;
phy-mode ="rgmii-id";
status = "okay";

phy1:phy@6 {
compatible = "marvell,88e1116r";
device_type = "ethernet-phy";
reg = <6>;
};
};

0 Kudos
Participant rankeney
Participant
3,907 Views
Registered: ‎11-26-2014

Re: zynq linux - dual emacps(gem) problem

 

0 Kudos
Participant rankeney
Participant
3,891 Views
Registered: ‎11-26-2014

Re: zynq linux - dual emacps(gem) problem

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.

0 Kudos
Visitor dragoner
Visitor
1,716 Views
Registered: ‎08-11-2017

Re: zynq linux - dual emacps(gem) problem

int eth0 :phy-mode=<rgmii-id> ,not <sgmii > ,marvell 88e1510  is rgmii interface.

0 Kudos