<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24">
<TITLE>RE: Xilinx devicetrees</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<BR>
<BR>
<P><FONT SIZE=2>-----Original Message-----<BR>
From: David H. Lynch Jr. [<A HREF="mailto:dhlii@dlasys.net">mailto:dhlii@dlasys.net</A>]<BR>
Sent: Sun 11/25/2007 1:37 AM<BR>
To: Stephen Neuendorffer<BR>
Cc: Grant Likely; linuxppc-embedded<BR>
Subject: Re: Xilinx devicetrees<BR>
<BR>
Stephen Neuendorffer wrote:<BR>
><BR>
> -----Original Message-----<BR>
> From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of Grant Likely<BR>
> Sent: Sat 11/24/2007 9:12 AM<BR>
> To: David H. Lynch Jr.<BR>
> Cc: linuxppc-embedded<BR>
> Subject: Re: Xilinx devicetrees<BR>
> <BR>
> Regardless, I think I saw a post of yours on the microblaze list<BR>
> about exporting a devicetree list with the firmware.<BR>
> that is probably a better solution that what exists now.<BR>
<BR>
I agree.. that's why I'm working on it. :) But just to clarify: I don't work directly on Xilinx products, but more in advanced development.<BR>
<BR>
> I am curious - with the firmware is not the same as in the firmware.<BR>
> But since you brought up deciphering firmware - to me and to Pico,<BR>
> and I gather to alot of others, providing indentity information within<BR>
> the firmware is a really really important issue - one which xilinx seems<BR>
> to be unable to make up its mind about.<BR>
> There are frequent posts addressing issues like this driver only<BR>
> works with this version of some IP - but there is no way to query the IP<BR>
> to enough detail to determine whether the driver will work. It is one<BR>
> thing to make version registers an option. It is entirely different to<BR>
> just omit them entirely or change the IP without changing the version.<BR>
> Our clients beat us up for things like that. DevieTrees do nto solve<BR>
> that problem.<BR>
<BR>
I know these issues are high priorities within the EDK development group. One advantage of device trees is that this information can be included without using any additional FPGA resources.<BR>
<BR>
> Anyway, my .02 would be to put the device tree into the firmware. In<BR>
> a perfect world - litterally in the firmware so that when the firmware<BR>
> loads the device tree data is already in the FPGA somewhere that it can<BR>
> be easily ready - oh and do that without consuming many FPGA resources.<BR>
> But in a more likely realworld scenario - append the information to<BR>
> the .bit file in some fashion so that if can easily be found and passed on.<BR>
<BR>
I've experimented with putting this information into BRAM. Typically compressed device trees should easily fit within a single BRAM. However, I think in most scenarios this is actually overkill. Storing the device tree with the bitstream is probably good enough, and likely cheaper since the bitstream is likely in bulk storage. This might be configuration flash (which is accessible after booting), SystemAce (in which case, the systemace image could load the device tree into a known location in memory). In other systems the bitstream and the device tree might be combined into an executable file along with processor code for configuring the FPGA. This might be used with an external processor or a partially reconfigured system.<BR>
<BR>
> Binding it to a kernel, is a non-starter for us.<BR>
<BR>
I agree that this is not the best way of leveraging the power of device trees. The point is that by using a device tree, you haven't lost anything you can do currently. In the future we might have one kernel which supports all versions of all our IP, along with all flavors of microblaze and powerpc... You would only ever need to recompile this kernel as a final optimization, if at all.<BR>
<BR>
> I am tasked with getting one binary for each<BR>
> OS to work with nearly every device(hardware) we make including<BR>
> addressing options that change with firmware AND the whim of the user.<BR>
> But life might not be to unpleasant - it might even actually be<BR>
> better, if our kernel loader just extracted the devicetree from the end<BR>
> of the currently executing firmware.<BR>
<BR>
Device trees are a data driven way of doing exactly this.<BR>
<BR>
Steve<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>