[PATCH 10/11] Add MPC8360EMDS board support

[Paul Mackerras]

Dan Malek writes:

> > ....   So you can boot the same kernel binary on
> > several boards, as long as the drivers are built in and the correct
> > device tree is used. Has everyone missed/forgotten that objective
> > completely?
> 
> That was never an objective when we started, although
> it seems some people involved in the implementation
> think it's the only objective.  It just happens to be a side
> effect when convenient.

I tend to look at it not as a direct objective in itself for the
embedded platforms, but more as something that will just happen
naturally when the code is written well.

I also don't think it's the role of the upstream kernel sources to
support every single embedded board out there.  I think stuff should
be upstream if it is either (a) useful to a lot of people as-is, or
(b) useful as a starting point for making a kernel that will work on a
specific board.

Most of the embedded stuff falls into category (b), which means that
it needs to be understandable and reusable, rather than being
specifically optimized for a particular board.  That means that ifdefs
are evil, because they obfuscate the code.  Also, ifdefs are often a
sign that a driver is only written to support one instance of a
particular device, which is a limitation on its reusability - it will
have to be modified when someone makes a chip or board that has two of
its device on it.

I have no problem whatever with someone taking the upstream sources
and optimizing it to the nth degree for their particular embedded
board.  I don't think that's appropriate for the upstream sources
though.

The device-tree concept offers a way to make drivers more readable and
reusable, by separating out the board-specific configuration
information (thus reducing ifdefs) and by encouraging the style of
code that naturally copes with any number of device instances.

> Now, we have something that is way more complex than
> we initially thought was necessary, trying to describe nearly
> everything addressable in the system instead of just the
> internal memory map.  I suspect the software to attain

How does the "internal memory map" differ from "everything addressable
in the system"?  I think it is useful if the device tree describes the
non-discoverable devices in the system; we have never said the device
tree has to contain devices that the kernel can discover for itself,
such as PCI devices.

> Highly configurable development/evaluation
> boards running a single binary aren't high volume
> products, and the additional resources required
> by such software could ensure real products aren't
> developed with PPCs.  We need to be sensitive
> to this.

Leo Li had an interesting idea, which is a preprocessor that would
take kernel code written to use the device tree, plus the specific
device tree for a board, and emit a version of the code with
everything hard-coded.  That would assist with getting the
uber-optimized version that you want for a product.

Paul.