Sun Dec 9 17:34:17 CET 2012
congruent with the logical PCI tree, but they differ significantly in a
few places. It is desirable to have both trees available: One for
resource allocation, one for device discovery. Killing either is calling
for problems down the road. Besides that, in reality we're neither
dealing with a real tree nor a completely acyclic graph.
There are easy ways out which either make the dts completely unreadable
or beget some unholy device tree code. Neither is acceptable if we
consider maintainability to be important.
The good thing is that my diploma thesis provides solutions for exactly
that class of problems. It's not about coreboot, but the problems we
face right now are so strikingly similar that I regret not writing the
whole thing in English. Anyway, I'll try to create a short writeup which
captures the essential results, and how to apply them without losing
mental sanity (or maintainability, for that matter).
The trick is to declare a preferred and readable form for storing device
relations (the existing dts structure works quite well in that regard)
and to handle different requirements for that representation like
database views. With a nice set of node properties and the right amount
of abstraction, we can keep both the code and the dts human readable and
have them provide easily understood views of their respective purposes
(resource allocation vs. device discovery). If we do it right, even such
horrors as wandering PATA/SATA PCI devices (after disabling PATA, SATA
will change its PCI devfn) are easily expressed and handled.
More information about the coreboot