Things to tackle in the MIPS space?

[Aleksandr Rybalko]

On Mon, 12 Sep 2011 14:02:17 -0700
Juli Mallett <jmallett at FreeBSD.org> wrote:

>> On Mon, Sep 12, 2011 at 13:50, Andrew Duane <aduane at 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 at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-mips
>> To unsubscribe, send any mail to
>> "freebsd-mips-unsubscribe at 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 at freebsd.org>