Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)

[Benjamin Herrenschmidt]

On Mon, 2005-05-23 at 00:43 +0300, Tzachi Perelstein wrote:
> Seems like it was a *hot* weekend...
> 
> Ben, I agree with Wolfgang that while taking footprint and simplicity
> into account we should "try to think about the whole system, including
> boot loader, kernel, and any data that might need to get passed between
> these two". 

This is what this is doing. Please read all that was said.

> My ppc64 Linux is booted from U-Boot on Marvell platform and it uses the
> simple board_info instead of the device-tree. There are only some minor
> hacks in arch files that by-pass the whole device-tree usage in head.S
> and setup.c, e.g. [1] early_init_board_info() instead of
> early_init_devtree(), and [2] skipping on unflatten_device_tree() and
> finish_device_tree(). 

Minor hacks -> too many hacks. Please. Understand that it means
everybody will end up creating slightly different board-info, and the
whole thing will end up like an ifdef clutter.

Honestly, I don't see where is your problem with a device-tree, it seems
we have proven it was both small and much more flexible.

> As you know, the majority of these functions and
> sub-functions just parse and handle the device-tree. 
> Frankly, although I'm willing to give device-tree a try, I think it is
> not the wise thing to do.

Well, I think you are wrong.

>  It is simple and effective, and it can be
> nicer with minor _general_ support in arch files to non-OF loaders. 

There is, it's called a flattened device-tree. Damn, I can't see what is
your problem here. A minimum tree is a few hundred bytes dammit ! You
can probably even define one that exposes the north bridges devices
(assuming you have similar ethernet as other Marvell chips) etc... in a
few more hundred bytes, thus making the whole probing of these &
matching with drivers a lot cleaner on the kernel side.

> A
> slightly different loading for embedded systems is not necessarily a
> mess. I'm sure that the ppc experience will make it be nice and
> structured even this way.

Nope, it won't. A structure definition is the _worse_ thing to do.

> Imagine emerging ppc64 Linux embedded systems living outside the kernel
> due to embedded incompatibilities; this might make much more mess in the
> long run... 

I don't understand your point. It is _simple_ to set up a device-tree.
It's probably even more flexible for your own embedded needs.

Ben.