From owner-freebsd-arm@FreeBSD.ORG Sun Dec 2 14:51:16 2007 Return-Path: Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 26E8D16A417 for ; Sun, 2 Dec 2007 14:51:16 +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 DA9F913C45B for ; Sun, 2 Dec 2007 14:51:15 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.1/8.14.1) with ESMTP id lB2EifBS070170; Sun, 2 Dec 2007 07:44:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 02 Dec 2007 07:48:03 -0700 (MST) Message-Id: <20071202.074803.-1625880187.imp@bsdimp.com> To: raj@semihalf.com From: "M. Warner Losh" In-Reply-To: <4752C2A0.9010604@semihalf.com> References: <20071202140920.GA40640@ci0.org> <20071202.072138.1723236577.imp@bsdimp.com> <4752C2A0.9010604@semihalf.com> 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: freebsd-arm@FreeBSD.ORG Subject: Re: ARM arch subdir cleanups X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2007 14:51:16 -0000 In message: <4752C2A0.9010604@semihalf.com> Rafal Jaworowski writes: : M. Warner Losh wrote: : > : : > : I just committed your patches. Yes, this kind of work is very welcome. : > : > Indeed. I've done some work trying to get obio abstracted out across : > all architectures. : > : : Are your OBIO cleanups available somewhere? Are you going to finish these (so : as not to overlap the work...)? What I've done to date is available in the p4 branch "arm-devel" and are in the form of a set of routines in subr_obio.c. They likely need to be enhanced and generalized a little (I just converted at91 to use them, nothing else). I had hoped to be able to come up with something that could also be merged into RELENG_7 as an optional feature to keep maintenance costs down for things MFC'd. : > The other thing that I'd like to see is a better defined board/cpu : > initialization sequence. Or to make better use of the one that's : > defined now and document it better. I made some bad choices, in : > hindsight, for the at91rm9200 port that are only now becoming : > apparent. : > : : Yes, this is a valid point. As we already talked I keep this in mind while : fleshing out the Orion port, but it'll make more sense for me to return to : such refactoring in a second spin, after we have basic functionality in operation. One thing that might help is better documentation in this area. Had my professional life not taken an unexpected turn recently, I had planned on getting some time to document the conventions and try to move all the arm subports into compliance with that vision. I was then hoping to use that experience to define a cleanup, etc. However, since I'm going to have a different focus professionally for a while, I'm afraid I'll have to leave at least some of the heavy lifting on this to others. My focus will be more MIPS and PowerPC based, but there's a lot of overlap here. Warner