at91sam9260 - macb doesn't transmit

This forum is for users of Microchip MPUs and who are interested in using Linux OS.

Moderator: nferre

Posts: 5
Joined: Mon Mar 11, 2013 7:39 pm

at91sam9260 - macb doesn't transmit

Thu Apr 04, 2013 10:44 am

Hi All,

I am hoping to draw on the collective intelligence here to help solve a networking problem. I am working with a board which is based on the at91sam9260ek design. The MAC on the SoC is connected to a KS8993 switch chip to provide connectivity to an ethernet network. From UBoot, I can configure an IP address and boot a kernel via TFTP so all looks well. But once booted into linux, it seems that outbound network traffic doesn't ever reach the network. The utility tcpdump shows that at least the kernel believes it has sent data and I can see traffic from the network. So at least it receives network traffic.

If I connect the board via a cross over cable to my workstation and run wireshark, I don't see anything coming from the board. No arp or anything. But the board sees everything that is sent to it.

The network configuration in linux looks ok to me.

Code: Select all

root@at91sam9260:/# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:14:85:F1:24:14  
          inet addr:  Bcast:  Mask:
          RX packets:457 errors:170 dropped:0 overruns:0 frame:0
          TX packets:239 errors:170 dropped:0 overruns:0 carrier:170
          collisions:0 txqueuelen:1000 
          RX bytes:38860 (37.9 KiB)  TX bytes:10958 (10.7 KiB)
          Interrupt:21 Base address:0x4000 

root@at91sam9260:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    0      0        0 eth0   U     0      0        0 eth0
root@at91sam9260:/# arp -n
IP address       HW type     Flags       HW address            Mask     Device     0x1         0x2         d4:8c:f4:a7:c0:42     *        eth0   0x1         0x2         08:11:b6:95:f4:4c     *        eth0   0x1         0x2         00:1c:84:a3:53:33     *        eth0
I checked to make sure that IP Tables is allowing all outbound traffic.

if I do a simple ping to, here is what TCPDUMP outputs:

Code: Select all

00:11:35.561681 ARP, Request who-has tell, length 28
00:11:35.722708 ARP, Request who-has tell, length 46
00:11:35.722859 ARP, Reply is-at 00:14:85:F1:24:14, length 28
00:11:36.561681 ARP, Request who-has tell, length 28
00:11:37.585442 ARP, Request who-has tell, length 28
00:11:37.722697 ARP, Request who-has tell, length 46
00:11:37.722848 ARP, Reply is-at 00:14:85:F1:24:14, length 28
The build environment I am working with is OpenWRT. I am using their trunk which has kernel 3.3.8 as a basis. I have the board and networking functioning reliably on an older release of OpenWRT which used kernel 2.6.25 albeit with some patches. Initially I tried a vanilla build of OpenWRT (latest trunk) with the GEM macb driver. I then noticed that the source code for the macb driver in the older OpenWRT had some modifications. These patches attach the PHYs from the KS8993 chip to the SoC MAC. I believe this is important because I had to modify UBoot to do the same before it would correctly function with the network.

So with the patches applied, here is what I see on boot on the 3.3.8 kernel.

Code: Select all

[    2.859375] MACB_mii_bus: probed
[    2.859375] macb macb: eth0: Cadence MACB at 0xfffc4000 irq 21 (00:14:85:F1:24:14)
[    2.867187] macb macb: eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=macb-ffffffff:01, irq=-1)
[    2.882812] macb macb: eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=macb-ffffffff:02, irq=-1)
And here is what I see on the older working kernel

Code: Select all

Phy found id 221430
Phy found id 221430
MACB_mii_bus: probed
eth0: Atmel MACB at 0xfffc4000 irq 21 (00:14:85:F1:24:14)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:01, irq=-1)
eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=ffffffff:02, irq=-1)
I can't work out why it works fine in UBoot and kernel 2.6.25 but not in Kernel 3.3.8. I checked to see what UBoot is doing to find out what the kernel isn't doing. So far I don't see anything special. Both Uboot and the 3.3.8 Kernel are set to use MII not RMII. And the board definition for Uboot and the Kernel reset the switch chip in the same way. I am not sure what to check next.

Can anyone suggest to me where I could direct my search next? Google/Forum search hasn't helped me so far.

Return to “LINUX”

Who is online

Users browsing this forum: Baidu [Spider] and 4 guests