Xilinx devicetrees

[Stephen Neuendorffer]

> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii at dlasystems.com] 
> Sent: Monday, November 26, 2007 1:17 PM
> To: Koss, Mike (Mission Systems)
> Cc: Stephen Neuendorffer; Grant Likely; linuxppc-embedded
> Subject: Re: Xilinx devicetrees
> 
> Koss, Mike (Mission Systems) wrote:
> > Time for my $.02, since I am heavily weighting my future 
> designs on the
> > use of the device trees. :) (and b/c I don't check my work 
> e-mail from
> > home ;P)
> >
> > ________________________________
> >
> > From: Stephen Neuendorffer [mailto:stephen.neuendorffer at xilinx.com] 
> > Sent: Sunday, November 25, 2007 6:59 PM
> > To: David H. Lynch Jr.; Grant Likely; linuxppc-embedded
> > Subject: RE: Xilinx devicetrees
> >
> >
> 
> >
> > SN> I don't understand the 'burden on software developers'. 
>  The code to
> > do this will just be standard code.  
>     I got 16K of RAM for my boot loader and that 16K has to 
> do alot more
> than just manage device trees.
>     I think we have 2K left. In that I have to fit scripting, and
> ethernet, so where am I supposed to fit the standard code ?
>     If the devicetree is say at the end of the bit file I can probably
> copy it to ram and pass a pointer to linux in maybe a couple 
> of hundred
> bytes.
>     If I have to do much more it ain't happening.

Personally, It sounds like you're trying to do to much...  The only
thing that that code really needs to do is to find the 'real' boot code:
Maybe Uboot stored in flash? :)  I'm not naive enough to suggest that I
understand all the constraints of your system, but it is another
solution.

> > The worst that one can say is:
> > SN> 1) I need several KB additional non volatile storage.  Given the
> > size of the FPGA bitstream, this can't be a huge constraint.
> >   
>        Several KB is NOT happening. The bitstream is in 
> flash. Flash is
> not a limited reasorce for  us.
>        FPGA cells, and BRAM are precious as gold. The more we use the
> less our clients have.

Device tree should probably be stored in flash, in your case....

> >
> > SN> Certainly..  But in a sense, these are all intermediate 
> files on the
> > path to the image on the board.
>     Unless we are going to teach linux to read and interpret 
> .bit files
> while loading, then devicetrees are intermediate in an entirely
> different sense.
>     The hardware works fine regardless of whether their is a 
> devicetree.
> But Linux may not boot.

I think this philosphy really minimized the value of software...  The
hardware doesn't work unless the software that comes with it *also*
works. :)

>      My objective is to get alot of software - linux, GHS, and
> standalone apps, to all load - from a single executables, accross
> multiple different bit images on several different (though 
> deliberately
> similar) products. My Linux kernel needs to work regardless 
> of the Pico
> card and regardless of the bit image, as done my GHS kernel, and ....
> And I need to do that in a severly resource constrained environment.
>     I would hope that should make sense of my harping about
> version/capabilities registers. If I have maybe 10 possible 
> peices of IP
> that may/maynot be present in a given FPGA and I am trying to
> dynamically configure - Linux/GHS/... to adapt to whatever it 
> encounters
> and work as long as it is a viable combination. At best 
> devicetrees are
> an extremly complex way of solving that - while version 
> registers are a
> trivial way.

It sounds like the real problem that you have is that even if you get
device trees working for Linux, you still have the same problem for GHS,
so from your perspective "device trees don't help"

Steve