Date: Fri, 28 Oct 2011 16:06:54 +0300 From: Aleksandr Rybalko <ray@freebsd.org> To: Juli Mallett <jmallett@FreeBSD.org>, Andrew Duane <aduane@juniper.net>, "mips@freebsd.org" <mips@freebsd.org> Subject: Re: Things to tackle in the MIPS space? Message-ID: <20111028160654.18d5b04b.ray@freebsd.org> In-Reply-To: <CACVs6=-UO8toF6Aci0JLjqF-KPy6%2BSwFUXxgijKSoX8McL5Q=g@mail.gmail.com> References: <AC6674AB7BC78549BB231821ABF7A9AEB74D600064@EMBX01-WF.jnpr.net> <CACVs6=_VFYs6sgjaBP4Ec2dX5k4=MSd=bJmyrWKEOznXxPmUzw@mail.gmail.com> <AC6674AB7BC78549BB231821ABF7A9AEB74D600193@EMBX01-WF.jnpr.net> <CACVs6=-UO8toF6Aci0JLjqF-KPy6%2BSwFUXxgijKSoX8McL5Q=g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Sep 2011 14:02:17 -0700
Juli Mallett <jmallett@FreeBSD.org> wrote:
>> On Mon, Sep 12, 2011 at 13:50, Andrew Duane <aduane@juniper.net>
>> wrote:
>> >> > 2) Ehternet support. Also apparently broken, although I know
>> >> > little about ENET and PHYs and such. We do have people here who
>> >> > do though.
>> >>
>> >> Um, what happened to Ethernet support? It worked and worked quite
>> >> well the last time I touched it. Performance could be better, but
>> >> improving performance of the Ethernet driver would probably be a
>> >> pretty nasty way to learn about how Ethernet drivers work.
>> >> (Namely because it's easy to make the performance much better
>> >> for a single case and a lot worse for every other one.) You
>> >> shouldn't need to know anything much about how the PHYs work,
>> >> though.
>> >
>> > Someone told me it was broken so I never turned it on. Something
>> > tells me we'll need Ethernet drivers around here, although we
>> > actually have things other than the kernel that use them. Don’t
>> > ask. I'll try turning them on an see how far I get on my blade.
>>
>> I hope it wasn't someone at FreeBSD.org spreading that FUD :)
>>
>> It may be that your board requires some extra configuration in the
>> Simple Executive code. This actually isn't too painful, usually,
>> even on really bizarre boards (although I do have one board that's
>> pretty much a lost cause because of the amount of engineering
>> required and the minimal returns in terms of user interest.)
>>
>> > The cleanup I'm always happy to help in, I have kinda of a "thing"
>> > about messy code.
>>
>> Good! Welcome to FreeBSD/MIPS, we brought over a lot of cruft in
>> borrowing code from sources that were derived from an operating
>> system you've probably never heard of :) If you want to clean up
>> mess that's totally gratuitously-bad and not actually *very* hard to
>> get right, I suggest looking at the exception vector code. If you
>> don't want to try to replace all of that, you could replace it with
>> a simpler variant for mips{32,64}r2 ISAs that uses the exception
>> shadow registers, and enable that optionally on Octeon. Should be a
>> huge gain for exception handling performance.
>>
>> >> It might be worth taking some of that work and turning it into
>> >> /boot/loader for Octeon, which even on systems with U-Boot would
>> >> mean better access to modules, tunables and UFS, and I suspect
>> >> loader would fit in most boards' NAND flash, which would be
>> >> really nice.
>> >
>> > Actually, my bootstrap doesn't use the loader at all (we had a
>> > specific requirement about that), but I wouldn't mind generalizing
>> > it. Much of the code in it was derived from the Cavium SDK, so it
>> > should be usable in FreeBSD, right?
>>
>> A hesitant "right". We'd prefer to keep Cavium-derived code to the
>> Simple Executive if at all possible, especially since could sometimes
>> borrow without realizing from Linux, and then we'd be in a little bit
>> of a mess from using their code. Cavium-derived code from U-Boot or
>> Linux, even if Cavium is not GPLing it themselves, should be treated
>> with extreme caution. I suspect you could just use the Simple
>> Executive for loader, too?
>>
>> > Bootstraps tend to be one of my better areas, and it seems to me
>> > that it was mentioned that we are lacking in that area.
>>
>> Cool!
>>
>> > Uh, oh, I've started running out of excuses not to touch the PCI
>> > stuff. We don't have any PCI busses on our platforms, except some
>> > internal stuff. We put two chips on the bus: a hardware packet
>> > accelerator FPGA, and an IDP processor. Our needs are pretty
>> > modest for that. IIRC though, the FPGA has some debug code that
>> > can function as a sort of PCI bus analyzer, keeping track of the
>> > transactions that come across.
>>
>> Ah, right, I keep forgetting that you don't use PCI at all, either as
>> a host or target :) I have some weird Octeon hardware coming soon
>> where the devices are on a PCI bus, so I'll likely need to bite some
>> of those bullets, or resign myself to using Linux on my local
>> management processor, which seems undesirable.
>> _______________________________________________
>> freebsd-mips@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> To unsubscribe, send any mail to
>> "freebsd-mips-unsubscribe@freebsd.org"
Hi,
I rewrite a bit dotg driver, and now it works on Octeon (at least on
my CN5010). Driver still have many problems, but serve 3G link -
just fine.
Driver available here:
http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx.c
http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx_reg.h
http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx_var.h
http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_octeon.c
NOTE: Please mount filesytems from USB as ReadOnly, because driver still
have problems on ~big writes.
Known problems:
* fail to do BULK OUT with 2k or bigger packets (may corrupt FS)
* SPLIT not implement (Required if used 2.0 HUB and Low or Full speed
device on it)
* Need to implement and Test support for ISOC endpoints
* Device mode not supported
Any comments are welcomed.
WBW
--
Aleksandr Rybalko <ray@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111028160654.18d5b04b.ray>