From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Thu, 19 May 2005 09:11:23 +1000 Subject: [U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO In-Reply-To: References: <1116400151.918.10.camel@gaston> Message-ID: <1116457884.918.29.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 Wed, 2005-05-18 at 10:12 +0200, Marius Groeger wrote: > Ben, > > On Wed, 18 May 2005, Benjamin Herrenschmidt wrote: > > > Here's the very first draft of my HOWTO about booting the linux/ppc64 > > kernel without open firmware. It's still incomplete, the main chapter > ^^^^^^^^^^^^^^^^^^^^^ > One could argue whether the full-blown emulation of an OF device tree > may really be called this.... ;-) You must be kidding :) Honestly, a device tree is small and rather simple to layout, and would fix most of the issues with piling up crap like incompatible boot_info structures and that sort of thing that plague the ppc32 kernel. A full blown implementation of OF is a lot bigger. It requires at least 3 different interfaces (the user interface, the fcode interface, the client interface), along with all the bits & pieces to get a full runtime environment. > > > b) Direct entry with a flattened device-tree block. This entry > > point is called by a) after the OF trampoline and can also be > > called directly by a bootloader that does not support the Open > > Firmware client interface. It is also used by "kexec" to > > For OF based systems, what you outline definitely makes an awful lot of > sense. How so ? OF based system just implement the OF interface... > For others I wonder what the costs of this are in terms of the memory > footprint (both RAM and ROM). Are there reference implementations in > existence? You may not have noticed (well, I haven't filled part III yet so it may not be clear), but I'm only making a very small subset of the device-tree mandatory, though I do encourage people to provide an as complete as possible. For example, I will definitely not require the bootloader to provide a full tree of PCI devices, only host bridges, in order to get interrupt routing and resource mapping. However, I encourage people to put things like on-chip devices in there, it makes everything much more flexible. Regarding the cost, well, the device-tree itself is fairly small, maybe a couple of pages for a minimum one. As I wrote, embedded boards can decide to have it built at booloader build time, and simply embedded as a blob in the firmware and passed along to the kernel, that is 0 firmware code. However, it would be simple to add minimum capabilities to the firmware for editing/adding properties (for things like memory size or kernel command line). I wonder sometimes why people are so "afraid" of the device-tree concept... it's really simple, does not require that much code, and makes everything so much more flexible in the long run. Ben.