Subject: [long] Lance on DS5k/200

From: Jan-Benedict Glaw <[email-masked]>
Date: Sat, 28 Jul 2001 21:41:14 +0200

Hi!

I'm tryin' to get a DS5000/200 to work. Currently, I see that declance.c
wasn't complete wrt. this system. Problem: ring buffer pointers not
initialized, Oops. I've copied that part from {PMAX_LANCE,ASIC_LANCE},
but that seems not to be enough. So now, the kernel loops infinitive
when trying to send a bootp packet.

Here's what I did:

static int __init dec_lance_init(struct net_device *dev, const int type)
{
[...]
	switch (type) {
[...]
	case PMAD_LANCE:
		slot = search_tc_card("PMAD-AA");
		claim_tc_card(slot);

		dev->mem_start = get_tc_base_addr(slot);
		dev->base_addr = dev->mem_start + 0x100000;
		dev->irq = get_tc_irq_nr(slot);
		esar_base = dev->mem_start + 0x1c0002;
		/*
		 * setup the pointer arrays, this sucks [tm] :-(
		 */
		for (i = 0; i < RX_RING_SIZE; i++) {
			lp->rx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU
						 + 2 * i * RX_BUFF_SIZE);
			printk("lp->rx_buf_ptr_cpu[%d]=%p\n",
					i, lp->rx_buf_ptr_cpu[i]
			);
			lp->rx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC
						     + i * RX_BUFF_SIZE);
			printk("lp->rx_buf_ptr_lnc[%d]=%p\n",
					i, lp->rx_buf_ptr_lnc[i]
			);
		}
		for (i = 0; i < TX_RING_SIZE; i++) {
			lp->tx_buf_ptr_cpu[i] = (char *) (dev->mem_start + BUF_OFFSET_CPU
					+ 2 * RX_RING_SIZE * RX_BUFF_SIZE
						 + 2 * i * TX_BUFF_SIZE);
			printk("lp->tx_buf_ptr_cpu[%d]=%p\n",
					i, lp->tx_buf_ptr_cpu[i]
			);
			lp->tx_buf_ptr_lnc[i] = (char *) (BUF_OFFSET_LNC
					    + RX_RING_SIZE * RX_BUFF_SIZE
						     + i * TX_BUFF_SIZE);
			printk("lp->tx_buf_ptr_lnc[%d]=%p\n",
					i, lp->tx_buf_ptr_lnc[i]
			);
		}

		break;
[...]
}

However, the chip actually does not transmit the frame. Please look
at it because I don't have a clue about the lance chip. Especially,
I see there problems:
	- lp->tx_buf_ptr_lnc[i] and lp->rx_buf_ptr_lnc[i] are
	  quite low addresses. Is this correct? Are they relative
	  to some other address (TC slot address?)
	- while kernel's bootp tries to send the packet, only
	  buffers [0] to [5] are used. Why are not all 16 buffers
	  used?

It would be *very* nice if the people who originally wrote this
driver could help me...

Here's the serial console's output:

>>boot 6/tftp console=ttyS3 root=/dev/nfs ip=bootp rw
1630208+139264+146848
This DECstation is a DS5000/200
Loading R[23]000 MMU routines.
[...]
TURBOchannel rev. 1 at 25.0 MHz (without parity)
    slot 5: DEC      PMAZ-AA  V5.3b   
    slot 6: DEC      PMAD-AA  V5.3a   
[...]
declance.c: v0.008 by Linux Mips DECstation task force
lp->rx_buf_ptr_cpu[0]=bf800240
lp->rx_buf_ptr_lnc[0]=00000120
lp->rx_buf_ptr_cpu[1]=bf800e40
lp->rx_buf_ptr_lnc[1]=00000720
lp->rx_buf_ptr_cpu[2]=bf801a40
lp->rx_buf_ptr_lnc[2]=00000d20
lp->rx_buf_ptr_cpu[3]=bf802640
lp->rx_buf_ptr_lnc[3]=00001320
lp->rx_buf_ptr_cpu[4]=bf803240
lp->rx_buf_ptr_lnc[4]=00001920
lp->rx_buf_ptr_cpu[5]=bf803e40
lp->rx_buf_ptr_lnc[5]=00001f20
lp->rx_buf_ptr_cpu[6]=bf804a40
lp->rx_buf_ptr_lnc[6]=00002520
lp->rx_buf_ptr_cpu[7]=bf805640
lp->rx_buf_ptr_lnc[7]=00002b20
lp->rx_buf_ptr_cpu[8]=bf806240
lp->rx_buf_ptr_lnc[8]=00003120
lp->rx_buf_ptr_cpu[9]=bf806e40
lp->rx_buf_ptr_lnc[9]=00003720
lp->rx_buf_ptr_cpu[10]=bf807a40
lp->rx_buf_ptr_lnc[10]=00003d20
lp->rx_buf_ptr_cpu[11]=bf808640
lp->rx_buf_ptr_lnc[11]=00004320
lp->rx_buf_ptr_cpu[12]=bf809240
lp->rx_buf_ptr_lnc[12]=00004920
lp->rx_buf_ptr_cpu[13]=bf809e40
lp->rx_buf_ptr_lnc[13]=00004f20
lp->rx_buf_ptr_cpu[14]=bf80aa40
lp->rx_buf_ptr_lnc[14]=00005520
lp->rx_buf_ptr_cpu[15]=bf80b640
lp->rx_buf_ptr_lnc[15]=00005b20
lp->tx_buf_ptr_cpu[0]=bf80c240
lp->tx_buf_ptr_lnc[0]=00006120
lp->tx_buf_ptr_cpu[1]=bf80ce40
lp->tx_buf_ptr_lnc[1]=00006720
lp->tx_buf_ptr_cpu[2]=bf80da40
lp->tx_buf_ptr_lnc[2]=00006d20
lp->tx_buf_ptr_cpu[3]=bf80e640
lp->tx_buf_ptr_lnc[3]=00007320
lp->tx_buf_ptr_cpu[4]=bf80f240
lp->tx_buf_ptr_lnc[4]=00007920
lp->tx_buf_ptr_cpu[5]=bf80fe40
lp->tx_buf_ptr_lnc[5]=00007f20
lp->tx_buf_ptr_cpu[6]=bf810a40
lp->tx_buf_ptr_lnc[6]=00008520
lp->tx_buf_ptr_cpu[7]=bf811640
lp->tx_buf_ptr_lnc[7]=00008b20
lp->tx_buf_ptr_cpu[8]=bf812240
lp->tx_buf_ptr_lnc[8]=00009120
lp->tx_buf_ptr_cpu[9]=bf812e40
lp->tx_buf_ptr_lnc[9]=00009720
lp->tx_buf_ptr_cpu[10]=bf813a40
lp->tx_buf_ptr_lnc[10]=00009d20
lp->tx_buf_ptr_cpu[11]=bf814640
lp->tx_buf_ptr_lnc[11]=0000a320
lp->tx_buf_ptr_cpu[12]=bf815240
lp->tx_buf_ptr_lnc[12]=0000a920
lp->tx_buf_ptr_cpu[13]=bf815e40
lp->tx_buf_ptr_lnc[13]=0000af20
lp->tx_buf_ptr_cpu[14]=bf816a40
lp->tx_buf_ptr_lnc[14]=0000b520
lp->tx_buf_ptr_cpu[15]=bf817640
lp->tx_buf_ptr_lnc[15]=0000bb20
eth0: PMAD-AA, addr = 08:00:2b:1c:44:ee, irq = 3
[...]
Sending BOOTP requests .lance_start_xmit:882: entry=0
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=1
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[1]=bf80ce40, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=2
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[2]=bf80da40, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=3
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[3]=bf80e640, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=4
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[4]=bf80f240, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=5
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[5]=bf80fe40, skb->data=8022c402, skblen=590)
 timed out!
IP-Config: Retrying forever (NFS root)...
Sending BOOTP requests .lance_start_xmit:882: entry=0
lance_start_xmit:884: calling cp_to_buf((char *) lp->tx_buf_ptr_cpu[0]=bf80c240, skb->data=8022c402, skblen=590)
.lance_start_xmit:882: entry=1
[...]

---

From: Florian Lohoff <[email-masked]>
Date: Sun, 29 Jul 2001 02:14:00 +0200

> 	  to some other address (TC slot address?)

If its a TC base address all addresses must be below 128*1024 as
a TC Slot IIRC has a 128K Window.

> 	  buffers [0] to [5] are used. Why are not all 16 buffers

Split between TX and RX ?

Flo
-- 
Florian Lohoff                  [email-masked]             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

---

From: Dave Airlie <[email-masked]>
Date: Sun, 29 Jul 2001 14:16:37 +0100 (IST)

You really should read around before hacking :-)

http://www.skynet.ie/~airlied/mips/declance_2_3_48.c

is the declance driver for the DS5000/200, I'm not sure it still works but
it did the last time I looked at it .. the declance.c in the same dir is
for 2.2 kernel.. I must rename them someday..

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / [email-masked]
pam_smb / Linux DecStation / Linux VAX / ILUG person

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 30 Jul 2001 22:04:59 +0200 (MET DST)

> a TC Slot IIRC has a 128K Window.

 Nope, it's system-dependent, with 1MB being the minimum specified (and
4MB being the real minimum implemented, IIRC).  There actually exist TC
boards that make use of more than 1MB of address space.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 30 Jul 2001 22:06:45 +0200 (MET DST)

> for 2.2 kernel.. I must rename them someday..

 How about merging it into official sources?  This way your work won't get
lost and others won't try to reinvent the wheel.

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Tue, 31 Jul 2001 00:24:21 +0200

> lost and others won't try to reinvent the wheel.

Of course. I wouldn't even *try* to do sth other. In fact, I'm looking
around for various specs of various implementations (as seen from
the bus) of the LANCE chip to see if I could manage the job to
unify them all together:

Driver file				      | Mentioned Chip
----------------------------------------------+--------------------
./drivers/net/declance.c
./xxx/declance.c	# as for DS5k/200
./drivers/net/bagetlance.c			none mentioned
./drivers/net/sk_g16.c				Am7990
./drivers/net/ni65.c				ni6510 aka Am7990
./drivers/net/ewk3.c				Am7990
./drivers/net/sk_mca.c				Am7990
./drivers/net/sunlance.c			NCR92c990
	`-> Father of declance.c as I think
./drivers/net/sunhme.c				none mentioned
	`-> *some* cards seem to be compatible?!
./drivers/net/a2065.c				Am7990
./drivers/net/ariadne.c				Am79c960
./drivers/net/atarilance.c			none mentioned
./drivers/net/sunqu.c				"looks like LANCE"
./drivers/net/atari_pamsnet.c			none mentioned
./drivers/net/lance.c				Am7990, Am79c970A
./drivers/net/pcnet32.c				none mentioned
./drivers/net/sgiseeq.c				Seeq8003 (different buffer
						layout for speed)
./drivers/net/am79c961a.c			Am79c961A
./drivers/net/sun3lance.c			none mentioned, but adopted from sunlance.c
./drivers/net/pcmcia/nmclan_cs.c		Am79c90
./drivers/net/ibmlana.c				"start of LANCE"
./drivers/net/7990.c		*** GENERIC ROUTINES!!! ***
./drivers/net/hplance.c				Uses 7990.c!
./drivers/net/mvme147.c				Uses 7990.c!

I really *hate* to see so many different implementations. That counts
to about 21..25 pieces of code, always written for the same thing.
Well, I'll start off in merging in those two declance drivers. But
this will come no earlier that in two weeks or so. I'll first do
the serial keyboard with dz.c.

MfG, JBG
PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to
    *BSD :-) Who will ever attempt to clean up?

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 31 Jul 2001 00:45:10 +0200 (MET DST)

> the bus) of the LANCE chip to see if I could manage the job to

 Yep, that would really be desireable, but there are quirks such as
third-party DMA controllers that must be taken into account when writing
generic chip support functions.  In the DECstation's case the DMA
controller is the I/O ASIC.

 It's probably doable by writing a generic backend and various interfaces
(see e.g. the 8390 driver), but much care must be taken.  And one must
work on the generic tree -- e.g. the Alan's one -- as otherwise changes
will be impossible to test by most of people.

> Well, I'll start off in merging in those two declance drivers. But

 Excellent.

> the serial keyboard with dz.c.

 Excellent.

>     *BSD :-) Who will ever attempt to clean up?

 Z8530 is on my to-do list.  Our driver really sucks: neither DMA (the I/O
ASIC again) nor sychronous mode, just basic asynchronous support.  I'm
going to look at LANCE one day, too, but it's lower on the list.

---

From: Jan-Benedict Glaw <[email-masked]>
Date: Tue, 31 Jul 2001 00:45:56 +0200

> going to look at LANCE one day, too, but it's lower on the list.

You you facing towards all those Z8530 implementation or only to
"ours"?

MfG, JBG (who can't even *believe* that there are *23* LANCE drivers)

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Tue, 31 Jul 2001 01:00:16 +0200 (MET DST)

> You you facing towards all those Z8530 implementation or only to

 I'd like to merge all of them, of course.  Especially as working on a
single driver only might prevent me from seeing certain device-specific
quirks that have to be handled in a non-conflicting way.  For example the
Z8530 application as used by DEC has a few "interesting" details when it
comes to chip's wiring.

 Don't hold your breath, though...

---

From: Thomas Bogendoerfer <[email-masked]>
Date: Tue, 31 Jul 2001 02:32:45 +0200

> ./drivers/net/pcnet32.c				none mentioned

even if it's based on the lance design from AMD (and it support a lance
compatible mode), you won't be able to unify this driver with other lance
drivers since the driver uses the 32bit mode of the pcnet32 chip familiy
79C97[0-8]).

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                 [ Alexander Viro on linux-kernel ]

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 31 Jul 2001 09:03:18 +0200 (MEST)

> 	  to some other address (TC slot address?)

Are these the addresses that link the ring buffers? If yes, they are adresses
from the LANCE's point of view.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
[email-masked] ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

---

From: Geert Uytterhoeven <[email-masked]>
Date: Tue, 31 Jul 2001 09:08:31 +0200 (MEST)

[...]

> ./drivers/net/a2065.c				Am7990

When I wrote this one, I based it on ariadne.ce, but thanks to Jes Sørensen it
should look quite similar to sunlance now.

> ./drivers/net/ariadne.c				Am79c960

The Ariadne is a bit special, because it byteswaps the data bus of the Am79c960
(PC-Net ISA, hence little endian) by hardware so the big endian m68k/PPC Amiga
doesn't have to swap packet data. But that does mean that non-packet data has
to be byteswapped.

    [...]

> to about 21..25 pieces of code, always written for the same thing.

So this quote from my quote database is still valid ;-)

<QUOTE>
There are more Lance drivers than there are architectures
					-- Geert Uytterhoeven on linux-kernel
</QUOTE>

Gr{oetje,eeting}s,

						Geert