Actions
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 297 subscribers
  • Views 1016 views
  • Users 0 members are here
Related

Zynq PS IP Core Ethernet Doesn't Come Up

Former Member

Hello All,
I'm currently working on the zedboard running and open embedded OS using the latest xilinx provided kernel and devicetree (3.19 and zynq-zed.dtb). I build my firmware using Vivado's block diagram feature and configure the Zynq PS IP core by simply selecting the Zedboard default configurations. What I've found is that using the latest kernel and devicetree I can get ethernet to come up without any issues when I generate my firmware using Vivado 2013.4 (Zynq7 PS v 5.3). However, when I port the design to Vivado 2014.1,2014.2,2014.4 (Zynq7 PS v 5.4) or Vivado 2015.1 (Zynq7 PS v 5.5), the ethernet doesn't come up and cannot be configured at all (statically or with DHCP). It gets a local address, but eth0 is completely bricked. If I configure it with a static IP, it still just gives host unreachable whereas configuring statically works with no problem using the 2013.4 firmware. I've gone through this with a fine toothed comb and to the best of my knowledge, the IP core configurations are the same version to version and the relevant pins are connected properly and configured for the proper voltage levels. After looking at the dmesg outputs after boot I did determine that again using the same kernel/devicetree but different firmware I get:

Works:
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 146 (00:0a:35:00:01:25)
macb e000b000.ethernet eth0: attached PHY driver [Marvell 88E1510] (mii_bus:phy_ addr=e000b000.etherne:00, irq=-1)

Fails:
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 146 (00:0a:35:00:01:25)
macb e000b000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)

I've tried going into the devicetree to explicitly define the Marvell phy driver, but the board still didn't come up. I didn't look at that dmesg output compared to the working version so I'll go back and double check that.

Any thoughts or suggestions on how I might fix/further debug this? I'm pretty stumped at this point.

Thanks,
-Austin

  • 0

    Hi Austin,

     I'm not aware of any problems in particular with a standard Ethernet design on any Zynq devices (Zedboard included) migrating from the old tools to the current versions.   There have been some problems with more complex designs, such as dual-ethernet, but that shouldn't apply here. 

    There is an example Ethernet Performace design posted for Zedboard that uses the 2014.4 tool release, and it works fine.  I decompiled the DTB that is suppled with that, and it gave me the following source for the Ethernet.  Perhaps you can compare this with your device tree entry and see if there is anything that leaps out.  This was built using the xilinx open source Linux, so it should be applicable to your implementation.

    Ron

    eth@e000b000 {
                compatible = "xlnx,ps7-ethernet-1.00.a";
                reg = <0xe000b000 0x1000>;
                interrupts = <0x0 0x16 0x0>;
                interrupt-parent = <0x1>;
                phy-handle = <0x2>;
                xlnx,ptp-enet-clock = <0x69f6bc7>;
                xlnx,slcr-div0-1000Mbps = <0x8>;
                xlnx,slcr-div0-100Mbps = <0x8>;
                xlnx,slcr-div0-10Mbps = <0x8>;
                xlnx,slcr-div1-1000Mbps = <0x1>;
                xlnx,slcr-div1-100Mbps = <0x5>;
                xlnx,slcr-div1-10Mbps = <0x32>;
                #address-cells = <0x1>;
                #size-cells = <0x0>;

                phy@0 {
                    compatible = "marvell,88e1510";
                    device_type = "ethernet-phy";
                    reg = <0x0>;
                    marvell,reg-init = <0x3 0x10 0xff00 0x1e 0x3 0x11 0xfff0 0xa>;
                    linux,phandle = <0x2>;
                    phandle = <0x2>;
                };
            };

  • 0 in reply to Former Member

    I had tried implementing a DTS like that. I tried that again using your example.
    It still didn't work, but that did eliminate the message regarding selecting
    a phy driver, so that does seem to force it to default to the Marvell. It's still
    not starting the ethernet clock. I've had the Ethernet come up with a 2014.2 build
    if I use the project distributed by Analog Devices for their FMCOMMS2 board.
    I've copied their block design into a new project, removed everything except the
    PS7 IP and when I build that cleaned version, it fails in the same way it has been
    failing. I'm certain at this point that my issue has something to do with project
    settings or build environment settings and not devicetree or IP core settings.

  • 0

    I had a bad fsbl.elf or a bad u-boot, but when I switched to the fsbl.elf/u-boot supplied by Analog Devices, the Ethernet works like a charm. I didn't think those could affect the Ethernet, also why just the Ethernet? Too weird, but bottom line got Ethernet and DMA working.

  • 0 in reply to Former Member

    Austin,

      The FSBL sets numerous device registers to set up the Zynq PS, so in general you should always make sure you generate the correct FSBL for a specific design, and not just copy it from another project.  Since the Ethernet is part of the hard-core, I'm not saying another FSBL won't work (obviously the ADI example does), but if you had any special configuration set up in the Vivado design these setting would not be passed on to a "foreign" FSBL.   As for U-boot, it's job is to load the kernel and DTB into DDR and it may pass some kernel arguments to the Linux loader, but I'm not aware of anything that would affect the Ethernet (but if anyone is and can enlighten me, please do).  U-boot itself usually tries to make contact with a DHCP server, so if was not working it could be a clue that the PHY was not operating correctly at U-boot startup, and that points the finger at the hardware design (or FSBL configuration).  

    It would be interesting to know which component was the culprit here.  If you have time, try swapping them out for your original versions one at a time and see if you can isolate the error.

    Glad you got it going.

    Ron

  • 0

    Hi Ron,
    The original FSBL I was using I generated for my hardware using SDK. I did do some more digging and found that in fact the latest u-boot can generate a working build using the "foreign" FSBL. The "native" FSBL I was using was what was causing the failures. I rebuilt the FSBL, which as an aside took forever as my Vivado SDK decided it wanted to go ahead and corrupt itself, but I could still run the build through the command line. The re-generated FSBL also works. I'm not sure why the original FSBL wasn't working. Thanks for the insight, though, it was very helpful in trying to understand why this didn't work.
    -Austin