Subject: Re: Sbus ethernet cards
To: Don Yuniskis <port-sparc@netbsd.org>
From: David Laight <David.Laight@btinternet.com>
List: port-sparc
Date: 11/26/2001 23:04:34
> >You will see Sun, ICL and Fujitsu parts lurking.
> >It ought to be easy to make any of them work.
> >ICL certainly made cards that are switchable AUI/10base2, switchable
> >AUI/TP and TP only.
> 
> But, no AUI/coax/rj45 cards?  (makes life easy for folks like
> me who can't make up our minds! :>)

Not enough room on the faceplate.....
> 
> Huh?  Oh, the SBUS connectors are (literally) on a single bus
> (perhaps with address decoders mapping each slot to a specific 
> address space?)  And, there are machines that have *two* such busses
> in them?  Are the controllers for the busses clever enough to
> allow activity on both simultaneously

The sbus slots are selected by high order physical addresses on the sbus.
8 address ranges exist, slot 0 is the motherboard i/o, systems typically
have 4 or 5 other slots - probably limited by bus loading and/or the
arbiter.

Yep! A real monster motherboard.  The 2 sbus are bridged separately
of (i think) the mbus - which has the cpu(s) and memory on it.
The mbus is wider that 32bits.

> Ouch!  But can you configure a particular hardware address
> into the controller thru software?  I.e. tell the NIChip
> to ignore the serial eprom interface...?

I don't know of a network adapter where the driver doesn't have to read
the address prom and then write the value into the relevant register(s)
of the ethernet controller.
On some cards getting teh MAC address is the hardest part of the driver!
> 
> >3) It is possible some boards have the DMA+ part - but I 
> >didn't ever see any of them.
> 
> Presumably this is a driver level issue?  Or, is there a significant
> performance win/lose?

I meant the DMA2 here... the DMA2 has a better caching strategy for
misaligned transfers.
> 
> IIRC, the LANCE  only has a small Tx/Rx buffer... less than
> 100 bytes (maybe 64?)  I.e. no internal "packet memory".

True - it also cannot retransmit a frame - eg when there is a collision
without reloading the data from memory.  This means that the first data
fragment must be at least 100 bytes long.
This also slightly scuppers attempts to transmit straight from 'user' buffers,
the headers on the packet won't be this long - even if you carefully let IP
and MAC add their headers in space before the TCP header...

    David