Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

[Grant Erickson]

The latest road bump I've encountered on the path to a Linux port for the
PowerPC 403GCX running on IBM's "Oak" evaluation board is getting the
National Semiconductor DP83902AV chip to behave.

The chip on the board works with both the IBM PROM and with TiVo's
2.1.24-based kernel, so I know that the hardware is OK.

Thinking that maybe I had a problem with the Linux 2.3.3x sources, I
overlaid the port onto 2.2.14 and get the same problem. So, it's
definitely something in the 4xx-code or something in my 'oaknet.c' driver.

My driver is pretty much a verbatim copy of all the other 8390-based
drivers. TiVo's 2.1.24 driver doesn't seem much different either.

I DO know for a fact that I can probe and see the device and I know for a
fact that the driver is getting and handling interrupts.

Anyone out there with any experience with 8390-based controllers or
drivers have any insight on where I might start looking to tackle the
below problem? 

The "oaknet.c" code is in the latest 2.3.39 sources; otherwise, I can send
the similar code for 2.2.14 if it'd help. Both rely on the stock 8390.o
module.

I get the following sorts of errors on both 2.2.14 and 2.3.3x:

Linux version 2.2.14 (grant@brule) (gcc version 2.95.2 19991024 (release)) #97 Wed Jan 12 16:52:16 CST 2000
Calibrating delay loop... 9.73 BogoMIPS
Memory: 7124k available (660k kernel code, 372k data, 36k init) [c0000000,c0800000]
Dentry hash table entries: 1024 (order 1, 8k)
Buffer cache hash table entries: 8192 (order 3, 32k)
Page cache hash table entries: 2048 (order 1, 8k)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 8192 bhash 8192)
Starting kswapd v 1.5 
Shoulda called rs_init...
RAM disk driver initialized:  16 RAM disks of 4096K size
loop: registered device at major 7
eth0: National DP83902AV at 08:00:5a:c8:02:b4, found at 0xf4000000, using IRQ 27.
Looking up port of RPC 100003/2 on 192.168.68.90
eth0: timeout waiting for Tx RDC, stat = 0x0
	start address 0x2000, current address 0x2018, count 42
Resetting eth0...
eth0: timeout waiting for Tx RDC, stat = 0x3
	start address 0x2600, current address 0x2612, count 42
Resetting eth0...
eth0: timeout waiting for Tx RDC, stat = 0x3
	start address 0x2000, current address 0x2014, count 42
Resetting eth0...
neighbour table overflow
eth0: timeout waiting for Tx RDC, stat = 0x3
	start address 0x2600, current address 0x2613, count 42
Resetting eth0...
eth0: timeout waiting for Tx RDC, stat = 0x3
	start address 0x2000, current address 0x2012, count 42
Resetting eth0...
eth0: timeout waiting for Tx RDC, stat = 0x3
	start address 0x2600, current address 0x2613, count 42
Resetting eth0...
neighbour table overflow

Stymied,

Grant Erickson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

[Magnus Damm]

If I understand the error messages right is your board waiting to 
send forever. 

I think I've seen that before...

I don't know how the board is organized, but my experience with
ethernet for 8xx is that it's really important to initialize the PHY
correctly.

The PHY on my F(ADS) boards needs to be enabled in a special board
specific register. Then should the PHY be configured with 3 pins,
half/full duplex, collision test and loopback.

I don't know who takes care of PHY setup in you case.
The PHY setup is board specific in our 8xx case anyhow.

Good luck /

magnus

Grant Erickson wrote:
> 
> The latest road bump I've encountered on the path to a Linux port for the
> PowerPC 403GCX running on IBM's "Oak" evaluation board is getting the
> National Semiconductor DP83902AV chip to behave.
> 
> The chip on the board works with both the IBM PROM and with TiVo's
> 2.1.24-based kernel, so I know that the hardware is OK.
> 
> Thinking that maybe I had a problem with the Linux 2.3.3x sources, I
> overlaid the port onto 2.2.14 and get the same problem. So, it's
> definitely something in the 4xx-code or something in my 'oaknet.c' driver.
> 
> My driver is pretty much a verbatim copy of all the other 8390-based
> drivers. TiVo's 2.1.24 driver doesn't seem much different either.
> 
> I DO know for a fact that I can probe and see the device and I know for a
> fact that the driver is getting and handling interrupts.
> 
> Anyone out there with any experience with 8390-based controllers or
> drivers have any insight on where I might start looking to tackle the
> below problem?
> 
> The "oaknet.c" code is in the latest 2.3.39 sources; otherwise, I can send
> the similar code for 2.2.14 if it'd help. Both rely on the stock 8390.o
> module.
> 
> I get the following sorts of errors on both 2.2.14 and 2.3.3x:
> 
> Linux version 2.2.14 (grant@brule) (gcc version 2.95.2 19991024 (release)) #97 Wed Jan 12 16:52:16 CST 2000
> Calibrating delay loop... 9.73 BogoMIPS
> Memory: 7124k available (660k kernel code, 372k data, 36k init) [c0000000,c0800000]
> Dentry hash table entries: 1024 (order 1, 8k)
> Buffer cache hash table entries: 8192 (order 3, 32k)
> Page cache hash table entries: 2048 (order 1, 8k)
> POSIX conformance testing by UNIFIX
> Linux NET4.0 for Linux 2.2
> Based upon Swansea University Computer Society NET3.039
> NET4: Unix domain sockets 1.0 for Linux NET4.0.
> NET4: Linux TCP/IP 1.0 for NET4.0
> IP Protocols: ICMP, UDP, TCP, IGMP
> TCP: Hash tables configured (ehash 8192 bhash 8192)
> Starting kswapd v 1.5
> Shoulda called rs_init...
> RAM disk driver initialized:  16 RAM disks of 4096K size
> loop: registered device at major 7
> eth0: National DP83902AV at 08:00:5a:c8:02:b4, found at 0xf4000000, using IRQ 27.
> Looking up port of RPC 100003/2 on 192.168.68.90
> eth0: timeout waiting for Tx RDC, stat = 0x0
>         start address 0x2000, current address 0x2018, count 42
> Resetting eth0...
> eth0: timeout waiting for Tx RDC, stat = 0x3
>         start address 0x2600, current address 0x2612, count 42
> Resetting eth0...
> eth0: timeout waiting for Tx RDC, stat = 0x3
>         start address 0x2000, current address 0x2014, count 42
> Resetting eth0...
> neighbour table overflow
> eth0: timeout waiting for Tx RDC, stat = 0x3
>         start address 0x2600, current address 0x2613, count 42
> Resetting eth0...
> eth0: timeout waiting for Tx RDC, stat = 0x3
>         start address 0x2000, current address 0x2012, count 42
> Resetting eth0...
> eth0: timeout waiting for Tx RDC, stat = 0x3
>         start address 0x2600, current address 0x2613, count 42
> Resetting eth0...
> neighbour table overflow
> 
> Stymied,
> 
> Grant Erickson

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

[Grant Erickson]

Niklaus (and others),

Thanks again for the insight on the Oak 8390-based Ethernet driver. The
polled register read/write macros did the trick (at least partially so).

I've done the modification fairly cleanly; however, I'm not sure that the
kernel maintainers will accept the attendant changes to 8390.[ch] via the
nic_{i,o}[s]{b,w}[p] macros. We'll see.

The board now at least ARPs through the interface to the NFS server and
the NFS server responds. However, that's as far as it gets at this point
(see below). Any ideas? In the interim, I'm going to try experimenting
with a few more things.

Linux version 2.3.39 (grant@brule) (gcc version 2.95.2 19991024 (release)) #29 Fri Jan 14 11:07:27 CST 2000
On node 0 totalpages: 00000800
zone(0): 2048 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Calibrating delay loop... 9.73 BogoMIPS
Memory: 6664k available (768k kernel code, 560k data, 44k init) [c0000000,c0800000]
Buffer-cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.3
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 512 bind 1024)
Starting kswapd v1.6
Shoulda called rs_init...
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: registered device at major 7
loop: enabling 8 loop devices
eth0: National DP83902AV at 08:00:5a:c8:02:b4, found at 0xf4000000, using IRQ 27.
Looking up port of RPC 100003/2 on 192.168.68.90
Device lo is down.
Device lo is down.
Device lo is down.
Device lo is down.
portmap: server 192.168.68.90 not responding, timed out
Root-NFS: Unable to get nfsd port number from server, using default
Looking up port of RPC 100005/1 on 192.168.68.90
Device lo is down.
Device lo is down.
Device lo is down.

A trace of the network activity:

grant@stcroix% sudo tcpdump -a -e -vv -N host oak
tcpdump: listening on eth0
11:21:20.533481 8:0:5a:c8:2:b4 Broadcast arp 64: arp who-has stcroix tell oak
11:21:20.533481 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:20.533481 8:0:5a:c8:2:b4 0:5:2:3e:b7:3a ip 342: oak.bootpc > stcroix.bootps: xid:0x2 C:oak [|bootp] (ttl 30, id 1)
11:21:20.533481 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 ip 342: stcroix.bootps > oak.bootpc: xid:0x2 C:oak Y:oak S:stcroix [|bootp] (ttl 64, id 28151)
11:21:20.613484 8:0:5a:c8:2:b4 0:5:2:3e:b7:3a ip 70: oak.3909 > stcroix.tftp: 27 RRQ "/tftpboot/vmlinux.img" (ttl 30, id 52224)

[ Whole bunch of oak<--->stcroix UDP transfers of vmlinux.img deleted ]

[ OK...Linux is up and running...now a whole bunch of ARPs ]

11:21:25.533659 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp who-has oak tell stcroix
11:21:26.383689 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:26.383689 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:27.383724 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:27.383724 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:28.383759 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:28.383759 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:31.393866 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:31.393866 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:32.393902 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:32.393902 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:33.393937 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:33.393937 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:41.424221 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:41.424221 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:42.424257 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:42.424257 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a
11:21:43.424292 8:0:5a:c8:2:b4 Broadcast arp 60: arp who-has stcroix tell oak
11:21:43.424292 0:5:2:3e:b7:3a 8:0:5a:c8:2:b4 arp 42: arp reply stcroix is-at 0:5:2:3e:b7:3a

[ ... ]


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

[Grant Erickson]

On Fri, 14 Jan 2000, Niklaus Giger wrote:
> Are you sure that the ethernet interrupt are correclty handled? It
> seems to me that the oak board never answers.

I definitely receive and handle the interrupt. The call chain is as
follows when I chase it with single-step from 0x500.

                  
  0x500 -> do_IRQ -> oak_get_irq -> ppc4xx_pic_get_irq -> IRQ = 27
              |
              `----> ppc_irq_dispatch_handler
                              |
                              `---> ppc4xx_pic_mask_and_ack
                              `---> ei_interrupt
                              `---> ppc4xx_pic_unmask

> Have you ever serviced correctly a interrupt on the PPC403? If you
> have HW-debug possiblity through the JTAG, try to break on external
> interrupt at address 0x500 and step through the interrupt code to
> verify that it works correctly.

Yes, it appears to be working correctly. I haven't dove into the actual
logic of ei_interrupt, however. I'm presuming (perhaps incorrectly) that
the 8390.c code is pretty architecture neutral.

> Other idea: Do you need a byte swapping to set the controller
> TCP/IP-address/ethernet adresses?

That's a possibility. The Ethernet address is OK and can be verified by
looking at the ARP trace I sent (the MAC addresses from the PROM-generated
and Linux-generated ARPs are the same). I don't think* the IP address
should come into play until the Oak controller has grabbed the ARP reply
from the server, right?

Thanks again for the input!

Regards,

Grant


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Help Sought: 8390-Ethernet Troubles on PowerPC 4xx Port

[Paul Gortmaker]

> 
> Niklaus (and others),
> 
> Thanks again for the insight on the Oak 8390-based Ethernet driver. The
> polled register read/write macros did the trick (at least partially so).
> 
> I've done the modification fairly cleanly; however, I'm not sure that the
> kernel maintainers will accept the attendant changes to 8390.[ch] via the
> nic_{i,o}[s]{b,w}[p] macros. We'll see.

Hard to say without seeing it.  Not worth bending over backwards to try
and adapt the current 8390 if it means obfuscating things in the process 
(the EI_SHIFT trickery may lie somehwere in this grey area).  Code 
duplication is no longer considered supreme evil (wrt linux drivers
anyway) 
if it makes life easier.  

> The board now at least ARPs through the interface to the NFS server and
> the NFS server responds. However, that's as far as it gets at this point
> (see below). Any ideas? In the interim, I'm going to try experimenting
> with a few more things.

Sounds like your driver isn't Rx'ing the arp reply properly and handing 
it off to the upper layers where it can get put into the ARP table.
I assume /proc/net/arp isn't showing your NFS server.

What is the scoop on these cards?  At a glance oaknet.c in 2.3.40 looks
pretty much like ne.c but stripped of the PCI crud.

Paul.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/