device-tree in U-Boot

[Tzachi Perelstein]

Hi Ben, 

I'll make U-Boot loading fits to ppc64 standards using the device-tree.
I was consulting Wolfgang Denk (U-Boot owner), and he confirmed it (more
or less).

Since I'm not familiar with OF and device tree, and since you generously
offered your help, I contact you for some guidance. 
As a first step, I would like to do it as simple as possible. On the
last stage of U-Boot before branching to Linux, I will collect the
needed information and reassemble it into a device-tree. 
Can you please advise me how to do it without adding the whole
device-tree implementation to U-Boot? Is there any code reference I can
use? 
You have mentioned that there are only little requirements provided by
the kernel regarding device tree. Can you please clarify?

Best regards,
Tzachi

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh at kernel.crashing.org]
> Sent: Monday, May 16, 2005 2:34 PM
> To: Christoph Hellwig
> Cc: Tzachi Perelstein; linuxppc64-dev at ozlabs.org
> Subject: Re: io_block_mapping in PPC64?
> 

> However, I agree this can be a bit too complicated for an embedded
> firmware, and the compact device-tree format may be more suited. That
> was one of the motivations for implementing it, along with making
kexec
> possible. The "bare metal" linux folks in IBM use it, I'm trying to
> figure out if some code can be provided to the community as an example
> on how to generate it.
> 
> The kernel provides only little requirements regarding the
device-tree.
> On purpose, I do not make mandatory, for example, to have every PCI
> device enumerated by the firmware. Only host bridges, so those can
> provide proper memory/io windows and irq routing to the kernel. That
> along with a few nodes defining the board type, RAM layout, and maybe
a
> few other options you want to pass along to the kernel.
> 
> However, for things like on-chip devices, experience has showed that a
> device-tree like structure is far more convenient and flexible than
any
> kind of hard-coded mecanism, it allows the firmware to easily inform
the
> kernel on what driver to load, what address/interrupts to assign, what
> MAC address to use for ethernet, etc... without creating a "carved in
> stone" ABI like a board info structure does.
> 
> Beleive me, Tzachi, I've been there, doing embedded developpement and
> bring up, and I far more prefer changing a property or two in the
device
> tree provided by the firmware than having to add more hacks to the
> kernel image every time I decide to release a new revision of an
> embedded board.
> 
> It is _not_ complicated, and it should be fairly easy to write a
parser
> that turns an ASCII representation into a "blob" that can be flashed
and
> passed along to the kernel. In fact, I'd be glad to help you implement
> some support for generating a simple device-tree from uboot. I'm not
> trying to but "arbitrary" restrictions here, I'm really trying to
> promote a nicer and more maintainable way of defining the
> firmware<->kernel interface that is suitable for both "desktop" (and
> server) like solutions and embedded. In fact, if you read the
> linuxppc-embedded list archives, you'll notice that more than once,
> people have been trying to replace the current mess with something
like
> that, though so far, nobody has actually implemented anything, mostly
> because there is the whole lot of existing legacy board_info crap to
> deal with. I'm trying to avoid that for the future of ppc64.
> 
> Ben.
> 
>