Things to tackle in the MIPS space?

[Andrew Duane]

> -----Original Message-----
> From: juli at clockworksquid.com [mailto:juli at clockworksquid.com] On
> Behalf Of Juli Mallett
> Sent: Monday, September 12, 2011 3:56 PM
> To: Andrew Duane
> Cc: mips at freebsd.org
> Subject: Re: Things to tackle in the MIPS space?
> 
> On Mon, Sep 12, 2011 at 12:35, Andrew Duane <aduane at juniper.net> wrote:
> > Now that I've pushed a lot of my Octeon startup work (and some
> > general cleanups), I'd like to start moving into more beefy work.
> >
> > There are a couple of TODO list items (and one or two not on the
> > list) that strike my fancy:
> >
> > 1) USB support. The list says "a driver using the simple exec was
> > committed, but". I suspect the "but" it "but it doesn't work.
> 
> The USB driver using the Simple Executive is incompletely-tested.  If
> you were willing to put time into it, I know hps@ is willing to see
> through work to get it going the rest of the way, and I'm sure he
> would love to work with someone who was investing time testing it and
> getting it into better shape.

I could not even make it finish the init routine. Touching one of the registers during config causes a bus error and tips the chip over. I had contacted Cavium about this but got no resolution.

Originally I started tracking down the register config sequence; I've done it before and it's not rocket science. But after a bit it was sidetracking me from more urgent things. I can pick it up again if hps would like to work with me.

> Someone else has talked about porting the DWC OTG USB driver which
> Linux uses to access the on-chip USB, but it didn't sound like their
> work was progressing very seriously.  This may be something you'd like
> to investigate, or perhaps just do an OTG driver for the on-chip USB
> from scratch.  How hard can it be? :)

The DWC OTG driver is .... poorly implemented. OK, it sucks. We have a version of it here at Juniper and it is really unreliable. I think using Cavium's code is probably a safer bet.

> 
> There is a driver for Octeon 2 boards that use ehci, etc., but it
> requires reimplementing a small amount of code that was previously
> derived from Linux, and not committed as a result.  I don't know if
> you are using hardware for which it matters, though.

We currently use 50xx, 52xx, and 56xx chips which don't use ehci as far as I know. Our future holds 6xxx chips though.


> > 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.

> 
> > 3) FDT. This is something I expect to be actively working on in the
> > immediate future. Other than JC's work on XLP, is there any action here?
> > 4) General SoC/Chip/Platform cleanup. This is something I always like
> > working on, although given my new-ness to FreeBSD perhaps not a best choice?
> 
> I think it's a fine starting point, but it's also a place where it's
> easy to do things in a pretty crappy way because they tend to be done
> in pretty crappy ways just about everywhere.  If you want something
> related to this that has a lot of value on Octeon, I'd suggest looking
> at saving and restoring coprocessor registers (similarly to how FPU
> state is managed on amd64, for instance, allowing for lazy context
> switching by disabling CP[n] access and also allowing for kernel to
> save and restore state explicitly so it can use coprocessor functions
> if desired.)  Gonzo and I were working on this for the crypto
> accelerator, which currently has to be run with interrupts disabled
> and thus kind of sucks for non-bulk options, and I believe he has
> largely-complete patches.  Finishing his work would be a couple of
> days work for a real gain.  And then just another couple of days to
> turn that into something which allows the various platforms to
> configure their own auxiliary coprocessors, which I am sure would be
> generally useful.  As part of this, you could probably complete FP
> support, though of course Octeon doesn't have FP (right?)

Some of this I could help out on, as an extra set of hands and eyes, but it would probably be best in a secondary role. The cleanup I'm always happy to help in, I have kinda of a "thing" about messy code.

> 
> > 5) Another Octeon bootstrap. When I initially discussed my
> bootstrap/bootinfo changes, there was some thought about offering up my
> bootstrap. It's kind of specific-purpose, but there are parts that
> could be adapted into a nice embedded Octeon bootstrap platform.
> 
> 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?

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.


> I'd add an item for Octeon which is actually several items, and
> depends what hardware you have available:
> 
> Write drivers for hosting an Octeon board as a PCI device on a FreeBSD
> system.  Write drivers to support running Octeon as a PCI device,
> rather than just host.  Improve/finish PCI/PCIe host support.  This is
> probably just a matter of disentangling how the Linux PCI bus layer
> and a single Linux PCI device driver on Octeon function, as I suspect
> our problem is just that we're not swapping address bits, are
> improperly byte-swapping, are accessing devices at the wrong address,
> are handling DMA wrong, are using the wrong cache coherency attribute
> for device memory, or something else like that that would be trivial
> and obvious if you really dissected a working system.  I've done a
> bunch of work on that in the past, but had to drop my Octeon time
> pretty much entirely, tried to pay someone to finish it, etc., and the
> result is that nothing much has happened this year.

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.


 ...................................
Andrew Duane
Juniper Networks
o   +1 978 589 0551
m  +1 603-770-7088
aduane at juniper.net