[U-Boot] [RFC 1/3] FDT: Add fixup support of multiple banks of memory

[Scott Wood]

On Tue, 10 Aug 2010 13:39:57 -0600
Grant Likely <grant.likely at secretlab.ca> wrote:

> :-)
> 
> I still stand on my point that hard coding device tree manipulations
> is asking for trouble.  IMNSHO, firmware should really be restricted
> to very well defined things in the device tree.  I've been thinking
> about this a lot, and I'm going to write a "Recommended Practice"
> document for dealing with the .dtb at the firmware level.  At the
> moment, I think firmware should be restricted to only touching the
> /chosen node, the /memory node, and updating well defined things like
> mac address, but only when the Ethernet node is dereferenced from an
> /aliases name instead of full path.

When I try to think of the fundamental difference between the above
modifications and others, the main thing that I see is
maturity/stability.  There's nothing special about these except that
we've already gone through the pain, and believe (but can't be certain)
we've got it right now.  We had problems with the /chosen node (must
already exist, can't already exist, etc).  We did other things before
for MAC addresses (hard-coded paths, "mac-address" versus
"local-mac-address", etc).  What happens if we need multiple memory
nodes?  What happens if u-boot's use of aliases contradicts some other
use?  Are even additional types of clock updates off-limits?  What
about looking up by compatible and distinguishing by address?

I think a question we need to answer is, what *is* the device tree?
Is it just a convenient way for Linux to organize its knowledge about
the hardware -- in which case, would we have been better off by having
firmware not touch it at all, and instead do something like cuImage with
bd_t replaced by something more robust and extensible (but not as
complicated as a full device tree)?

Or is the device tree a bundle of information handed to the OS by
whatever came before it (be it firmware, a replaceable chunk of code
sitting on top of firmware, a hypervisor, static partitioning provided
by the system designer, or early Linux code to transform a known type
of bad device tree into a good one)?  This is what it was in Open
Firmware, and is my understanding of what it was meant to be in ePAPR.

I think the latter is far more useful.  It involves a greater
compatibility challenge, but there are escape hatches short of
replacing firmware.  It scares me less than trying to maintain a static
device tree for every way the p4080 reference board could be configured
(and deal with support when people use the wrong one). :-)

> I *might* be able to be convinced that firmware should be allowed to
> modify other properties, but only if it isn't hard coded into the
> firmware (ie, by using a boot script or other method that can be
> changed without upgrading firmware).  As we've discovered in the past,
> it is very easy to get into a situation where firmware must be
> upgraded to deal with a change in the device tree data. (ie. soc node
> name cannot be changed from "soc5200" to "soc" on the lite5200 because
> older versions of U-Boot do a pathname lookup)  This risk can be
> mitigated if there are some well defined rules about what firmware is
> and is not allowed to modify in the tree.

There are other ways to mitigate the risk, such as having a recovery
mode that boots a different firmware image.

Even if you are stuck with firmware that wants to do broken device tree
updates, there are options:
 - Use a dts that works with the old firmware, and have a wrapper
   that fixes up whatever you wanted to change in the final tree
   after the firmware's done with it.
 - Have two trees.  Give u-boot a dtb it likes, and have glue code
   suck out important bits to stick into the real dtb.  Kind of like
   cuImage, but with a noncompliant dtb instead of bd_t.
 - Tell u-boot to not do any updates (I think this is possible if you
   use the subcommand version of bootm and do each stage manually --
   or you could give uboot some dummy dtb that it likes and put the
   real thing in a dtbImage) and hard code everything in the dts.
 - Just have the OS retain compatibility with the old binding, if
   it's not completely unusable.

Making the device tree manipulation code replaceable would be nice.
In cases where we want to convey some knowledge from the fixed
part of the firmware, it would not be too different from unconditionally
doing the two-tree thing, except that the firmware tree would be
simpler and not associated with the user-supplied dts (i.e. a "better
bd_t"), and the glue code wouldn't be tied to a particular OS.

-Scott