[U-Boot-Users] RE: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)
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
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.
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
participants (3)
-
Benjamin Herrenschmidt -
Segher Boessenkool -
Tzachi Perelstein