Date: Mon, 23 Sep 1996 09:57:39 -0400 From: dennis@etinc.com (Dennis) To: Julian Elischer <julian@whistle.com> Cc: hackers@freebsd.org Subject: Re: VC support, *BSD and atm/frame/isdn Message-ID: <199609231357.JAA14656@etinc.com>
next in thread | raw e-mail | index | archive | help
J. Elischer writes... >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? > >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.. I was suggesting that your code might be ported easily to work with our boards, and that we could supply them to you...of course I didnt know that you had your own board. (now you know why we dont supply source...what an easy job you would have porting our software over :-) I suspect that some of the problems that you are having are hardware related to your board (and not the 5028), as the hardware technology is not new, only the microcode. The problem that we had was that the original design was unacceptable (hardware PVC segregation, which they changed at my suggestion to a single stream), plus the LMI was out of spec and didnt work at all in the real world. We'd be happy to supply the hardware (without CPUs if necessary)..what we'd really like is to have a "public" driver for them to appease those that require source. We've been meaning to do it ourselves....... Dennis
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609231357.JAA14656>