Problem for Linux AXI Ethernet driver with SGMII mode

This topic contains 2 replies, has 2 voices, and was last updated by  hlan 4 months, 3 weeks ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #56042

    hlan
    Member

    Dear Sir or Madam,

    My teaching group is doing our best to improving course series for CS student using Nexys4-DDR with MIPSfpga. We are already having difficulty in running Linux Ethernet driver in our MIPSfpga SOC project with device shown in design_1.pdf and nexys4ddr.dts, and please see attachments. To improve transfer rate, we use a 1000 Mbps expansion board with a chip Marvell 88E1111 connecting to Nexys4-DDR. Our modified Ethernet part design with SGMII mode is similar to the official VC707 BIST Design, and please see attached Ethernet_part.pdf.

    After the Linux OS startup, Ethernet can transmit packets but can’t receive packets. In addition, the ethtool returned the settings for eth0: 10Mb/s and Half Duplex, and the details are reported in test-20170526.txt document. However, the settings for the Marvell 88E1111 indicated 100Mb/s and Full Duplex by the LEDs in the FPGA board.

    According to our understanding of the Linux AXI Ethernet driver for VC707 BIST, it only support the AXI Ethernet Subsystem but not include Marvell 88E1111. In our case, is the 88E1111 regarded as an independent device to be driven in boot stage?

    The complex problem is not only associated with MIPSfpga itself but also with Linux Ethernet drivers. We would appreciate it if someone can provide suggestions or communicate with us.

    Many thanks
    Best wishes,
    Lan Huang

    Attachments:
    You must be logged in to view attached files.
    #56052

    ZubairLK
    Member

    Hi,

    First of all. I commend you on such an ambitious project.

    I would recommend simplifying the design as much as possible and then incrementally adding complexity.
    e.g. Remove the DMA controller if possible. Remove interrupts if possible to run the device in polling mode. Start with the minimum RTL addition needed.

    In this case, we are not entirely sure if the issue is in software or the RTL.
    Hence, debugging this can take a tremendous amount of skill and time.

    To start with, I don’t see how we can be certain that Tx packets are working and Rx packets are not? The Tx count reported by ifconfig might not be working.

    Are Tx packets actually being sent out on the Ethernet wires?
    Ping a target IP address. Check if actual Tx packets are going out on the Ethernet interface.
    This can be debugged in HW by connecting a logic probe at the Tx lines.
    If that is working then good.
    Is the Rx packet from ping coming back? If it is coming back then excellent.
    Then trace the Rx packet back to SGMII lines.
    If the Ethernet IP core is receiving the packet.
    Then excellent. Use openocd. Pause the MIPS core. Check physical registers of the SGMII block and read them to see if the Rx packet is in the Fifo. If it is, then start tracing in software in the kernel.

    I’d recommend a systematic approach and tracing the whole data path from Hardware to RTL to Software and back.

    Regards,
    ZubairLK

    1 user thanked author for this post.
    #56053

    hlan
    Member

    Dear ZubairLK,
    Thank you for your kind help! We will do what you said.

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.