From mboxrd@z Thu Jan  1 00:00:00 1970
From: Wolfgang Denk <wd@denx.de>
Date: Fri, 26 Oct 2012 22:06:22 +0200
Subject: [U-Boot] Merging device trees at runtime for module-based
	systems
In-Reply-To: <508AD8F9.8030105@wwwdotorg.org>
References: <5087B919.2010006@gmail.com> <508AD8F9.8030105@wwwdotorg.org>
Message-ID: <20121026200622.214792005D6@gemini.denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Dear Stephen Warren,

In message <508AD8F9.8030105@wwwdotorg.org> you wrote:
>
> Simply overlaying two DTBs on top of each-other (in the same fashion
> that dtc's /include/ statement would do at compile-time) might not be
> fully general enough, although perhaps it would be sufficient for your
> immediate needs.

I think it should be sufficient for the overwhelming majority of use
cases.  When designing and implementing this feature, I suggest to
start small with the most common use cases in mind only.

> For example, lets say that a GPIO is routed from a device on the main
> board to a device on a daughter board, or even from one daughter board
> into the main board and back out to a different daughter board. Now,
> consider that the different board(s) that are the source of the GPIO
> might use completely different SoCs or versions of the SoC, which might
> require using a different GPIO specifier to represent the signal. That
> means you need to change the .dtb file for the "client" of the GPIO
> depending on the HW or .dtb that provides the GPIO. That's certainly not
> a simple matter of merging multiple .dtb blobs together.

Yes, one can construct arbitrarily complicated situations.  But I
think it is perfectly reasonable to ignore these, at least for the
initial implementation.

I'm not even convinced that we should try to come up with a solution
that is capable of dealing automtically with any situation of such
complexity.  In reality, we can probably combine a simple overly
mechanism with additional fixup though some shell script running FDT
manipulation commands directly.

> I wonder if similar yet more subtle issues might arise, such as some
> motherboards requiring an active-low IRQ signal yet others requiring an
> active-high IRQ signal, thus requiring a daughter-board to program its
> IRQ source differently. Similarly, what about different drive strength
> requirements for a signal source, depending on what board version
> receives the signal?

I suggest to try to ignore such situations for now, and get started
with a working, simple implementation.  If we actually run into a
situation where handling such situations is needed, we can then
discuss about solutions based on a much beter understanding and
experience with the - then - existing simple code.


In short: let's do a simple, working thing first, and add bells and
whistles later.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A dog always bit deepest on the veterinary hand.
                                    - Terry Pratchett, _Wyrd Sisters_