From owner-freebsd-mips@FreeBSD.ORG Mon Sep 12 21:02:38 2011 Return-Path: Delivered-To: mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 839C11065670 for ; Mon, 12 Sep 2011 21:02:38 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 207D08FC1A for ; Mon, 12 Sep 2011 21:02:37 +0000 (UTC) Received: by wyh15 with SMTP id 15so5063613wyh.13 for ; Mon, 12 Sep 2011 14:02:37 -0700 (PDT) Received: by 10.227.24.73 with SMTP id u9mr228731wbb.82.1315861357095; Mon, 12 Sep 2011 14:02:37 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.117.8 with HTTP; Mon, 12 Sep 2011 14:02:17 -0700 (PDT) In-Reply-To: References: From: Juli Mallett Date: Mon, 12 Sep 2011 14:02:17 -0700 X-Google-Sender-Auth: sav40ndFFDIRRWO23L4jWanjEBw Message-ID: To: Andrew Duane Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "mips@freebsd.org" Subject: Re: Things to tackle in the MIPS space? X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 21:02:38 -0000 On Mon, Sep 12, 2011 at 13:50, Andrew Duane 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.