From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from IE1EHSOBE002.bigfish.com (outbound-dub.frontbridge.com [213.199.154.16]) by ozlabs.org (Postfix) with ESMTP id 141FBDDFC8 for ; Wed, 13 May 2009 16:58:31 +1000 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9D398.34655E0B" Subject: RE: device trees. Date: Tue, 12 May 2009 23:58:22 -0700 References: <20090511155232.A30671B6005D@mail89-va3.bigfish.com> <4A08593C.4010503@dlasys.net> <20090511183638.F07C01438054@mail184-wa4.bigfish.com> <4A08C599.2030100@dlasys.net> <20090512005554.EEE1019D009B@mail129-dub.bigfish.com> <4A08E050.9000302@dlasys.net> <20090512042733.8D4A21400054@mail184-dub.bigfish.com> <20090513001048.490B533005D@mail141-va3.bigfish.com> <20090513023614.GJ24338@yookeroo.seuss> <4A0A6495.2050605@dlasys.net> From: Stephen Neuendorffer To: "David H. Lynch Jr." , , Message-ID: <20090513065824.25E23AA8054@mail107-dub.bigfish.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , ------_=_NextPart_001_01C9D398.34655E0B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >> 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 pr= ogram configuration bits of the FPGA through the configuration interface. There is a mechanism to do this in Virtex 4 a= nd Virtex 5, but there is no such mechanism for Spartan 3. The best option that works for all Xilinx FP= GAs is to use the initial state of a BRAM memory block to contain the .dtb, which can then be scavenged and reus= ed 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 i= s 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 usin= g a .dtb. Steve This email and any attachments are intended for the sole use of the named r= ecipient(s) and contain(s) confidential information that may be proprietary= , privileged or copyrighted under applicable law. If you are not the intend= ed recipient, do not read, copy, or forward this email message or any attac= hments. Delete this email message and any attachments immediately. ------_=_NextPart_001_01C9D398.34655E0B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: device trees.

>> Um.. one thing I'm missing in this discussion of= attaching the dtb to
>> the bitstream:  I don't see how the bitstream becomes accessi= ble to
>> the kernel at runtime.  Unless you were exposing the dtb as p= art of
>> the fpga programming, but I thought you explicitly weren't doing t= hat
>> 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 pr= ogram configuration bits of the FPGA through
the configuration interface.  There is a mechanism to do this in Virte= x 4 and Virtex 5, but there is no
such mechanism for Spartan 3.  The best option that works for all Xili= nx FPGAs is to use the initial state of a
BRAM memory block to contain the .dtb, which can then be scavenged and reus= ed 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 i= s 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 u= se of the named recipient(s) and contain(s) confidential information that m= ay be proprietary, privileged or copyrighted under applicable law. If you a= re not the intended recipient, do not read, copy, or forward this email mes= sage or any attachments. Delete this email message and any attachments imme= diately. ------_=_NextPart_001_01C9D398.34655E0B--