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

Ethernet not working on Zedboard

Former Member

Hi
Linux is booting up ok (i.e. I'm getting a working login promt on the uart port) but I'm having trouble getting ethernet to work on my zedboard (rev D).

I'm using the following sources:
Linux: https://github.com/Xilinx/linux-xlnx.git tag: "xilinx-v2016.1".
U-boot: https://github.com/Xilinx/u-boot-xlnx.git tag: "xilinx-v2016.1".
Vivado: v2015.3.

To compile U-boot I'm using the zynq_zed_defconfig (no modifications) and to build linux I'm using "xilinx_zynq_defconfig" (no modifications).

For u-boot I'm using the embedded default device tree from within the u-boot source tree (as configured by the defconfig file).
For Linux I'm using the default device tree for zed-board: "linux-xlnx/arch/arm/boot/dts/zynq-zed.dts"
For linux I compile the device tree manually by using the xilinx DTC compiler: https://git.kernel.org/pub/scm/utils/dtc/dtc.git

For the FSBL I have a custom vivado project exported to xilinx sdk and using the fsbl sample application project to create and compile the fsbl.

using mkbootimage to create a BOOT.BIN file and booting from the SD card.

The Link led on the zed board, and also on my switch, is lit so there's a valid link between the devices but no ethernet traffic seems to be getting through. Ping returns 100% packet loss.

One clue is that U-boot complains about not finding any ethernet PHY, here's the u-boot log:
------------
Model: Zynq Zed Development Board
Board: Xilinx Zynq
DRAM:  ECC disabled 512 MiB
MMC:   sdhci@e0100000: 0
SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB
*** Warning - bad CRC, using default environment

In:    serial@e0001000
Out:   serial@e0001000
Err:   serial@e0001000
Model: Zynq Zed Development Board
Board: Xilinx Zynq
Net:   ZYNQ GEM: e000b000, phyaddr 0, interface rgmii-id
PHY is not detected
GEM PHY init failed
No ethernet found.
-------------

Linux doesn't seem to complain besides not getting a dhcp lease, here's some relevant lines from the boot log:
-------------
libphy: MACB_mii_bus: probed
macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:01:22)
macb e000b000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
...
Configuring network interfaces... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
udhcpc (v1.23.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, forking to background
-------------

Are there any known zedboard compatibility issues with the "xilinx-v2016.1" tags of the u-boot and linux sources?
I sort of expected this to work out of the box when using the default configs so it's probably me doing something wrong...

  • 0

    I'm starting to suspect that the problem is related to the fsbl.
    If I use the "mw" command in u-boot to step by step initialize the ethernet controller and MIO clock manually (see chapter 16.3.3 in Xilinx doc UG585 Zynq-7000 TRM) then I can read registers from the phy using the "mdio read" command in u-boot and also in the linux boot log the phy is identified as a [Marvell 88E1510] instead of a [Generic PHY].
    Also, linux is now able to detect the link up event!

    Here's the complete command sequence I used i u-boot:
    --------------
    mw 0xf8000008 0xdf0d
    mw 0xf8000740 0x3902
    mw 0xf8000744 0x3902
    mw 0xf8000748 0x3902
    mw 0xf800074c 0x3902
    mw 0xf8000750 0x3902
    mw 0xf8000754 0x3902
    mw 0xf8000758 0x1903
    mw 0xf800075C 0x1903
    mw 0xf8000760 0x1903
    mw 0xf8000764 0x1903
    mw 0xf8000768 0x1903
    mw 0xf800076c 0x1903
    mw 0xf80007d0 0x1280
    mw 0xf80007d4 0x1280
    mw 0xf8000b00 0x0001
    mw 0xf8000140 0x00500801
    mw 0xf8000138 0x0001
    mw 0xf8000004 0x767b
    --------------

    It's not a complete success though, linux still complains  about not being able to generate the correct clock frequency. Here's the relevant part of the linux boot:
    --------------
    libphy: MACB_mii_bus: probed
    macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118 at 0xe000b000 irq 145 (00:0a:35:00:01:22)
    macb e000b000.ethernet eth0: attached PHY driver [Marvell 88E1510] (mii_bus:phy_addr=e000b000.etherne:00, irq=-1)
    ...
    Configuring network interfaces... IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
    udhcpc (v1.23.1) started
    Sending discover...
    Sending discover...
    macb e000b000.ethernet eth0: unable to generate target frequency: 125000000 Hz
    macb e000b000.ethernet eth0: link up (1000/Full)
    IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Sending discover...
    No lease, forking to background
    --------------

    However, if I manually set a static IP address I'm able to ping my computer and also download files (~26MB) using ftpget. The md5sums of the downloaded files are correct so it appears as if it's actually working.. or?

    Shouldn't the FSBL generated by the xsdk be responsible for setting up and initializing all this?

  • 0

    Hi Anders.Marklund,

    I am not sure what could be the source of the problem in this case.  There are likely several possibilities but is difficult to determine which without further investigation.

    Have you tried using the Xilinx official 2016.1 release to see if you are still seeing these Ethernet issues under that release?

    http://www.wiki.xilinx.com/Zynq+2016.1+Release

    If Ethernet works using those files then at least you have a reference point to work against in trying to narrow down which component is giving you trouble (FSBL, U-Boot, devicetree, or Linux kernel).

    Regards,

    -Kevin

  • 0

    Thanks for the tip!
    With the 2016.1 release binaries from the link you provided ethernet works as expected in both u-boot and linux, yay!

    I did a test where I replaced the only the fsbl with our own fsbl (made with vivado 2015.3) and then it stops working with the same symptoms as before, so it appears that it is indeed the fsbl that is the culprit.

    Next I will try to install vivado 2016.1 and import our project and regenerate the fsbl and see if that magically resolves the problem...

  • 0

    Hi Anders.Marklund,

    Thanks for the update, that certainly helps narrow the problem down a bit.

    Are you using the built-in board definitions for ZedBoard within Vivado 2015.3/2016.1?  If not, double check to see that the ENET0 interface is enabled and set to MIO[16:27] and that MDIO is using MIO[52:53] as well.  Also, double check the clock configuration is set to 1000 Mpbs for ENET0 IO Peripheral Clocks.

    Those settings within Vivado get propagated forward to the FSBL via the ps7_init.* files which are derived from the board definition delivered to SDK from Vivado during the hardware export.

    Regards,

    -Kevin

  • 0 in reply to zedhed

    I'm having the same problem.  We have a custom project for a MicroZed board and the FSBL being generated by Vivado 2016.1 SDK doesn't work.  It would be nice if someone with a working FSBL could paste the part of the init that handles the ethernet to compare with my generated code.