Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Running Quartus 13.0sp1 Triple Speed Ethernet IP on uClinux

Altera_Forum
Honored Contributor II
2,475 Views

Hi, 

 

I have had no luck getting the Ethernet connection working and am hoping someone could provide some guidance. I have a Cyclone V GX development board running uClinux but I would like to enhance it, so I can connect my PC to the board via Ethernet. A cross over cable is being used and the network ip address is within range (board ip addr: 192.168.0.4 and PC ip addr: 192.168.0.1). In the "make menuconfig", the "Altera Tripple Speed Ethernet support" and "Drivers for Marvell PHYs" are selected. When I boot up uClinux, it shows "eth0: Altera TSE MAC at 0xf400400 irq 3/4". Everything looks okay, but when I try to ping from PC to the board, I keep getting destination host unreachable. Attached is a screen capture of both windows. The right window is the PC pinging the board and the left is nios2-terminal running uClinux. "ipconfig -a" shows the correct IP and MAC addresses, but there is no Ethernet connection. I greatly appreciate if anyone can point me in the right direction and let me know what I need to do. 

 

Thanks!
0 Kudos
12 Replies
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

 

I have had no luck getting the Ethernet connection working and am hoping someone could provide some guidance. I have a Cyclone V GX development board running uClinux but I would like to enhance it, so I can connect my PC to the board via Ethernet. A cross over cable is being used and the network ip address is within range (board ip addr: 192.168.0.4 and PC ip addr: 192.168.0.1). In the "make menuconfig", the "Altera Tripple Speed Ethernet support" and "Drivers for Marvell PHYs" are selected. When I boot up uClinux, it shows "eth0: Altera TSE MAC at 0xf400400 irq 3/4". Everything looks okay, but when I try to ping from PC to the board, I keep getting destination host unreachable. Attached is a screen capture of both windows. The right window is the PC pinging the board and the left is nios2-terminal running uClinux. "ipconfig -a" shows the correct IP and MAC addresses, but there is no Ethernet connection. I greatly appreciate if anyone can point me in the right direction and let me know what I need to do. 

 

--- Quote End ---  

 

 

Please try to set the default gateway IP (fake address like 192.168.0.1) and change your PC's IP like 192.168.0.2. If you have some problem yet, please check the packets using 'Wireshark'. 

 

http://www.wireshark.org/ 

 

Kazu
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi Kazu, 

 

Thank you very much for your respond. I updated the PC gateway IP with 192.168.0.1, but fail to update the uClinux gateway. When I executed command "route add default gw 192.168.0.1" in uClinux, it gives me "route: SIOCADDRT: Network is unreachable". I am using the "trunk" branch uClinux ver.3.7 and the latest sopc2dts for device tree. Is the following dts output correct?  

 

tse_mac: ethernet@0x14003200 { 

Compatible ="ALTR,tse-13.0", "ALTR,tse-1.0"; 

reg = < 0x14004000 0x00000400 

0x14003300 0x00000040 

0x14003200 0x00000040 

0x14006000 0x00002000 >; 

reg-names = "control_port", "rx_csr", "tx_csr", "s1"; 

interrupt-partent = < &myNios2 >; 

interrupts = < 3 4 >; 

ALTR, rx-fifo-depth = < 2048 >; 

ALTR, tx-fifo-depth = < 2048 >; 

address-bits = < 48 >; 

max=frame-size = < 1518 >; 

local-mac-address = [ 00 07 ed 21 00 06 ]; 

phy-mode = "rgmii' 

ALTR,mii-id = < 0 >; 

ALTR,phy-addr = < 0 >; //I manually added into the dts. To my knowledge, it doesn't make a difference to have this line or not. 

}; 

 

Thanks, 

 

Yeung
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

 

Thank you very much for your respond. I updated the PC gateway IP with 192.168.0.1, but fail to update the uClinux gateway. When I executed command "route add default gw 192.168.0.1" in uClinux, it gives me "route: SIOCADDRT: Network is unreachable". I am using the "trunk" branch uClinux ver.3.7 and the latest sopc2dts for device tree. Is the following dts output correct?  

 

tse_mac: ethernet@0x14003200 { 

Compatible ="ALTR,tse-13.0", "ALTR,tse-1.0"; 

reg = < 0x14004000 0x00000400 

0x14003300 0x00000040 

0x14003200 0x00000040 

0x14006000 0x00002000 >; 

reg-names = "control_port", "rx_csr", "tx_csr", "s1"; 

interrupt-partent = < &myNios2 >; 

interrupts = < 3 4 >; 

ALTR, rx-fifo-depth = < 2048 >; 

ALTR, tx-fifo-depth = < 2048 >; 

address-bits = < 48 >; 

max=frame-size = < 1518 >; 

local-mac-address = [ 00 07 ed 21 00 06 ]; 

phy-mode = "rgmii' 

ALTR,mii-id = < 0 >; 

ALTR,phy-addr = < 0 >; //I manually added into the dts. To my knowledge, it doesn't make a difference to have this line or not. 

}; 

 

Thanks, 

 

--- Quote End ---  

 

 

In this case, you have your PC and Cyclone V GX board in the same sub-net, so maybe you don't need a default gateway. The ping packets should be sent directly to your board, but before it, your PC must send an 'arp' packet to get your board MAC address. Please check it by 'WireShark' or some other sniffing tools. If your board will not reply to the arp request, it may be a problem of your board or kernel. 

 

Kazu
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

 

I monitored the in/out traffic using Wireshark and it shows there is ARP from PC (ip:192.168.0.2) but no trace of ARP respond from the board (ip:192.168.0.4). I know the board ethernet port works with it's demo "Board Update Portal" test app. You are right! At this point, it could be the Hardware level or the kernel Config error. To begin, I tried signal tap the ethernet interface and very quickly to realize the transmit (enet_tx_en) and receive control (enet_rx_dv) signals stay low constantly. Are both signal supposedly not stay low? Attached is both signaltap and wireshark screen capture. Any help is greatly appreciated. 

 

--- Quote End ---  

 

 

At first, please check the 'link pulse'. Does your PC is linking with your board under the desired speed? And the enet_gtx_clk (125MHz GMII Transmit Clock?) is moving? 

 

Kazu
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi Kazu, 

 

Thank you very much for your time to help out this issue. There is link pulse when the uClinux boot up and the PC indicate connectivity running at 1Gbit. The scope measurement of the enet_gtx_clk signal to the Marvell 88E1111 clock is active and running at 125MHz as expected. In uClinux, I was able to verify the Ethernet activity by executing "ethtool -S eth0". Interestingly, when ping from PC to the development board, uclinux received same amount of data frame was ping by the PC. Does it means the hardware is working but Kernel may not configure correctly? I did follow the direction closely from http://www.alterawiki.com/wiki/ethernet to setup the Kernel, but do not know if there are a few other steps maybe missing for connection between PC and the FPGA. Any advice is greatly appreciated. 

 

Thanks, 

 

Yeung
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

Interestingly, when ping from PC to the development board, uclinux received same amount of data frame was ping by the PC. Does it means the hardware is working but Kernel may not configure correctly?  

--- Quote End ---  

 

 

Of course, you have selected the TCP/IP stack, haven't you ? 

 

Networking support ---> --- Networking support Networking options ---> <*> Packet socket Packet socket: mmapped IO <*> Unix domain sockets < > PF_KEY sockets TCP/IP networking IP: multicasting IP: advanced router IP: kernel level autoconfiguration IP: DHCP support IP: BOOTP support  

 

Kazu (I think this web editor is too stupid. It can't express the indents exactly!)
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi Kazu, 

 

I have enabled these settings except "Packet socket:mmapped IO" which it is no where to be find. Please take a look at attached screen capture (uClinuxNetwork_1.jpg and uClinuxNetwork_2.jpg) for the setting. 

 

In QSYS, I change the clock to TSE IP from 50 MHz to 125 MHz (not a PLL output) to experiment if it makes a different, but the result is the same. 

 

uClinuxNetwork_3 is a screen capture of the tcpdump when I ping from my PC (192.168.0.3) to the board (192.168.0.4). As you can see, the GX board does detected the incoming traffic and reply back. I believe the kernel isn't configure correctly somehow so it responds back with something the PC couldn't understand. There could be a bug in the device driver which I also did a quick check on the "altera_tse.c". The irq handler function does trigger when it is ping from the board to PC or vice versa. Do you know if the uClinux v3.7 have a new patch for the Ethernet? 

 

Thanks for your help again, 

 

Yeung
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

 

As you can see, the GX board does detected the incoming traffic and reply back. I believe the kernel isn't configure correctly somehow so it responds back with something the PC couldn't understand. There could be a bug in the device driver which I also did a quick check on the "altera_tse.c". The irq handler function does trigger when it is ping from the board to PC or vice versa. 

 

--- Quote End ---  

 

 

From the observation, it seems that your kernel wants to respond to the arp request, but the reply packets won't be sent. 

Maybe you have a 'scatter gather DMA' for 'tx', please check whether it is working or not. 

 

Kazu
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

Please excuse my lack of experience using scatter gather DMA, but is there a way to test the SGDMA? I did the scope analyze on the GMII interface and the enet_gtx_clk is running 125MHz but the transmit control signal remains low. In QSYS, the SGDMA transmit interface I have 

CSR -> CPU.data_master 

descriptor_read and descriptor_write -> Onchip Dscriptor_memory.s1 

m_read -> DDR3.avi 

out -> tse_mac.transmit
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

Please excuse my lack of experience using scatter gather DMA, but is there a way to test the SGDMA? I did the scope analyze on the GMII interface and the enet_gtx_clk is running 125MHz but the transmit control signal remains low. In QSYS, the SGDMA transmit interface I have 

CSR -> CPU.data_master 

descriptor_read and descriptor_write -> Onchip Dscriptor_memory.s1 

m_read -> DDR3.avi 

out -> tse_mac.transmit 

--- Quote End ---  

 

 

Please observe the signals around csr, descripter_read and m_read by your SignalTapII. At first, your CPU instructs the start of DMA by using the csr bus, after that the SGDMA read a descriptor and get the command which instructs the transfer region. 

And please not that the SGDMA is using 'physical addresses' not virtual addresses. So you must make the contents of descriptors by physical ones. 

 

Kazu
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi Kazu, 

 

Many thanks for your help. I have resolved the issue. The problem wasn't in the tx scatter gather DMA but the enet_gtx_clk along with timing constraint problem in the SDC. The Marvell 88E1111 gigabit ethernet transceiver requires the following interface signals  

GTX_CLK -> PHY transmit clock (enet_gtx_clk) 

TX_EN -> transmit control signal (enet_tx_en) 

TXD[3:0] -> data transmit bus (enet_tx_d[3:0]) 

RX_CLK -> PHY receive clock (enet_rx_clk) 

RX_DV -> receive control signal ( enet_rx_dv) 

RXD[3:0] -> data receive bus (enet_rx_d[3:0]) 

 

The MAC must hold TX_EN (transmit control signal) low until the MAC has ensured the TX_EN is operating at the same speed as the PHY. However, because of the enet_gtx_clk isn't working properly, which it explain the TX_EN is always low I have mentioned from previous post. The key to my problem is I have a PLL generate frequency (125MHz, 25MHz, and 2.5MHz) to drive the MAC transmit clock and PHY GTX clock, which I though it was a correct thing to do since this is what it's in the board_portal_update example come with the board. However, the key to my solution is the PHY GTX clock require 90 degree phase shift from the MAC transmit clock. Therefore, the PLL should generate two sets of frequency, (125MHz, 25MHz, and 2.5MHz) to drive the MAC transmit clock and then another set with 90 degree phase shift (125MHz, 25MHz, and 2.5MHz) to drive the PHY GTX clock. 

 

I am able to ping from both end but am trying to understand why I needed the 90deg phase shift for it enable to work properly. Does it makes any sense to you? 

 

Yeung
0 Kudos
Altera_Forum
Honored Contributor II
529 Views

Hi, 

 

 

--- Quote Start ---  

 

I am able to ping from both end but am trying to understand why I needed the 90deg phase shift for it enable to work properly. Does it makes any sense to you? 

 

--- Quote End ---  

 

 

I don't know what interface mode (GMII, RGMII, MII) you are using, but about the timing, maybe the next references will help you. 

 

http://www.ieee802.org/3/z/public/presentations/nov1996/aigmitim.pdf 

 

http://www.altera.com/literature/an/an477.pdf 

 

Kazu
0 Kudos
Reply