[U-Boot-Users] RE: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)

[U-Boot-Users] RE: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)

[Tzachi Perelstein]

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". 

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(). 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. It is simple and effective, and it can be
nicer with minor _general_ support in arch files to non-OF loaders. 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.

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

Best Regards,
Tzachi

[U-Boot-Users] RE: 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.

[U-Boot-Users] Re: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)

[Segher Boessenkool]

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

The mess won't be _in the main kernel repository_, though.  I.e., 
whoever
caused it, would have to deal with it; not everyone else.


Segher