From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Mon, 23 May 2005 08:29:36 +1000 Subject: [U-Boot-Users] RE: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2) In-Reply-To: References: Message-ID: <1116800976.6002.16.camel@gaston> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.