Flat OF Device Tree for ppc32 [was: Platform bus/ppc sys model...]

Tom Rini trini at kernel.crashing.org
Fri Apr 8 03:49:36 EST 2005

On Thu, Apr 07, 2005 at 12:35:51PM -0500, Jon Loeliger wrote:
> On Thu, 2005-04-07 at 12:20, Tom Rini wrote:
> > Part of the point of this is to move to a defined interface :)
> I've extracted a defined interface for the _current_ bd_t
> structure so far.  I'm telling you, you're not going to
> like it... :-)
> So what do you want to do with it?  Specifically, my tree
> is in this state:
>     - I have made two files, a .c and a .h that contain
>       essentially a grand-union of all of the bd_t and 
>       board_info structure definitions that I could find.
>     - I have introduced shim function definitions that are
>       simple accessor functions to front the common structure
>       definition.

It sounds like a start certainly.

> It is semi gross in that this file contains a plethora of
> #ifdef messes that span multiple PPC32 boards and architectures.
> Whereas these used to be nicely distributed (:-)) they are
> all gathered into one place that clearly demonstrates a 
> few things:
>     - This is wrong and needs to be cleaned up more :-),
>     - Obvious refactoring for common functionality that
>       is NOT board-specific is still needed,
>     - There are 51 unique fields in all the bd_t defs.

The vauge idea was that we would contruct the flattened tree, somehow
along the lines of
cat totally_common.txt > tree.txt
cat cpu_specific.txt >> tree.txt
cat board_specific.txt >> tree.txt
... autogen a header, or whatever ...

But basically yes, we should and must refactor things a bit so that,
ideally, a new 440GX-based platform would just need to supply its own
board_specific.txt (or whatever) and get the rest of the truely common
bits easily.

And ideally, a lot of the generation code can be shared between

> I am currently proving that various platforms still build.
> I'm not going to be able to run-test any boards except
> a limited few.
> I will happily supply a diff of my messings to the list or
> a few individuals who want it.

Please post to the list as an RFC.  Thanks.

Tom Rini

More information about the Linuxppc-embedded mailing list