Date: Mon, 12 Sep 2011 12:55:31 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Andrew Duane <aduane@juniper.net> Cc: "mips@freebsd.org" <mips@freebsd.org> Subject: Re: Things to tackle in the MIPS space? Message-ID: <CACVs6=_VFYs6sgjaBP4Ec2dX5k4=MSd=bJmyrWKEOznXxPmUzw@mail.gmail.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB74D600064@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AEB74D600064@EMBX01-WF.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 12, 2011 at 12:35, Andrew Duane <aduane@juniper.net> wrote: > Now that I've pushed a lot of my Octeon startup work (and some general cl= eanups), 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) th= at strike my fancy: > > 1) USB support. The list says "a driver using the simple exec was committ= ed, 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? :) 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 =C2=A0have 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 immed= iate 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 wor= king 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/boot= info changes, there was some thought about offering up my bootstrap. It's k= ind of specific-purpose, but there are parts that could be adapted into a n= ice 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=_VFYs6sgjaBP4Ec2dX5k4=MSd=bJmyrWKEOznXxPmUzw>