Date: Mon, 30 Oct 2006 20:06:15 -0800 From: Peter Grehan <grehan@freebsd.org> To: Rafal Jaworowski <raj@semihalf.com> Cc: freebsd-ppc@freebsd.org Subject: Re: PowerPC architecture directory layout Message-ID: <4546CBB7.4040202@freebsd.org> In-Reply-To: <4542188D.6010600@semihalf.com>
index | next in thread | previous in thread | raw e-mail
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.
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4546CBB7.4040202>