[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: on board ethernet (Sonic) on Quad's



On Mon, Mar 29, 1999 at 09:05:19AM -0600, Jason H. Reeves wrote:
> 
> |~~>Can anyone shed any light on this?  Thanks

This is getting a FAQ ... short answer: Sonic driver code is in 2.0.36 
and 2.1.130+ kernels. It works fine for me with 2.1.131, I've wasted a lot
of time to port it to 2.0.36 but there's aa cache consistency problem I've
not been able to track down yet. If you can't find a 2.1.131 with working 
Sonic support (remember to unckeck the 'dont disable VBL interrupts' booter
option yadda yadda) I'll try to build a new one (the one I use won't boot on 
030 machines etc.).
 
> 	I have the same problem on my Quadra 610.  I got OpenBSD to work
> on it just fine...which hints that there is code out there to make the
> Sonic work.  Since I'm not a developer type (more of a tester/fiddler

The Sonic driver is shared with the mips port; it was developed for mips and 
ported to m68k in the 2.1.120 or 2.1.131 series. If you'd like to dig into
the BSD and Linux code to try and find out how they solve the cache problems
differently (or what other magic they use), go ahead. I'll probably release 
a new 2.0.36 source diff shortly (watch the linux-mac68k ML for
announcements).

> type, really) I haven't poked around enough to find out 1) where this
> code is, or 2) how to integrate it into the Debian kernel.  Being new to
> the linux world, and even newer to mac 68k linux, I felt it safer to
> stay out of the kernel until I know more. :-)

You don't need to write new code or port the BSD driver, but going over the
existing code would help a lot. The driver magically starts working when 
enough printk() statements are in the interrupt handler so it's either a 
timing issue or a cache issue. Without that, it's initialized fine but
apparently fails to send packets reliably. 

> 	For the people that know....is the code that the OpenBSD folk
> are using to make the Sonic ethernet card work compatible with the
> debian-mac68k kernel?  Or are they relying on the ROMs to get info about
> the card?  What's the story?

Can't answer that; I've never bothered to look more closely at the BSD
source than necessary to detemine the register address base and spacing. And 
to steal the PROM station address read code.

Hope this explains the current problems, and gives you some leads to work
on.

	Michael


Reply to: