Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

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

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

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Hi Jason,

    i have exact the same Problem.

    Whats the reason for that? Anybody some ideas?

    Thanks

    Marco
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    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