[long] Lance on DS5k/200

[long] Lance on DS5k/200

[Jan-Benedict Glaw]

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
[...]

Re: [long] Lance on DS5k/200

[Florian Lohoff]

On Sat, Jul 28, 2001 at 09:41:14PM +0200, Jan-Benedict Glaw wrote:
> 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?)

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

> 	- while kernel's bootp tries to send the packet, only
> 	  buffers [0] to [5] are used. Why are not all 16 buffers
> 	  used?

Split between TX and RX ?

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
     Why is it called "common sense" when nobody seems to have any?

Re: [long] Lance on DS5k/200

[Dave Airlie]

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.


On Sat, 28 Jul 2001, Jan-Benedict Glaw wrote:

> 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
> [...]
>

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

Re: [long] Lance on DS5k/200

[Dave Airlie]

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.


On Sat, 28 Jul 2001, Jan-Benedict Glaw wrote:

> 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
> [...]
>

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

Re: [long] Lance on DS5k/200

[Alan Cox]

> >  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.
> 
> You you facing towards all those Z8530 implementation or only to
> "ours"?

All the 8530 sync support is in my Z85230 driver. Its written so
someone can add async support to it.

Re: [long] Lance on DS5k/200

[Alan Cox]

> >  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.
> 
> You you facing towards all those Z8530 implementation or only to
> "ours"?

All the 8530 sync support is in my Z85230 driver. Its written so
someone can add async support to it.

Re: [long] Lance on DS5k/200

[Maciej W. Rozycki]

On Sun, 29 Jul 2001, Florian Lohoff wrote:

> If its a TC base address all addresses must be below 128*1024 as
> 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: macro@ds2.pg.gda.pl, PGP key available        +

Re: [long] Lance on DS5k/200

[Maciej W. Rozycki]

On Sun, 29 Jul 2001, Dave Airlie wrote:

> 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..

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

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [long] Lance on DS5k/200

[Jan-Benedict Glaw]

On Mon, Jul 30, 2001 at 10:06:45PM +0200, Maciej W. Rozycki wrote:
> On Sun, 29 Jul 2001, Dave Airlie wrote:
> > 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..
> 
>  How about merging it into official sources?  This way your work won't get
> 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?
	

Re: [long] Lance on DS5k/200

[Maciej W. Rozycki]

On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote:

> 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:

 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.

> this will come no earlier that in two weeks or so. I'll first do
> the serial keyboard with dz.c.

 Excellent.

> PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to
>     *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.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [long] Lance on DS5k/200

[Jan-Benedict Glaw]

On Tue, Jul 31, 2001 at 12:45:10AM +0200, Maciej W. Rozycki wrote:
> On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote:
> > PS: Looking at ~23 Am7990 and ~5 Z8530 drivers I think I should go to
> >     *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.

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)

Re: [long] Lance on DS5k/200

[Maciej W. Rozycki]

On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote:

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

 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... 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [long] Lance on DS5k/200

[Thomas Bogendoerfer]

On Tue, Jul 31, 2001 at 12:24:21AM +0200, Jan-Benedict Glaw wrote:
> 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:

> ./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 ]

Re: [long] Lance on DS5k/200

[Geert Uytterhoeven]

On Sat, 28 Jul 2001, Jan-Benedict Glaw wrote:
> 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?)

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)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: [long] Lance on DS5k/200

[Geert Uytterhoeven]

On Tue, 31 Jul 2001, Jan-Benedict Glaw wrote:
> On Mon, Jul 30, 2001 at 10:06:45PM +0200, Maciej W. Rozycki wrote:
> >  How about merging it into official sources?  This way your work won't get
> > 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/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.

    [...]

> I really *hate* to see so many different implementations. That counts
> 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

--
Geert Uytterhoeven ------------- Sony Software Development Center Europe (SDCE)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Voice +32-2-7248626 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium

Re: [long] Lance on DS5k/200

[Dave Airlie]

> 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.

I sent this earlier but attached some large files.. so in case people on
the list didn't get it ..

http://www.skynet.ie/~airlied/mips/dz.c and dec_dz_keyb.c

are my initial attempts at dz keyboard support for DS5000/200, they
required the access.bus keyboard supprt (or at least lk201 stuff)....

just in case the are usefull.. they worked for lowercase, but the shift
state stuff is all wrong... I lost my monitor soon afterwards which
stopped my development.. I think someone else is working on this
maybe Karsten Merker...

Dave.

>
> 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?
>
>

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

Re: [long] Lance on DS5k/200

[Dave Airlie]

> 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.

I sent this earlier but attached some large files.. so in case people on
the list didn't get it ..

http://www.skynet.ie/~airlied/mips/dz.c and dec_dz_keyb.c

are my initial attempts at dz keyboard support for DS5000/200, they
required the access.bus keyboard supprt (or at least lk201 stuff)....

just in case the are usefull.. they worked for lowercase, but the shift
state stuff is all wrong... I lost my monitor soon afterwards which
stopped my development.. I think someone else is working on this
maybe Karsten Merker...

Dave.

>
> 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?
>
>

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