Nios® II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
12421 Discussions

Nios w/MMU + OpenCores 10/100 MAC + DP83848 PHY Issues

Altera_Forum
Honored Contributor II
1,088 Views

Hello All, 

I have recently upgraded my uClinux build to a more recent version that supports the MMU for the Nios II. I have ported most of my previous design to work the the new version. However, I am having issues getting the Ethernet to work with the OpenCores 10/100 MAC controller (v8.03, I believe) I successfully used in my previous firmware designs on this same board. The firmware, aside from SOPC, is largely unmodified from a previous known working design. 

 

I have tried both the 'Opencores (Igor) Emac support' and the 'OpenCores 10/100 Mbps Ethernet MAC support' options in menuconfig. Though I have not selected both at the same time, which I would believe to be an incorrect combination anyway. 

 

In SOPC Builder I have duplicated the way the Ethernet section was configured in my old build. The base SOPC system was configured as per the "Creating a Nios II Design with an MMU" on the NiosWiki site. I have also written drivers to access the "old" custom components that were ported from the previous system and verified that they work. 

 

I can use the 'mii-tool' to communicate with the National DP83848 PHY and it shows the proper link speed/information/status. I believe this is working as it should, which suggests to me that some portions of the MAC controller are operating properly. 

 

On boot, it appears the drivers are being loaded properly based on this: 

oeth-mdio: probed 

oeth_probe: 64 rx, 64 tx buffs 

 

I am able to configure an IP address using 'ifconfig' and the MAC address I have specified in my board's config.c file is being used. 

 

Please note that the MAC vendor IDs have been masked for public display. 

 

The output from 'ifconfig' is as follows: 

eth0 link encap:ethernet hwaddr xx:xx:xx:ad:be:ef 

inet addr:172.16.70.1 bcast:172.16.255.255 mask:255.255.0.0 

up broadcast running 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:2 base address:0x1000 memory:13100000-13142000 

 

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:10 errors:0 dropped:0 overruns:0 frame:0 

tx packets:10 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:0 

rx bytes:1120 (1.0 kib) tx bytes:1120 (1.0 kib) 

 

I have enabled the debug printing in open_eth.c hoping that it would give me some insight, but as far as I can tell, things should be working properly. For example, when I 'ping' to a PC on the network I see the following output from the driver: 

tx 

ipacket: add = d3c28c02 len = 42 

 

ff ff ff ff ff ff xx xx xx ad be ef 08 06 00 01 

08 00 06 04 00 01 00 14 39 ad be ef ac 10 46 01 

00 00 00 00 00 00 ac 10 46 02 

 

I can tell from looking that an ARP just went out from Linux, but nothing ever comes back. 

 

I have also used SignalTap to look at the RX/TX lines to my PHY. I can see that packets come in when pinging from PC to my board, but I never see packets going out when I ping from my board to the PC. Just for clarification, the packets that come in to my board are never registered by Linux as being received. In other words, receive doesn't work either. 

 

Does anyone have experience with this combination of components that might have some helpful suggestions to help me solve my problems? 

 

Warmest regards, 

Jason
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
127 Views

Don't know a thing about it, but the one thing that caught my eye was the hw addr : 

eth0 Link encap:Ethernet HWaddr XX:XX:XX:AD:BE:EF 

 

Are you sure that is correct? looks like a deadbeef to me, so something is unitialized or pointed to the wrong point. Just my thought, sorry can't be more helpful, although might give you somewhere to start. 

 

kevin
Altera_Forum
Honored Contributor II
127 Views

Kevin, 

That is what I have been using as a hard-coded MAC address until I plug in the real MAC address that is grabbed from an EEPROM. I tend to use DEADBEEF, and other Hexadecimal variations, mainly for my own entertainment. Maybe I shouldn't, huh? 

 

Good observation though! 

 

Thanks, 

Jason
Altera_Forum
Honored Contributor II
127 Views

Hi Jason, 

 

i have exact the same Problem.  

Whats the reason for that? Anybody some ideas? 

 

Thanks 

Marco
Altera_Forum
Honored Contributor II
127 Views

Marco, 

Unfortunately, I have yet to figure out where the problem exists. Since I am on a tight schedule I have been forced to go back to my previous working uClinux build. 

 

I intend to revisit the problem when I have more time available, but for now I cannot. 

 

I attempted to use the Triple-Speed Ethernet (TSE) core with some luck. I used the example I found on the old NiosWiki site (updated link: http://www.alterawiki.com/wiki/creating_a_nios_ii_design_with_an_mmu). I configured the TSE core per the example found in the 'Nios II Hardware Reference Design for Linux' SOPC system. You can find the download for the reference design from the previous link. 

 

Good luck! 

 

-Jason
Altera_Forum
Honored Contributor II
127 Views

I experiment a similar problem. 

Received frames have the status bit "InvalidSymbol" set, and thus discared by the driver. 

ethoc doesn't look at this bit, so frame are not discarded. 

open_eth does and throw the frames, it is why linux doesn't receive them. 

The question is: why this status bit is set? 

 

- Fred
Reply