[PATCH] General CHRP/MPC5K2 platform support patch

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Oct 26 08:59:38 EST 2006


> What are the implications anyway for the bplan board being CHRP vs the
> way the rest of the embedded ppcs are set up?  Will having this setup
> as a CHRP system conflict w/ non-CHRP embedded boards?  (I'm assuming
> that CHRP requires more capable firmware than u-boot passing in a fdt)

Not really :) The main thing they "buy" by going CHRP is that they use
RTAS for PCI config space access and thus don't have to write the host
bridge code. Since their firmware initializes everything properly, there
is little need for non-generic platform code and that sort of generic
platform code is what CHRP provides.

With the device-tree thingy done properly nowadays, there should be
little difference between platforms unless you end up dealing with
really special things.

There should be no conflict with non-CHRP boards using the MPC5200 chip
provided they do things right which is what I've been advocating so far.
That includes making sure everybody agrees on the format of the MPC5200
specific bits in the device-tree:

 - Format of the interrupt cells (they have come up upon my suggestion
to a 3-cell based format (could probably be compressed a bit but heh)
and that should be documented publically)

 - Binding (set of required properties and their definitions) for on
chip devices, and more specifically, for representing the bestcomm and
the links between devices and associated bestcomm tasks.

If the above is properly agreed upon, then the code for dealing with
MPC5200 specific devices will purely rely on those bits, and thus should
be useable from whatever platform it's included in, wether it's CHRP, or
something else.

Unfortunately, at this point, Nicolas seems to be unwilling to open up
his device-tree publically.

Ben.





More information about the Linuxppc-embedded mailing list