Date: Wed, 25 Jan 2006 09:03:54 +0100 From: Andre Oppermann <andre@freebsd.org> To: pyunyh@gmail.com Cc: current@freebsd.org, net@freebsd.org Subject: Re: Marvell/SysKonnect YukonII source code available Message-ID: <43D730EA.6070105@freebsd.org> In-Reply-To: <20060125015511.GA11296@rndsoft.co.kr> References: <43D5FF19.7090903@freebsd.org> <20060125015511.GA11296@rndsoft.co.kr>
next in thread | previous in thread | raw e-mail | index | archive | help
Pyun YongHyeon wrote: > On Tue, Jan 24, 2006 at 11:19:05AM +0100, Andre Oppermann wrote: > > Marvell/SysKonnect made the source code to the YukonII chips available > > today under a BSD license: > > > > http://people.freebsd.org/~andre/mykbsd60x86-8.12.1.3-src.tgz > > > > I haven't tested the driver yet and I don't know if it available directly > > from the their website already. > > > > Many thanks to Gerald and Frank at SysKonnect for working with us and > > making this possible! > > > Yes, that's great news. > > Is there any chance to get a copy of data sheet for Yukon chips? If you are willing and able to sign a NDA for the 'physical' docs I think so. Using the obtained knowledge in a driver is not longer a problem as pretty much all of the information is available in the BSD licensed OSS driver too. It's just a bit harder to digest w/o the documentation. Ie. now that the driver is OSS there are no more trade secrets in the chip. > I've tried hard to make Rx TCP/UDP checksum offload work but > failed. ATM both Linux and OpenBSD use Rx IP checksum offload only > but this driver enabled Rx checksum offload for TCP/UDP. So I guess > there is somthing not listed in SK-NET Genesis data sheet. :-( Likely. > Quick reading the source shows that this driver has the following > issues. > 1. Incomplete bus_dma(9) support. The driver uses BUS_SPACE_MAXADDR > when it creates DMA tags which means its DMA supports any address > without limitations. However, I'm sure Rx/Tx descriptors should > reside in < 4GB. So the driver wouldn't work on systems with > 4GB > memory. > 2. Since the driver makes use of mbpool(9) it wouldn't work when > bounce buffers are involved. In fact, I think the use of mbpool(9) > is really bad as it lacks bus_dmamap_sync(9) operation. > 3. Lack of ALTQ support. > 4. The driver may not work on big-endian architectures. > 5. The driver may not work on architectures with strict-alignment. Yes, they haven't spent all the time to get up-to-date with FreeBSD. It seems most of their time is spent on OSX and Solaris drivers for new wired and wireless chips. > Btw, new sk(4) is availabe at the following URL. Due to lack of > documentation it doesn't support YukonII yet. > http://people.freebsd.org/~yongari/sk/if_sk.c > http://people.freebsd.org/~yongari/sk/if_skreg.h What's the differences to our current sk(4)? -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43D730EA.6070105>