Things to tackle in the MIPS space?

Tue Sep 13 11:25:41 UTC 2011

On Mon, 12 Sep 2011 12:55:31 -0700
Juli Mallett <jmallett at FreeBSD.org> wrote:

>> 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.
>> 
>> 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? :)

It's me :)
my DWC OTG driver works fine for 3G modems with USB2.0 interface, but
not for USB1.2(lack of SPLIT transaction support if HUB used and lack
of data to proper setup root port into USB1.2)

I wrote driver using Cavium code and RT3052F(chopped version)
datasheet. But obviously it don't work on Octeon's yet
1. don't support 64 bit DMA
2. don't found what i need to do to activate OTG controller

Patch here http://my.ddteam.net/files/2011-01-17_dotg.patch

>> 
>> 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.
>> 
>> > 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.
>> 
>> > 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?)
>> 
>> > 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.
>> 
>> 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.
>> 
>> Thanks,
>> Juli.
>> _______________________________________________
>> 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"

-- 
Alexandr Rybalko <ray at dlink.ua> 
aka Alex RAY <ray at ddteam.net>