Date: Mon, 12 Sep 2011 14:02:17 -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=-UO8toF6Aci0JLjqF-KPy6%2BSwFUXxgijKSoX8McL5Q=g@mail.gmail.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB74D600193@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AEB74D600064@EMBX01-WF.jnpr.net> <CACVs6=_VFYs6sgjaBP4Ec2dX5k4=MSd=bJmyrWKEOznXxPmUzw@mail.gmail.com> <AC6674AB7BC78549BB231821ABF7A9AEB74D600193@EMBX01-WF.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 12, 2011 at 13:50, Andrew Duane <aduane@juniper.net> wrote:
>> > 2) Ehternet support. Also apparently broken, although I know little
>> > about ENET and PHYs and such. We do=C2=A0have people here who do thoug=
h.
>>
>> Um, what happened to Ethernet support? =C2=A0It worked and worked quite
>> well the last time I touched it. =C2=A0Performance could be better, but
>> improving performance of the Ethernet driver would probably be a
>> pretty nasty way to learn about how Ethernet drivers work. =C2=A0(Namely
>> because it's easy to make the performance much better for a single
>> case and a lot worse for every other one.) =C2=A0You shouldn't need to k=
now
>> 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=E2=80=99t ask. I'll try turning th=
em 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 r=
equirement about that), but I wouldn't mind generalizing it. Much of the co=
de 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. W=
e don't have any PCI busses on our platforms, except some internal stuff. W=
e 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 tr=
ack 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=-UO8toF6Aci0JLjqF-KPy6%2BSwFUXxgijKSoX8McL5Q=g>