From owner-freebsd-hackers Sun Sep 22 22:49:46 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA19156 for hackers-outgoing; Sun, 22 Sep 1996 22:49:46 -0700 (PDT) Received: from alpo.whistle.com (s205m1.whistle.com [207.76.205.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA19119 for ; Sun, 22 Sep 1996 22:49:42 -0700 (PDT) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.5/8.7.3) with SMTP id WAA20362; Sun, 22 Sep 1996 22:48:12 -0700 (PDT) Message-ID: <32462434.4A7B7C1D@whistle.com> Date: Sun, 22 Sep 1996 22:46:28 -0700 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: dennis CC: hackers@freebsd.org Subject: Re: VC support, *BSD and atm/frame/isdn References: <199609230411.AAA11548@etinc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk dennis wrote: > > J Elischer writes..... > > >for what I've done so far as an experiment, > >look at: > >ftp://ref.tfs.com/incoming/VC.tar > >I've layerd this onto a stipped down version of a driver > >for the SGS mk50h28 frame chip (hey it ain't released code so don't > >spread that part too much..) it's just an example of how it MIGHT work. > >the VC code only supports rfc1490 but you could add modules to do > >other types just as easily... > >this all assumes however that one if/VC is acceptable.. > > Are you using our card as a platform for the MK5028? No, they had the card built before I was involved.. it's quite low tech and basically has the chip, and a 32K staic ram and a little glue logic. At least on the early version I have here.. the ram may go up and maybe other things may change when going into mass production. e.g the connector. I don't think it's particularly efficient, but it's not expected to be running under very heavy usage in this version. I believe that they went out and did a scan of several providers to see if they could use them but somehow ended up doing it that way. I do know that they had a hard time trying to work out what pinouts to use for connecting a V35 connector to a connector small enough for a back plate, and that they liked your DB25 implimentation. I've scanned the literature but I haven't found an "Official" or even "defacto" standard on how to do this.. the V35 connector is SOO clunky. I've been meaning to ask you... did you find that pinout somewhere, or did you make it up..? > If not, it does > drop in as a replacement for the processor we use, and it might > be interesting to get the code working. We evaluated the MK5028 > but decided to do the frame relay stuff in software ('cause it wasn't that > difficult and gave us more control), and the early versions of the > processor just didnt work, and we couldnt wait for them to fix it. I've got news for you... It's STILL got bugs.. The versions we have send duplicate packets when used with the driver I showed. The only way to not get them is to do LMI processing manually. The next rev doesn't, (we have the emulator for it) but it can't receive correctly all the time (gets IP checksum errors) It might be just thta the extra capacitance in the emulator module throws off the memory timing in our card sometimes. Basically I wrote that driver from scratch after figuring the SGS docs out (they are very poor). The next version of the chip has a "totally raw" mode that makes it act like a standard SDLC(and family) chip with no Frame processing so we hope to be able to use the same chip for frame/non-frame applications without losing the advantage of it doing all the LMI processing on our behalf.. Mind you, the LMI processing aint that much and I think I'll have to do it in S/W anyhow for the frame-over-ISDN interface. (frame-128) as that will of course be using a differnt interface as far as I can see (unless a miracle occurs) That's why I want to do this layered thing.. to be able to slot in a FRAME layer over a sync link and have the same interface as the frame card itself exports. then to be able to slot rfc1490 over that without regard as to whether it's frame or ATM. Theoretically you could do X25 etc. as well, but I have no interest in that personally. > > Nonetheless, people have been asking for source code for our board, > and if you have code for the 5028 then you have most of the work > done..I'm sure there'd be lots of interest from our customer base, > plus an OEM opportunity for yourselves. I think I may be a bit dense here.. I'm not quite sure what you are suggesting.. that we use your boards? that we sell Our bourds incompetition to you? You want to sell our board to people who want source code? that we give away the completed driver? what? I'm not in principle against any of these though some may or may not stand up to scrutiny, but I'm just not sure what you are suggesting.. We are not in the business of selling the cards.. we just want to sell the complete boxes and whatever is the path of least resistance to that goal will prevail I think.. > > Dennis > ---------------------------------------------------------------------------- > Emerging Technologies, Inc. http://www.etinc.com > > Synchronous PC Cards and Routers For Discriminating > Tastes. 56k to T1 and beyond. Frame Relay, PPP, HDLC, > and X.25 for BSD/OS, FreeBSD and LINUX.