List Info

Thread: Re: MI SONIC Ethernet driver for mac68k




Re: MI SONIC Ethernet driver for mac68k
user name
2007-05-31 06:58:41
ivan.carrillogmail.com wrote:

> > Is there "sn0 at obio0" line during
configure before the panic?
> >
> 
> Yes, there's a line that reads:
> 
> sn0 at obio0: integrated SONIC Ethernet adapter
> 
> > Could you also try a stock -current kernel in
NetBSD-daily?
> >
ftp://ftp.NetBSD.org/pub/NetBSD-daily/HEAD/200705270002Z/mac
68k/binary/kernel/
> >
> 
> Tried it and it seems to work fine (seems to boot
faster too!).

Hmm. Maybe the card is not initialized properly and random
RX DMA
might corrupt kernel text memory.

-current if_sn_obio.c has the following code on
initialization:
---
	/*
	 * Kind of kludge this.  Comm-slot cards do not really
	 * have a visible type, as far as I can tell at this time,
	 * so assume that MacOS had it properly configured and use
	 * that configuration.
	 */
	switch (current_mac_model->machineid) {
	case MACH_MACLC575:
	case MACH_MACP580:
	case MACH_MACQ630:
		NIC_PUT(sc, SNR_CR, CR_RST);	wbflush();
		i = NIC_GET(sc, SNR_DCR);
		sc->snr_dcr |= (i & 0xfff0);
		sc->bitmode = (i & DCR_DW) ? 1 : 0;
		break;
	default:
		break;
	}
---
but it doesn't seem to work always on my LC630.
If a kernel is booted from MacOS without any network access
after powercycle the DCR_DW and DCR_EXTBUS (0x8000) are not
set
(then card is initialized into 16 bit mode). But on booting
from
MacOS with any network access (getting a kernel via fetch
etc.)
the DCR is set and the card is initialized properly.

I guess LC575, P(erforma?)580, and Q630 (including LC630)
can only
have the Apple CS network cards and all of them should be 32
bit,
so I've changed my patch to do so. Could you try this one?

http://www.ceres.dti.ne.jp/~tsutsui/netb
sd/mac68k-MI-sonic-20070531.diff
http://www.ceres.dti.ne.jp/~tsutsui
/netbsd/netbsd-mac68k-MI-sonic-20070531.gz
(these also contain fpu changes)

> Network throughput still seems somewhat slow, I'm
getting max at
> around 130KB/s (in os 8.1 I get over 270KB/s).

The MI SONIC driver (sys/dev/ic/dp83932.c) should have
better
performance than -current mac68k homegrown version because
the former does direct DMA from/to mbufs and less memory
copies.
---
Izumi Tsutsui

Re: MI SONIC Ethernet driver for mac68k
user name
2007-05-31 18:32:30
In article <070531205841.M0110699mirage.ceres.dti.ne.jp>
on port-mac68k
I wrote:

> The MI SONIC driver (sys/dev/ic/dp83932.c) should have
better
> performance than -current mac68k homegrown version
because
> the former does direct DMA from/to mbufs and less
memory copies.

...so it seems more proper cache sync ops are required on
DMA xfers.

I've put a new kernel with attached patch (mostle based on
mvme68k) here:
http://www.ceres.dti.ne.jp/~tsutsui
/netbsd/netbsd-mac68k-MI-sonic-20070601.gz

and it actually works even on NFS root.
---
Izumi Tsutsui


Index: arch/m68k/m68k/bus_dma.c
============================================================
=======
RCS file: /cvsroot/src/sys/arch/m68k/m68k/bus_dma.c,v
retrieving revision 1.22
diff -u -r1.22 bus_dma.c
--- arch/m68k/m68k/bus_dma.c	5 Mar 2007 14:31:08 -0000	1.22
+++ arch/m68k/m68k/bus_dma.c	31 May 2007 23:21:38 -0000
 -419,113
+419,108 
     bus_size_t len, int ops)
 {
 #if defined(M68040) || defined(M68060)
+	bus_addr_t p, e, ps, pe;
+	bus_size_t seglen;
 	int i;
 #endif
 
+#if defined(M68020) || defined(M68030)
+	if (cputype == CPU_68020 || cputype == CPU_68030)
+		return;
+#endif
+
+	/* Short-circuit for unsupported `ops' */
+	if ((ops & (BUS_DMASYNC_PREREAD |
BUS_DMASYNC_PREWRITE)) == 0)
+		return;
+
+#if defined(M68040) || defined(M68060)
 	/*
 	 * flush/purge the cache.
-	 *  should probably be fixed to use offset and len
args.
 	 */
+	for (i = 0; i < map->dm_nsegs && len != 0;
i++) {
+		if (map->dm_segs[i].ds_len <= offset) {
+			/* Segment irrelevant - before requested offset */
+			offset -= map->dm_segs[i].ds_len;
+			continue;
+		}
 
-#if defined(M68040) || defined(M68060)
-	if (ops & BUS_DMASYNC_PREWRITE) {
-		for (i = 0; i < map->dm_nsegs; i++) {
-			bus_addr_t p = map->dm_segs[i].ds_addr;
-			bus_addr_t e = p+map->dm_segs[i].ds_len;
-			/* If the pointers are unaligned, it's ok to flush
surrounding cache line */
-			p -= p % 16;
-			if (e % 16) e += 16 - (e % 16);
-#ifdef DIAGNOSTIC
-			if ((p % 16) || (e % 16)) {
-				panic("unaligned address in _bus_dmamap_sync
"
-				    "while flushing. address=0x%08lx, "
-				    "end=0x%08lx, ops=0x%x", p, e, ops);
-			}
-#endif
+		/*
+		 * Now at the first segment to sync; nail
+		 * each segment until we have exhausted the
+		 * length.
+		 */
+		seglen = map->dm_segs[i].ds_len - offset;
+		if (seglen > len)
+			seglen = len;
+
+		ps = map->dm_segs[i].ds_addr + offset;
+		pe = ps + seglen;
+
+		if (ops & BUS_DMASYNC_PREWRITE) {
+			p = ps & ~0xf;
+			e = (pe + 0xf) & ~0xf;
+
+			/* flush cache line */
 			while ((p < e) && (p % PAGE_SIZE)) {
-				DCFL(p);		/* flush cache line */
+				DCFL(p);
 				p += 16;
 			}
+
+			/* flush page */
 			while (p + PAGE_SIZE <= e) {
-				DCFP(p);		/* flush page */
+				DCFP(p);
 				p += PAGE_SIZE;
 			}
+
+			/* flush cache line */
 			while (p < e) {
-				DCFL(p);		/* flush cache line */
+				DCFL(p);
 				p += 16;
 			}
-#ifdef DIAGNOSTIC
-			if (p != e) {
-				panic("overrun in _bus_dmamap_sync "
-				    "while flushing. address=0x%08lx, "
-				    "end=0x%08lx, ops=0x%x", p, e, ops);
-			}
-#endif
 		}
-	}
-#endif /* M68040 || M68060 */
 
-	if (ops & BUS_DMASYNC_PREREAD) {
-		switch (cputype) {
-		default:
-#ifdef M68020
-		case CPU_68020:
-			break;
-#endif
-#ifdef M68030
-		case CPU_68030:
-			break;
-#endif
-#if defined(M68040) || defined(M68060)
-#ifdef M68040
-		case CPU_68040:
-#endif
-#ifdef M68060
-		case CPU_68060:
-#endif
-			for (i = 0; i < map->dm_nsegs; i++) {
-				bus_addr_t p = map->dm_segs[i].ds_addr;
-				bus_addr_t e = p+map->dm_segs[i].ds_len;
-				if (p % 16) {
-					p -= p % 16;
-					DCFL(p);
-				}
-				if (e % 16) {
-					e += 16 - (e % 16);
-					DCFL(e - 16);
-				}
-#ifdef DIAGNOSTIC
-				if ((p % 16) || (e % 16)) {
-					panic("unaligned address in "
-					    "_bus_dmamap_sync while purging."
-					    "address=0x%08lx, end=0x%08lx, "
-					    "ops=0x%x", p, e, ops);
-				}
-#endif
-				while ((p < e) && (p % PAGE_SIZE)) {
-					DCPL(p);	/* purge cache line */
-					p += 16;
-				}
-				while (p + PAGE_SIZE <= e) {
-					DCPP(p);	/* purge page */
-					p += PAGE_SIZE;
-				}
-				while (p < e) {
-					DCPL(p);	/* purge cache line */
-					p += 16;
-				}
-#ifdef DIAGNOSTIC
-				if (p != e) {
-					panic("overrun in _bus_dmamap_sync "
-					    "while purging. address=0x%08lx, "
-					    "end=0x%08lx, ops=0x%x", p, e, ops);
-				}
-#endif
+		/*
+		 * Normally, the `PREREAD' flag instructs us to purge
the
+		 * cache for the specified offset and length. However,
if
+		 * the offset/length is not aligned to a cacheline
boundary,
+		 * we may end up purging some legitimate data from the
+		 * start/end of the cache. In such a case, *flush* the
+		 * cachelines at the start and end of the required
region.
+		 */
+		else if (ops & BUS_DMASYNC_PREREAD) {
+			/* flush cache lines on boundaries */
+			if (ps & 0xf) {
+				DCFL(ps & ~0xf);
+			}
+			if (pe & 0xf) {
+				DCFL(pe & ~0xf);
+			}
+
+			p = (ps + 15) & ~0xf;
+			e = pe & ~0xf;
+
+			/* purge cache line */
+			while ((p < e) && (p % PAGE_SIZE)) {
+				DCPL(p);
+				p += 16;
+			}
+
+			/* purge page */
+			while (p + PAGE_SIZE <= e) {
+				DCPP(p);
+				p += PAGE_SIZE;
+			}
+
+			/* purge cache line */
+			while (p < e) {
+				DCPL(p);
+				p += 16;
 			}
-			break;
-#endif /* M68040 || M68060 */
 		}
+		offset = 0;
+		len -= seglen;
 	}
+#endif
 }
 
 /*
Index: dev/ic/dp83932.c
============================================================
=======
RCS file: /cvsroot/src/sys/dev/ic/dp83932.c,v
retrieving revision 1.14
diff -u -r1.14 dp83932.c
--- dev/ic/dp83932.c	4 Mar 2007 06:01:54 -0000	1.14
+++ dev/ic/dp83932.c	31 May 2007 23:21:38 -0000
 -649,11
+649,15 
 			    BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
 			tda32 = &sc->sc_tda32[i];
 			status = sonic32toh(sc, tda32->tda_status);
+			SONIC_CDTXSYNC32(sc, i,
+			    BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
 		} else {
 			SONIC_CDTXSYNC16(sc, i,
 			    BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
 			tda16 = &sc->sc_tda16[i];
 			status = sonic16toh(sc, tda16->tda_status);
+			SONIC_CDTXSYNC16(sc, i,
+			    BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
 		}
 
 		if ((status &
~(TCR_EXDIS|TCR_CRCI|TCR_POWC|TCR_PINT)) == 0)
 -713,6
+717,8 
 			SONIC_CDRXSYNC32(sc, i,
 			    BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
 			rda32 = &sc->sc_rda32[i];
+			SONIC_CDRXSYNC32(sc, i,
+			    BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
 			if (rda32->rda_inuse != 0)
 				break;
 			status = sonic32toh(sc, rda32->rda_status);
 -724,6
+730,8 
 			SONIC_CDRXSYNC16(sc, i,
 			    BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE);
 			rda16 = &sc->sc_rda16[i];
+			SONIC_CDRXSYNC16(sc, i,
+			    BUS_DMASYNC_PREREAD|BUS_DMASYNC_PREWRITE);
 			if (rda16->rda_inuse != 0)
 				break;
 			status = sonic16toh(sc, rda16->rda_status);

Re: MI SONIC Ethernet driver for mac68k
user name
2007-05-31 21:17:19
On Fri, Jun 01, 2007 at 08:32:30AM +0900, Izumi Tsutsui
wrote:
> ...so it seems more proper cache sync ops are required
on DMA xfers.
> 
> I've put a new kernel with attached patch (mostle based
on mvme68k) here:
> http://www.ceres.dti.ne.jp/~tsutsui
/netbsd/netbsd-mac68k-MI-sonic-20070601.gz
> 
> and it actually works even on NFS root.

Nice work!

Thank you!
-allen

-- 
Allen Briggs  |  http://www.ninthw
onder.com/~briggs/  |  briggsninthwonder.com

Re: MI SONIC Ethernet driver for mac68k
country flaguser name
Germany
2007-06-01 16:00:11
At 8:32 Uhr +0900 1.6.2007, Izumi Tsutsui wrote:
>...so it seems more proper cache sync ops are required
on DMA xfers.
>
>I've put a new kernel with attached patch (mostle based
on mvme68k) here:
>http://www.ceres.dti.ne.jp/~tsutsui
/netbsd/netbsd-mac68k-MI-sonic-20070601.gz
>
>and it actually works even on NFS root.

Works fine on a Quadra 650's obio sn.

Do your patches make the MI sonic driver use DMA there, and
is it supposed
to make a difference? I am getting around 600 KBytes/sec for
ftp transfers
from a ss10 with hme with both the MD and MI drivers.

	hauke


--
"It's never straight up and down"     (DEVO)



Re: MI SONIC Ethernet driver for mac68k
country flaguser name
United States
2007-06-03 16:13:13
On May 31, 2007, at 7:58 AM, Izumi Tsutsui wrote:
> The MI SONIC driver (sys/dev/ic/dp83932.c) should have
better
> performance than -current mac68k homegrown version
because
> the former does direct DMA from/to mbufs and less
memory copies.

This is probably a good thing because using the MI driver's
DMA is  
something you've actually got working. Theoretically,
though, the on- 
board DMA engine on the AV should also be able to DMA to the
mbufs  
directly, assuming they meet the appropriate alignment
constraints, etc.

I would have to imagine there is some good reason to use the
onboard  
DMA over the Sonic's DMA, if only because Apple engineers
would have  
been aware of the Sonic's DMA engine and they could have
saved ASIC  
space on the PSC if they could have relied on the the Sonic
to push  
the data. Why bother with more DMA channels if you don't
need them?

Good work, though!


[1-5]

about | contact  Other archives ( Real Estate discussion Medical topics )