From owner-freebsd-ppc@FreeBSD.ORG Tue Oct 31 04:05:35 2006 Return-Path: X-Original-To: freebsd-ppc@freebsd.org Delivered-To: freebsd-ppc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E1CF16A492 for ; Tue, 31 Oct 2006 04:05:35 +0000 (UTC) (envelope-from grehan@freebsd.org) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D75743D46 for ; Tue, 31 Oct 2006 04:05:33 +0000 (GMT) (envelope-from grehan@freebsd.org) Received: from [10.33.24.110] (nat-198-95-226-228.netapp.com [198.95.226.228]) by dommail.onthenet.com.au (MOS 3.5.7-GR) with ESMTP id CGN84219 (AUTH peterg@ptree32.com.au); Tue, 31 Oct 2006 14:05:24 +1000 (EST) Message-ID: <4546CBB7.4040202@freebsd.org> Date: Mon, 30 Oct 2006 20:06:15 -0800 From: Peter Grehan User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8b) Gecko/20051014 MIME-Version: 1.0 To: Rafal Jaworowski References: <4542188D.6010600@semihalf.com> In-Reply-To: <4542188D.6010600@semihalf.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ppc@freebsd.org Subject: Re: PowerPC architecture directory layout X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Oct 2006 04:05:35 -0000 Hi Rafal, > we're in the process of porting FreeBSD 6.1 to the Freescale MPC85555 > embedded PowerPC platform. This is PowerQUICC3 integrated telecom > controller based on the e500 (Book E compliant) core, which is different > in some important aspects from the "traditional" PowerPC family (AIM). Great ! > There are some general issues we identified and we'd like to discuss: > > Current FreeBSD/powerpc port is deeply entangled with OF and Mac > dependencies: when adding support for a new architecture variant one is > faced with sys/powerpc/powerpc which is the low-level stuff, quite often > strictly OF/Mac-oriented. Yep. > Our initial thoughts and approach was splitting out the > existing low-level code into the following hierarchy: > > sys/powerpc/powerpc - files common to all PowerPC variants > sys/powerpc/aim - specific to "traditional" PowerPC specs > (most of present sys/powerpc/powerpc) > sys/powerpc/{e500, others} - specific to e500 or other specs to be > supported I'd like to keep all aim (oea ?)/e500/other-arch processor-specific stuff in the powerpc directory if possible, since I think that there isn't a whole lot there. i/o could go into it's own directory such as the existing powermac directory. What I want to avoid is the confusion of processor type/board type as in netBSD where they are in a flat space under arch. > The problem with current PowerPC port however is OF dependencies, so to > have really clean separation for potential further platforms support the > current port should be also split into strict AIM part (which would be > used by all AIM ports) and strict OF part. Yep, the OF stuff should be carved out and dumped into the ofw directory. > What is your view and recommended route to follow? Can we work together > on redisigning the sys/powerpc layout to make it more extensible when > new platforms are added etc.? My goals would be: - as much runtime customization as possible. The CPU type can be determined very early in the boot sequence and a CPU-specific function table init'd. This would have routines for setting up vectors, context switching, the mmu kobj, cache syncing etc. - it should be mandatory for the bootloader to pass up FreeBSD-style metadata. - a way of describing bus layout would be very useful. Something like the Linux device tree compiler, but BSD licensed :) That way, a platform could supply it's own nexus driver and enumerate buses for the on-chip peripherals that abound in the embedded PPC world. > I believe FreeBSD/ARM folks must have had similar considerations > exercise as they have a number of different variations within ARM > family, maybe we can learn from them somehow? I tend to think that PPC systems are a lot less memory constrained than ARM systems, and as such don't need the same level of compile-time customization. I would hope that there isn't a proliferation of kernel config files for PPC systems - in my utopia, GENERIC would be able to deal with all processor types and board options, and you would only need a custom config to reduce options. later, Peter.