On Mon, May 11, 2009 at 05:38:16PM -0400, David H. Lynch Jr. wrote:
> Grant Likely wrote:
> >
> > What do you mean by "one size fits all solution?"
> >
> > The kernel doesn't care where the device tree comes from. All it
> > cares about is that by the time the kernel is started the device tree
> > must be fully formed and populated. It can be completely pre-canned
> > (like simpleImage), it can be modified by firmware (like u-boot), or
> > it can be generated from scratch (like with real OpenFirmware). There
> > is lots of flexibility on how to handle it.
> First device trees are now the ONLY means of passing information to
> the kernel.
That's not really true in practice. Yes, the device tree is the only
way to pass information to the kernel proper, but having a
bootwrapper, built along with the kernel, which translates information
in some other form into a device tree is a perfectly reasonable
solution for the right circumstances.
> By definition that means it is a one size fits all
> solution. While there is nothing inherently wrong with that,
> solutions intended to meet all circumstances need to be simple,
> powerful, and flexible. They need to work well 100% of the time not
> 98%.
>
> Not only is the device tree expected to pass static hardware
> configuration information, but it is the sole means of passing anything.
> As an example Command lines are to be in the device tree.
> Everything is supposed to be in the device tree, whether that
> information is static or dynamic, whether it is hardware information,
> or user choices.
>
> That means that whether you are in a Sun or Apple Desktop or a
> system with the no flash and barely enough resources to run Linux,
> you still may have to manipulate the device tree.
Compared to running Linux, manipulating the device tree is a complete
triviality, so I don't see what the problem is here.
[snip]
> Welding the bit file to the dtb might solve 75% of my issues,
> And it probably would get me to the point where I could move
> forward and live with
> the remaining issues untile I was inspired to solve them.
> but it does not solve everything. It is increasingly clear to me
> that I am going to have to
> manipulate device trees.
That's probably true. But you don't necessarily have to do it within
your BRAM firmware - you can do it inside the Linux bootwrapper.
> >> Anyway, all I was looking for was a leg up on figuring out how to do
> >> what I want with them. Rather than starting from scratch.
> >> I am not looking to be convinced that I am approaching this all wrong.
> >> If you are happy with what you have - great. I am not.
> >> While I was not looking to restart a great debate over device trees
> >> - I do not actually think they are a bad idea.
> >>
> >
> > I still don't understand what you're worried about starting an arguing
> > about. Pretty much any of the PowerPC maintainers can point at warts
> > and problems in the current handling of device trees. I'm not
> > particularly happy with simpleImage (and I wrote it), but it takes
> > time and effort to write something more capable.
> >
> I was not trying to start an argument, my initial question was
>
> "Is there an example somewhere that shows building a device tree on the
> fly ?"
>
> The responses have questioned why I want to do that rather than how can I
> do that.
> I was not actually seeking a debate over the merit of device trees, or
> u-boot, or libdft, or ....
Probably the closest things to suitable examples here are
arch/powerpc/kernel/prom_init.c, which builds the dtb from the "live"
OF device tree. At the moment that's a bit of a special case, but
there's no inherent reason that logic couldn't be moved to the
bootwrapper.
The other, not in the main tree, is Paul's restodt, which builds a
device tree from old-style PReP residual information. I recall it was
sent to the list as a userspace program (we were gathering information
on the sorts of PReP out there). I think Paul made at least a first
cut at fusing it into the bootwrapper, but I don't know if that ever
got sent out to the list.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
