io_block_mapping in PPC64?

[Benjamin Herrenschmidt]

On Mon, 2005-05-16 at 12:58 +0200, Christoph Hellwig wrote:
> On Mon, May 16, 2005 at 01:47:22PM +0300, Tzachi Perelstein wrote:
> > 
> > Please forgive me, but although I absolutely accept your motivation, I
> > disagree with your conclusion. Linux ppc64 should have an alternative to
> > the 'desktop' device-tree structure, something that will be more
> > embedded systems friendly, like the compact U-Boot structure. It doesn't
> > mean that ppc64 arch will become a mess.
> 
> So why exactly is the flat device tree not embedded device friendly?
> The IBM maple evaluation board uses it quite nicely

Sorry, Christophe, I have to correct you here :) The Maple board use IBM
PIBS firmware which implements the full open firmware client interface.
However, I agree this can be a bit too complicated for an embedded
firmware, and the compact device-tree format may be more suited. That
was one of the motivations for implementing it, along with making kexec
possible. The "bare metal" linux folks in IBM use it, I'm trying to
figure out if some code can be provided to the community as an example
on how to generate it.

The kernel provides only little requirements regarding the device-tree.
On purpose, I do not make mandatory, for example, to have every PCI
device enumerated by the firmware. Only host bridges, so those can
provide proper memory/io windows and irq routing to the kernel. That
along with a few nodes defining the board type, RAM layout, and maybe a
few other options you want to pass along to the kernel.

However, for things like on-chip devices, experience has showed that a
device-tree like structure is far more convenient and flexible than any
kind of hard-coded mecanism, it allows the firmware to easily inform the
kernel on what driver to load, what address/interrupts to assign, what
MAC address to use for ethernet, etc... without creating a "carved in
stone" ABI like a board info structure does.

Beleive me, Tzachi, I've been there, doing embedded developpement and
bring up, and I far more prefer changing a property or two in the device
tree provided by the firmware than having to add more hacks to the
kernel image every time I decide to release a new revision of an
embedded board.

It is _not_ complicated, and it should be fairly easy to write a parser
that turns an ASCII representation into a "blob" that can be flashed and
passed along to the kernel. In fact, I'd be glad to help you implement
some support for generating a simple device-tree from uboot. I'm not
trying to but "arbitrary" restrictions here, I'm really trying to
promote a nicer and more maintainable way of defining the
firmware<->kernel interface that is suitable for both "desktop" (and
server) like solutions and embedded. In fact, if you read the
linuxppc-embedded list archives, you'll notice that more than once,
people have been trying to replace the current mess with something like
that, though so far, nobody has actually implemented anything, mostly
because there is the whole lot of existing legacy board_info crap to
deal with. I'm trying to avoid that for the future of ppc64.

Ben.