From owner-freebsd-mips@FreeBSD.ORG Wed Jan 21 05:48:11 2009 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 41D7A106566C for ; Wed, 21 Jan 2009 05:48:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DB6F68FC13 for ; Wed, 21 Jan 2009 05:48:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n0L5kpi1009118 for ; Tue, 20 Jan 2009 22:46:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 20 Jan 2009 22:47:27 -0700 (MST) Message-Id: <20090120.224727.1884751430.imp@bsdimp.com> To: mips@freebsd.org From: "M. Warner Losh" X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: Minor reorg... 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: Wed, 21 Jan 2009 05:48:11 -0000 Greetings, I'd like to propose a minor reorg of the mips tree. For the moment, not much will change, since many things already come close to conforming to this scheme. I'm presenting it here for interested parties to comment upon. First, if you aren't aware of it, I'd like to draw your attention to the projects/mips svn tree. In the spirit of openness, we're moving the main mips development to that tree. We'll continue with the perforce tree for a few more weeks, I'm guessing, until we're sure we have everything moved into the subversion tree. There's a couple of things that need to be cleaned up before they can migrate from the perforce tree, but all the code I'm aware of that falls into that category should have clean replacements soon. Next, we have a bit of a hodge-podge of naming schemes in mips right now: old new ------------------------------------ adm5120 or infineon alchemy same atheros same idt same malta ? malta ? sentry5 bcm47xx or broadcom plus the usual compile, conf and mips. The last three won't change. As you may have guessed, I'd like to move to having things under mips be organized by vendor, or chip family. Currently all the vendors we have use very closely related families. Of course, broadcom bought sibyte a few years ago, so they have multiple families, hence my wavering between bcm47xx and broadcom for that directory name. I'm not sure that we'd benefit much from a adm5120 rename, but I'd like to be consistent. Before I rearrange the deck chairs, I thought I'd give people a chance to comment. I'd also like to make sure that we have board support separated out from SoC support, as well as a mechanism in place for doing multiple boards in one kernel. I'd also like to abstract out boot loader support a bit, since that's how the system starts and many boot loaders are available over a range of SoCs[*]. But those bigger changes are something that will have to wait for another day. Should I wait until I have a bigger plan? Or should I start moving things around now? [*] I'm thinking a loader/cfe.c, loader/uboot.c, loader/yamon.c, etc which will be responsible for determining what board is present, and jumping that board's init code (likely by calling a probe routine: haven't worked out the details since I wanted to see how well Sam's work on ARM in this area played out). Warner P.S. I'm also thinking of revamping the bus_space so it is a table of pointers, ala ARM, since we're starting to run into mips systems that would be easier if we had such a thing. From owner-freebsd-mips@FreeBSD.ORG Wed Jan 21 14:07:37 2009 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 C350C106577D for ; Wed, 21 Jan 2009 14:07:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 9989C8FC2B for ; Wed, 21 Jan 2009 14:07:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id C6BAC249B3E; Wed, 21 Jan 2009 08:52:06 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 21 Jan 2009 08:52:06 -0500 X-Sasl-enc: Ux0YmVAsjKdOnT+0xy7LnlV9IRiS4yzxu1lJk7ne/fi+ 1232545926 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3FD8F16953; Wed, 21 Jan 2009 08:52:06 -0500 (EST) Message-ID: <49772885.3090405@FreeBSD.org> Date: Wed, 21 Jan 2009 13:52:05 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090120.224727.1884751430.imp@bsdimp.com> In-Reply-To: <20090120.224727.1884751430.imp@bsdimp.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org Subject: Re: Minor reorg... 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: Wed, 21 Jan 2009 14:07:39 -0000 M. Warner Losh wrote: > ... > sentry5 bcm47xx or broadcom > ^^^^^^^ bcm47xx != bcm5365. The 47xx chips have major pipeline bugs which require patched GCC toolchains to address. If my addled brain is in the right fluids, I seem to recall Broadcom got into a bit of a flap because the patches to deal with the 47xx didn't get pushed right back to GCC. So multiple version(s) of the patches exist. Other than that, I believe the backplane stuff in the SoCs are similar, but NOT identical -- I think the bcm47xx memory controller needs a bit of a kick up the arse to work, whereas the bcm5365 based stuff is generally setup by firmware. I think I posted something to list(s) about this in the last 2-3 years.... later BMS