Things to tackle in the MIPS space?

[Juli Mallett]

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.