device trees.

[David Gibson]

On Tue, May 12, 2009 at 05:10:46PM -0700, Stephen Neuendorffer wrote:
> 
> Another possibility is to pad the DTB with a DESYNC command and the
> correct pad frame, just in case it cannot be prevented.

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.

I imagine this is simply due to my ignorance about FPGA techniques,
but if someone could enlighten me...?

> > -----Original Message-----
> > From: Grant Likely [mailto:grant.likely at secretlab.ca]
> > Sent: Monday, May 11, 2009 10:30 PM
> > To: Stephen Neuendorffer
> > Cc: David H. Lynch Jr.; linuxppc-dev at ozlabs.org
> > Subject: Re: device trees.
> > 
> > On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer
> > <stephen.neuendorffer at xilinx.com> wrote:
> > >> > OK, so the key question seems to be *when* the bitstream is
> > > associated
> > >> > with the
> > >> > device tree.  If at bitstream generation time, you can prepend the
> > > .dtb
> > >> > to the bitstream.  As long as the dtb doesn't contain the magic
> > >> > bitstream start code, you can go back and access it later.
> > >> >
> > >> You really mean prepend ? I was presuming that things would work
> > > better
> > >> if it was appended ?
> > >
> > > Yes, actually prepend is simpler because you don't have to know the size
> > > of the bitstream.
> > > Everything before the SYNC code in the bitstream is ignored.
> > 
> > ...In this case, might need to preprocess the .dtb the escape out the
> > possibility of a sync code appearing.
> > 
> > g.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson