PowerPC architecture directory layout

[Peter Grehan]

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.