device trees.

[Stephen Neuendorffer]

>> Um.. one thing I'm missing in this discussion of attaching the dtb to
>> the bitstream:  I don't see how the bitstream becomes accessible to
>> the kernel at runtime.  Unless you were exposing the dtb as part of
>> the fpga programming, but I thought you explicitly weren't doing that
>> because of limited bram space.

>    While I am not sure I grasp all of the nuances why, this is NOT the
>scheme Stephen recomends.
>    But it looks to be the most promising for me at Pico.

There is not a general way to pass additional information which does not program configuration bits of the FPGA through
the configuration interface.  There is a mechanism to do this in Virtex 4 and Virtex 5, but there is no
such mechanism for Spartan 3.  The best option that works for all Xilinx FPGAs is to use the initial state of a
BRAM memory block to contain the .dtb, which can then be scavenged and reused in the system, if necessary, although this
can impact overall system design.

David specifically asked for a mechanism which:
1) works on Spartan 3, in addition to V4 and V5.
2) does not require reserving an initialized BRAM, since BRAM information is very expensive in his system.

The solution is highly specific to the configuration mechanism that David's company uses in their systems, and is not generally applicable
to all board designs.

The main point of all of this is to avoid separating the bitstream from the corresponding .dtb, in order to
avoid consistency issues.  Essentially, the bitstream describes itself using a .dtb.

Steve



This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090512/51004f5c/attachment.htm>