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

[Altera_Forum]

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

[Altera_Forum]

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]

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]

Hi Jason, 

 i have exact the same Problem.  Whats the reason for that? Anybody some ideas?  Thanks Marco

[Altera_Forum]

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]

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