From owner-freebsd-arm@FreeBSD.ORG Sun Dec 2 14:35: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 DE04716A419 for ; Sun, 2 Dec 2007 14:35:16 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by mx1.freebsd.org (Postfix) with ESMTP id 918F613C458 for ; Sun, 2 Dec 2007 14:35:16 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id EA0B41449C; Sun, 2 Dec 2007 15:37:32 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16034-09; Sun, 2 Dec 2007 15:37:31 +0100 (CET) Received: from [83.175.187.132] (pc187-132.ghnet.pl [83.175.187.132]) by mail.semihalf.com (Postfix) with ESMTP id 6741814429; Sun, 2 Dec 2007 15:37:31 +0100 (CET) Message-ID: <4752C2A0.9010604@semihalf.com> Date: Sun, 02 Dec 2007 15:35:12 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: "M. Warner Losh" References: <474FF9BF.8090707@semihalf.com> <20071202140920.GA40640@ci0.org> <20071202.072138.1723236577.imp@bsdimp.com> In-Reply-To: <20071202.072138.1723236577.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com 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:35:16 -0000 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...)? > 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. Rafal