From owner-freebsd-mips@FreeBSD.ORG Fri Oct 28 13:30:24 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 29ACD1065672 for ; Fri, 28 Oct 2011 13:30:24 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id A9AE58FC17 for ; Fri, 28 Oct 2011 13:30:22 +0000 (UTC) Received: from [192.168.99.1] (helo=terran.dlink.ua) by dlink.ua with smtp (Exim 4.63) (envelope-from ) id 1RJm6H-0006U0-Jp; Fri, 28 Oct 2011 16:04:04 +0300 Date: Fri, 28 Oct 2011 16:06:54 +0300 From: Aleksandr Rybalko To: Juli Mallett , Andrew Duane , "mips@freebsd.org" Message-Id: <20111028160654.18d5b04b.ray@freebsd.org> In-Reply-To: References: Organization: FreeBSD Project X-Mailer: Sylpheed 2.7.1 (GTK+ 2.20.1; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: 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: Fri, 28 Oct 2011 13:30:24 -0000 On Mon, 12 Sep 2011 14:02:17 -0700 Juli Mallett wrote: >> 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 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. >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to >> "freebsd-mips-unsubscribe@freebsd.org" Hi, I rewrite a bit dotg driver, and now it works on Octeon (at least on my CN5010). Driver still have many problems, but serve 3G link - just fine. Driver available here: http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx.c http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx_reg.h http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_cn50xx_var.h http://zrouter.org/hg/FreeBSD/head/file/default/head/sys/dev/usb/controller/dotg_octeon.c NOTE: Please mount filesytems from USB as ReadOnly, because driver still have problems on ~big writes. Known problems: * fail to do BULK OUT with 2k or bigger packets (may corrupt FS) * SPLIT not implement (Required if used 2.0 HUB and Low or Full speed device on it) * Need to implement and Test support for ISOC endpoints * Device mode not supported Any comments are welcomed. WBW -- Aleksandr Rybalko