cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
17,446 Views
Registered: ‎09-11-2012

zynq linux - dual emacps(gem) problem

 

Hello
I have been applying dual emacps(gem1, gem2) of zynq-7020 on Linux in my custom zynq board
But an error occurred in the kernel boot process
Eth0 was initialized But Eth1 was not initialized successfully
Error message is as follows:

Can you tell me how to fix this problem.

 

 ***********************************************************************************************************************************

## Starting application at 0x00008000 ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0
Linux version 3.3.0-14.2-build1-01491-g42fac65-dirty (hyun@hyun) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-50) ) #6 SMP PREEMPT Tue Sep 25 19:45:19 KST 2012
CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: Xilinx Zynq Platform, model: Xilinx Zynq ZC702
Memory policy: ECC disabled, Data cache writealloc
PERCPU: Embedded 7 pages/cpu @c1489000 s5696 r8192 d14784 u32768
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129920
Kernel command line: console=ttyPS0,115200 root=/dev/ram rw initrd=0x800000,8M
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 512MB = 512MB total
Memory: 506432k/506432k available, 17856k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xe0800000 - 0xff000000   ( 488 MB)
    lowmem  : 0xc0000000 - 0xe0000000   ( 512 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc040294c   (4075 kB)
      .init : 0xc0403000 - 0xc0427640   ( 146 kB)
      .data : 0xc0428000 - 0xc0453820   ( 175 kB)
       .bss : 0xc0453844 - 0xc046da5c   ( 105 kB)
Preemptible hierarchical RCU implementation.
        Verbose stalled-CPUs detection is disabled.
NR_IRQS:128
[SHKIM][drivers/of/irq.c:419-of_irq_init()]111111
[SHKIM][drivers/of/irq.c:422-of_irq_init()]222222
[SHKIM][drivers/of/irq.c:450-of_irq_init()]
[SHKIM][drivers/of/irq.c:461-of_irq_init()]: match->compatible=arm,cortex-a9-gic
[SHKIM]of_irq_init: init arm,cortex-a9-gic @ c1484798, parent   (null)
xlnx,ps7-ttc-1.00.a #0 at 0xe0800000, irq=43
Console: colour dummy device 80x30
Calibrating delay loop... 1332.01 BogoMIPS (lpj=6660096)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
smp_twd: clock not found: -2
Calibrating local timer... 333.49MHz.
hw perfevents: enabled with ARMv7 Cortex-A9 PMU driver, 7 counters available
Setting up static identity map for 0x2ebec8 - 0x2ebefc
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
Brought up 2 CPUs
SMP: Total of 2 processors activated (2664.03 BogoMIPS).
devtmpfs: initialized
NET: Registered protocol family 16
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x410000c8, AUX_CTRL 0x72360000, Cache size: 524288 B
registering platform device 'pl330' id 0
registering platform device 'arm-pmu' id 0
hw-breakpoint: found 5 (+1 reserved) breakpoint and 1 watchpoint registers.
hw-breakpoint: maximum watchpoint size is 4 bytes.
xslcr xslcr.0: at 0xF8000000 mapped to 0xE0808000
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource xttcpss_timer1
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 196608 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
UDP hash table entries: 256 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 256 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Trying to unpack rootfs image as initramfs...
rootfs image is not initramfs (no cpio magic); looks like an initrd
Freeing initrd memory: 8192K
xscugtimer xscugtimer.0: ioremap fe00c200 to e080a200 with size 400
pl330 dev 0 probe success
JFFS2 version 2.2. (NAND) (SUMMARY)  �© 2001-2006 Red Hat, Inc.
msgmni has been set to 1005
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 82) is a xuartps
console [ttyPS0] enabled
xdevcfg f8007000.ps7-dev-cfg: ioremap f8007000 to e085e000 with size 1000
brd: module loaded
loop: module loaded
xqspips e000d000.ps7-qspi: cs1 >= max 1
xqspips e000d000.ps7-qspi: can't create new device for m25p80
xqspips e000d000.ps7-qspi: at 0xE000D000 mapped to 0xE0860000, irq=51
GEM: BASEADDRESS hw: e000b000 virt: e0862000
XEMACPS mii bus: probed
eth0, pdev->id -1, baseaddr 0xe000b000, irq 54
GEM: BASEADDRESS hw: e000c000 virt: e0864000
------------[ cut here ]------------
WARNING: at fs/sysfs/dir.c:482 sysfs_add_one+0x68/0x88()
sysfs: cannot create duplicate filename '/class/mdio_bus/c0199c44'
Modules linked in:
[<c0012928>] (unwind_backtrace+0x0/0xe0) from [<c001e860>] (warn_slowpath_common+0x4c/0x64)
[<c001e860>] (warn_slowpath_common+0x4c/0x64) from [<c001e8f8>] (warn_slowpath_fmt+0x2c/0x3c)
[<c001e8f8>] (warn_slowpath_fmt+0x2c/0x3c) from [<c00dbcfc>] (sysfs_add_one+0x68/0x88)
[<c00dbcfc>] (sysfs_add_one+0x68/0x88) from [<c00dc498>] (sysfs_do_create_link+0x104/0x1f0)
[<c00dc498>] (sysfs_do_create_link+0x104/0x1f0) from [<c0193b00>] (device_add+0x21c/0x590)
[<c0193b00>] (device_add+0x21c/0x590) from [<c01cc630>] (mdiobus_register+0x80/0x160)
[<c01cc630>] (mdiobus_register+0x80/0x160) from [<c024d2a8>] (of_mdiobus_register+0x48/0x1a0)
[<c024d2a8>] (of_mdiobus_register+0x48/0x1a0) from [<c041630c>] (xemacps_probe+0x588/0x7fc)
[<c041630c>] (xemacps_probe+0x588/0x7fc) from [<c0196a6c>] (platform_drv_probe+0x14/0x18)
[<c0196a6c>] (platform_drv_probe+0x14/0x18) from [<c0195b74>] (driver_probe_device+0xc8/0x184)
[<c0195b74>] (driver_probe_device+0xc8/0x184) from [<c0195c90>] (__driver_attach+0x60/0x84)
[<c0195c90>] (__driver_attach+0x60/0x84) from [<c0194744>] (bus_for_each_dev+0x48/0x74)
[<c0194744>] (bus_for_each_dev+0x48/0x74) from [<c0195490>] (bus_add_driver+0x98/0x214)
[<c0195490>] (bus_add_driver+0x98/0x214) from [<c0196168>] (driver_register+0xa0/0x134)
[<c0196168>] (driver_register+0xa0/0x134) from [<c0196d04>] (platform_driver_probe+0x18/0x8c)
[<c0196d04>] (platform_driver_probe+0x18/0x8c) from [<c000858c>] (do_one_initcall+0x90/0x160)
[<c000858c>] (do_one_initcall+0x90/0x160) from [<c0403874>] (kernel_init+0xa4/0x170)
[<c0403874>] (kernel_init+0xa4/0x170) from [<c000dfcc>] (kernel_thread_exit+0x0/0x8)
---[ end trace 1b14d03f9442e7bd ]---
mii_bus c0199c44 failed to register
eth1: error in xemacps_mii_init
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
Xilinx PS USB Device Controller driver (Apr 01, 2011)
mousedev: PS/2 mouse device common for all mice
Linux video capture interface: v2.00
gspca_main: v2.14.0 registered
uvcvideo: Unable to create debugfs directory
usbcore: registered new interface driver uvcvideo
USB Video Class driver (1.1.1)
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
mmc0: Invalid maximum block size, assuming 512 bytes
mmc0: SDHCI controller on e0100000.ps7-sdio [e0100000.ps7-sdio] using ADMA
TCP cubic registered
NET: Registered protocol family 17
VFP support v0.3: implementor 41 architecture 3 part 30 variant 9 rev 4
Registering SWP/SWPB emulation handler
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
RAMDISK: gzip image found at block 0
mmc0: new high speed SDHC card at address e624
mmcblk0: mmc0:e624 SU16G 14.8 GiB (ro)
mmcblk0: p1
EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem) on device 1:0.
devtmpfs: mounted
Freeing init memory: 144K
Starting rcS...
++ Mounting filesystem
++ Setting up mdev
++ Starting telnet daemon
++ Starting http daemon
++ Starting ftp daemon
++ Starting dropbear (ssh) daemon
++ Mounting SD Card at /mnt
rcS Complete
zynq>
zynq> ifconfig eth0 up
GEM: lp->tx_bd ffdfe000 lp->tx_bd_dma 1f8cf000 lp->tx_skb df053000
GEM: lp->rx_bd ffdff000 lp->rx_bd_dma 1fbec000 lp->rx_skb df053400
GEM: MAC 0x00350a00, 0x00002201, 00:0a:35:00:01:22
GEM: phydev defdd000, phydev->phy_id 0x1410e40, phydev->addr 0x0                                    
eth0, phy_addr 0x0, phy_id 0x01410e40
eth0, attach [Marvell 88E1116R] phy driver
zynq>ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:01:22 
          UP BROADCAST 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:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:54 Base address:0xb000

zynq> ifconfig lo up
zynq> ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0A:35:00:01:22 
          UP BROADCAST 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:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:54 Base address:0xb000

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)

zynq> ifconfig eth1 up
ifconfig: SIOCGIFFLAGS: No such device
zynq> ifconfig eth1
ifconfig: eth1: error fetching interface information: Device not found
zynq>

 

************************************************************************************************************

 

And Could you check devicetree file..

 

************************************************************************************************************

/*
* Device Tree Generator version: 1.3
*
* (C) Copyright 2007-2008 Xilinx, Inc.
* (C) Copyright 2007-2009 Michal Simek
*
* Michal SIMEK <monstr@monstr.eu>
*
* 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 the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place, Suite 330, Boston,
* MA 02111-1307 USA
*
* CAUTION: This file is automatically generated by libgen.
* Version: Xilinx EDK 14.2 EDK_P.28xd
*
* XPS project directory: device-tree_bsp_0
*/

/dts-v1/;
/ {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "xlnx,zynq-zc702";
    interrupt-parent = <&gic>;
    model = "Xilinx Zynq ZC702";
    aliases {
        serial0 = &ps7_uart_1;
    } ;
    chosen {
        bootargs = "console=ttyPS0,115200 root=/dev/ram rw initrd=0x800000,8M";
        linux,stdout-path = "/amba@0/uart@E0001000";
    } ;
    cpus {
        #address-cells = <1>;
        #cpus = <0x2>;
        #size-cells = <0>;
        ps7_cortexa9_0: cpu@0 {
            clock-frequency = <666666688>;
            compatible = "xlnx,ps7-cortexa9-1.00.a";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x8000>;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x8000>;
            model = "ps7_cortexa9,1.00.a";
            reg = <0>;
            timebase-frequency = <333333344>;
            xlnx,cpu-1x-clk-freq-hz = <0x69f6bcb>;
            xlnx,cpu-clk-freq-hz = <0x27bc86c0>;
        } ;
        ps7_cortexa9_1: cpu@1 {
            clock-frequency = <666666688>;
            compatible = "xlnx,ps7-cortexa9-1.00.a";
            d-cache-line-size = <0x20>;
            d-cache-size = <0x8000>;
            device_type = "cpu";
            i-cache-line-size = <0x20>;
            i-cache-size = <0x8000>;
            model = "ps7_cortexa9,1.00.a";
            reg = <1>;
            timebase-frequency = <333333344>;
            xlnx,cpu-1x-clk-freq-hz = <0x69f6bcb>;
            xlnx,cpu-clk-freq-hz = <0x27bc86c0>;
        } ;
    } ;
    ps7_ddr_0: memory@0 {
        device_type = "memory";
        reg = < 0x0 0x20000000 >;
    } ;
    ps7_axi_interconnect_0: axi@0 {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "xlnx,ps7-axi-interconnect-1.00.a", "simple-bus";
        ranges ;
        gic: interrupt-controller@f8f01000 {
            #interrupt-cells = < 3 >;
            compatible = "arm,cortex-a9-gic";
            interrupt-controller ;
            reg = < 0xf8f01000 0x1000  >,< 0xf8f00100 0x100  >;
            linux,phandle = <0x1>;
            phandle = <0x1>;
        } ;
        pl310: pl310-controller@f8f02000 {
            arm,data-latency = < 3 2 2 >;
            arm,tag-latency = < 2 2 2 >;
            cache-level = < 2 >;
            cache-unified ;
            compatible = "arm,pl310-cache";
            interrupts = < 0 34 4 >;
            reg = < 0xf8f02000 0x1000 >;
        } ;
        ps7_ddrc_0: ps7-ddrc@f8006000 {
            compatible = "xlnx,ps7-ddrc-1.00.a";
            interrupt-parent = <&gic>;
            reg = < 0xf8006000 0x1000 >;
            xlnx,has-ecc = <0x0>;
        } ;
        ps7_dev_cfg_0: ps7-dev-cfg@f8007000 {
            compatible = "xlnx,ps7-dev-cfg-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 8 0 >;
            reg = < 0xf8007000 0x1000 >;
        } ;
        ps7_ethernet_0: ps7-ethernet0@e000b000 {
            compatible = "xlnx,ps7-ethernet-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 22 0 >;
            phy-handle = <&phy0>;
            reg = < 0xe000b000 0x1000 >;
            xlnx,ptp-enet-clock = <111111115>;
            xlnx,slcr-div0-1000Mbps = <8>;
            xlnx,slcr-div0-100Mbps = <8>;
            xlnx,slcr-div0-10Mbps = <8>;
            xlnx,slcr-div1-1000Mbps = <1>;
            xlnx,slcr-div1-100Mbps = <5>;
            xlnx,slcr-div1-10Mbps = <50>;
            mdio {
                #address-cells = <1>;
                #size-cells = <0>;
                phy0: phy@0 {
                    compatible = "marvell,88e1116r";
                    device_type = "ethernet-phy";
                    reg = <0>;
                } ;
            } ;
        } ;
        ps7_ethernet_1: ps7-ethernet1@e000c000 {
            compatible = "xlnx,ps7-ethernet-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 45 0 >;
            phy-handle = <&phy1>;
            reg = < 0xe000c000 0x1000 >;
            xlnx,ptp-enet-clock = <111111115>;
            xlnx,slcr-div0-1000Mbps = <8>;
            xlnx,slcr-div0-100Mbps = <8>;
            xlnx,slcr-div0-10Mbps = <8>;
            xlnx,slcr-div1-1000Mbps = <1>;
            xlnx,slcr-div1-100Mbps = <5>;
            xlnx,slcr-div1-10Mbps = <50>;
            mdio {
                #address-cells = <1>;
                #size-cells = <0>;
                phy1: phy@1 {
                    compatible = "marvell,88e1116r";
                    device_type = "ethernet-phy";
                    reg = <1>;
                } ;
            } ;
        } ;
        ps7_iop_bus_config_0: ps7-iop-bus-config@e0200000 {
            compatible = "xlnx,ps7-iop-bus-config-1.00.a";
            interrupt-parent = <&gic>;
            reg = < 0xe0200000 0x1000 >;
        } ;
        ps7_qspi_0: ps7-qspi@e000d000 {
            bus-num = <0>;
            compatible = "xlnx,ps7-qspi-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 19 0 >;
            is-dual = <0>;
            num-chip-select = <1>;
            reg = < 0xe000d000 0x1000 >;
            speed-hz = <200000000>;
            xlnx,fb-clk = <0x1>;
            xlnx,qspi-clk-freq-hz = <0xbebc200>;
            xlnx,qspi-mode = <0x0>;
        } ;
        ps7_qspi_linear_0: ps7-qspi-linear@fc000000 {
            compatible = "xlnx,ps7-qspi-linear-1.00.a";
            interrupt-parent = <&gic>;
            reg = < 0xfc000000 0x1000000 >;
            xlnx,qspi-clk-freq-hz = <0xe4e1c0>;
        } ;
        ps7_scutimer_0: ps7-scutimer@f8f00600 {
            clock-frequency = <333333344>;
            compatible = "xlnx,ps7-scutimer-1.00.a";
            interrupt-parent = <&gic>;
            reg = < 0xf8f00600 0x20 >;
        } ;
        ps7_scuwdt_0: ps7-scuwdt@f8f00620 {
            clock-frequency = <333333344>;
            compatible = "xlnx,ps7-scuwdt-1.00.a";
            interrupt-parent = <&gic>;
            reg = < 0xf8f00620 0xe0 >;
        } ;
        ps7_sd_0: ps7-sdio@e0100000 {
            clock-frequency = <125000000>;
            compatible = "xlnx,ps7-sdio-1.00.a", "xlnx,ps7-sdhci-1.00.a", "generic-sdhci";
            interrupt-parent = <&gic>;
            interrupts = < 0 24 0 >;
            reg = < 0xe0100000 0x1000 >;
            xlnx,has-cd = <0x0>;
            xlnx,has-power = <0x0>;
            xlnx,has-wp = <0x0>;
            xlnx,sdio-clk-freq-hz = <0x7735940>;
        } ;
        ps7_ttc_0: ps7-ttc@f8001000 {
            clock-frequency-timer0 = <111111112>;
            clock-frequency-timer1 = <111111112>;
            clock-frequency-timer2 = <111111112>;
            compatible = "xlnx,ps7-ttc-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 10 0  >,< 0 11 0  >,< 0 12 0  >;
            reg = < 0xf8001000 0x1000 >;
        } ;
        ps7_uart_1: serial@e0001000 {
            clock = <50000000>;
            compatible = "xlnx,ps7-uart-1.00.a", "xlnx,xuartps";
            device_type = "serial";
            interrupt-parent = <&gic>;
            interrupts = < 0 50 0 >;
            reg = < 0xe0001000 0x1000 >;
            xlnx,has-modem = <0x0>;
            xlnx,uart-clk-freq-hz = <0x2faf080>;
        } ;
        ps7_wdt_0: ps7-wdt@f8005000 {
            clock-frequency = <111111112>;
            compatible = "xlnx,ps7-wdt-1.00.a";
            interrupt-parent = <&gic>;
            interrupts = < 0 9 0 >;
            reg = < 0xf8005000 0x1000 >;
            xlnx,wdt-clk-freq-hz = <0x69f6bc8>;
        } ;
        xadc: xadc@f8007100 {
            compatible = "xlnx,ps7-xadc-1.00.a";
            interrupts = < 0 7 0 >;
            reg = < 0xf8007100 0x20 >;
        } ;
    } ;
} ;

 

0 Kudos
Reply
47 Replies
Explorer
Explorer
10,142 Views
Registered: ‎07-09-2012

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
Reply
Visitor
Visitor
9,782 Views
Registered: ‎11-07-2013

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
Reply
Observer
Observer
9,750 Views
Registered: ‎07-08-2013

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
Reply
Observer
Observer
9,703 Views
Registered: ‎07-08-2013

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
Reply
Xilinx Employee
Xilinx Employee
9,633 Views
Registered: ‎09-10-2008

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
Reply
Xilinx Employee
Xilinx Employee
9,613 Views
Registered: ‎09-10-2008

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
Reply
Observer
Observer
9,609 Views
Registered: ‎07-08-2013

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
Reply
Xilinx Employee
Xilinx Employee
9,594 Views
Registered: ‎09-10-2008

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
Reply
Xilinx Employee
Xilinx Employee
9,590 Views
Registered: ‎03-13-2012

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

0 Kudos
Reply
Visitor
Visitor
9,181 Views
Registered: ‎07-09-2014

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
Reply
Explorer
Explorer
7,020 Views
Registered: ‎07-09-2012

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
Reply
Contributor
Contributor
6,530 Views
Registered: ‎12-24-2013

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
Reply
Contributor
Contributor
6,434 Views
Registered: ‎12-24-2013

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
Reply
Scholar
Scholar
5,653 Views
Registered: ‎11-09-2013

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
Reply
Observer
Observer
4,267 Views
Registered: ‎01-10-2009

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
Reply
Participant
Participant
4,200 Views
Registered: ‎11-26-2014

 

0 Kudos
Reply
Participant
Participant
4,184 Views
Registered: ‎11-26-2014

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
Reply
Visitor
Visitor
2,009 Views
Registered: ‎08-11-2017

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

0 Kudos
Reply