Date: Wed, 8 Sep 1999 15:52:05 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: thorpej@nas.nasa.gov Cc: hackers@freebsd.org Subject: Re: Tulip device driver question Message-ID: <199909081952.PAA08382@skynet.ctr.columbia.edu> In-Reply-To: <199909081845.LAA01909@lestat.nas.nasa.gov> from "Jason Thorpe" at Sep 8, 99 11:45:17 am
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, Jason Thorpe had to walk into mine and say: > > However, the main problem is keeping the chip from zapping memory that it > > doesn't own. Normally I use mbuf cluster buffers in the receive ring, but > > I would only tell the chip that the buffer was 1536 bytes long instead of > > 2048. But again, it seemed like the chip was DMAing much more data than > > it should have been and overruning the whole cluster. Since I needed to > > copy received packets in order to fix up the alignment anyway, I stopped > > using mbuf clusters and instead allocated my own 4K receive buffers and > > told the chip to DMA into those, on the theory that it may have been > > barfing up the entire contents of its FIFO memory which was more than > > 2048 bytes. Sure, most of the time you waste a lot of those 4K blocks, > > but at least when the chip freaks out it doesn't trash any memory that > > you don't know about. > > Um. Ew. Okay. Sigh. > > In NetBSD, we only copy if the system doesn't have __NO_STRICT_ALIGNMENT > (e.g. i386, m68k [we support some PCI m68k boxes], VAX [all those PCI > vaxes, you know!)... I'll have to see what I can do about all of this. Somebody raised the point that the NFS code will copy packets in order to obtain longword alignment for the benefit of XDR decoding. The argument was that since NFS wants the payload aligned, you may as well fix up the alignment in the driver. Of course, at the time this was a bigger issue because the copying in NFS was broken. There aren't that many PCI chipsets that allow byte alignment for receive buffers. The high end cards (Intel, 3Com, Texas Instruments) do, as well as the gigabit ethernet NICs, or at least the ones I have do. The only cheap one that does it is the Sundance ST201, which clones the 3Com XL interface. (D-Link will be using this chip on the DFE-550TX. Sundance is at www.sundanceti.com.) > > My biggest problem with this stupid thing now is trying to get to work > > on the 486/66 that I'm currently using for testing. It has an old Integrated > > Micro Systems PCI bridge and the PNIC seems to have decided not to be > > friends with it: the machine tends to freeze up solid whenever the chip > > does any DMA, including just loading the setup frame. > > It it trying to use Memory-Read-Multiple or Memory-Read-Line? Old (esp. 486) > PCI bridges were known to have problems with those PCI commands. I'm not sure. I got tired of schlepping from my office to the lab to reboot the stupid machine all the time and put it aside for a while. :) > > http://www.freebsd.org/~wpaul/PNIC/pnic.ps.gz > > Excellent! Thank you very much! No problem. > > All of the Winbond cards are essentially the same so the one you have > > should be enough -- mine is from a company called Trendware. The PNIC > > is a bit tougher to deal with because there are a couple of revisions: > > the original LinkSys PNIC cards use the 82c168 and the internal busted > > NWAY support (i.e. no MII transceiver). For these you have to fiddle > > with the GPIO bits to flip the relay on the card (yes, a relay) in order > > Heh... I have a Kingston 21140 board that uses the PCS function to do > 100baseTX, and you hear a relay flip on that board too :-) > > On these PNIC boards which use the external ENDEC / PCS ... I guess you'd > be able to detect which flavor you have (for flipping the GPIO pins) using > the subsystem IDs in PCI configuration space... The PNIC doesn't use the > DEC-format SROM, unfortunately, so just getting CSR6 and CSR12 from the > SROM isn't an option... I have to confess that I've been ignoring the SROM. My usual scheme is to probe for a PHY on the MII bus first, and if I find none, I assume the card uses some other form of media. In the case of the PNIC, you can distinguish the 82c168 from the 82c169 by checking the PCI revision code. I've seen the following: - 0x10: original 82c168 - 0x20: 82c169 used on LinkSys/Matrox PNIC cards with Myson PHY - 0x21: 82c169 used on Netgear FA310-TX rev D1/D2 cards The Netgear cards have chips that say NGM169B (rev D1) or NGM169C (rev D2). The PCI revision has not changed between the B and C chips so I don't know what the difference is. The cards themselves differ in that the Rev D1 boards use a Level One LXT970 PHY while the Rev D2 boards use a Broadcom PHY. > > to select the right media. The trouble is LinkSys doesn't sell them > > anymore: the later cards use the 82c169, and now they've gone to the > > PNIC II. I had some 82c168 cards donated by FreeBSD users. I can part > > with one of them if you can't find one anywhere. As for the Macronix, > > I would appreciate this... I haven't been able to find '168 boards at all. Okay, I just dug one out of my pile (it says Matrox on the back but it's identical to the LinkSys one). Give me an address where I should send it and I'll try to drop it in the mail sometime this week. > > ideally you need one each of the 98713, 98713A and 98715A. The 98713 > > I have a '15A board... I know of a NetBSD user who has a '13 board (he > sent in patches to make it work with the `de' driver initially). Unfortunately I only have one each of the Macronix cards. You can still find some of the 98713 and 98713A cards around though. > Doing the NWAY register stuff as a simulated PHY is a good idea... should > sort-of work for the PNIC, too, and would save duplicating all that logic > that MII code already implements. Depends a bit on how hard it is to fake up the pseudo registers. I'm pretty sure I can do it but I'm not looking forward to it. > > Also, the PNIC II (LC82c115) is actually a Macronix chip with wake > > on lan and only a 128-bit multicast hash table. The LinkSys LNE100TX v2.0 > > card that I have and the sample 98715A card look almost identical. > > ...I'll have to hunt down one of these cards. These are easy to find: the LNE100TX v2.0 is what LinkSys is currently shipping. They come in a blue and orange box, unlike the old one which was mostly white. Any place that was selling the older LNE100TX is probably selling the LNE100TX v2.0 now. You might also be able to hit up Greg Lapolla at LinkSys for a sample board. (I sent you his e-mail address in a separate mail.) > > If you have a 98715A datasheet handy, you can use that as a reference > > when programming this chip; just remember about the smaller hash table. > > I'll stick a copy of my PNIC II datasheet at www.freebsd.org for you > > a little later -- I originally got my copy from LinkSys. > > That's be great... Okay. It's at http://www.freebsd.org/~wpaul/Macronix/PNIC_II.PDF. Note that when you pull this up in a PDF viewer and examine the document properties, it will tell you the document name is "MX9815A." :) > > a board called the Jaton XpressNet what uses the Davicom DM9102. This > > is another chip with a pretty cruddy DMA engine. > > Davicom ... Winbond-like? No, the Davicom DM9102 is a pretty close copy of the tulip: it uses the setup frame mechanism for programming the RX filter. You can find the datasheet at http://www.davicom8.com. They also have a Linux driver up there somewhere (it's kind of gnarly, but then so are most Linux drivers). The DM9102 also has a built-in PHY so there's no ambiguity about the media. Don't confuse this with the DM9101 which is a PHY only. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909081952.PAA08382>