david at gibson.dropbear.id.au
Tue Apr 28 14:21:05 EST 2009
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> David Gibson wrote:
> > It's not so much point of view as situation. Putting the device tree
> > in the firmware and putting the device tree in the kernel are both
> > valid choices, with their own distinct advantages and drawbacks.
> I was under the impression that the reason we put the device trees in
> the kernel is because we didn't have a better place to put them.
> Keeping them in the kernel repository was just convenient.
> So I personally don't consider the *location* of the DTS files to be a
> basis for deciding what they really mean.
I'm not talking abou where the DTS files sit, I'm talking about where
the compiled blob sits. There are a number of options here:
* built into the firmware
* loaded by the firmware, say from a separate flash partition
(e.g. modern uboot)
* generated at runtime by the firmware
* built into the kernel's bootwrapper (e.g. cuboot).
* generated by the bootwrapper at runtime from
firmware information in another format (e.g. paul's proposed res2dt
approach for PReP)
Which method is appropriate depends on the needs of the platform,
including what legacy stuff we need to deal with for the platform.
Then in turn, how hard we should work to make the kernel backwards
compatible with old device tree formats depends on what choice we made
here (for platform specific devices, obviously).
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_!
More information about the Linuxppc-dev