device trees.

[David Gibson]

On Wed, May 13, 2009 at 02:11:33AM -0400, David H. Lynch Jr. wrote:
> David Gibson wrote:
> > 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...?
> >   
>     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.
> 
>     In my instance, the FPGA code is typically in NOR Flash - actually
> several different FPGA bitstreams might be in Flash.
>     The mechanism that we use to load the FPGA ensures that I can know
> the Flash File that was used to program the FPGA.
>     That means that my monitor an read that file and extract the device
> tree.
>     The remainder is a discussion of how to concatenate the dtb and the
> bit stream together, the pros/cons of prepending vs. appending,
>     and work arrounds for issues.
>     The critical factor is that the nature of the FPGA load process
> makes it possible to put data at the front or rear and assure that it
> gets ignored.

Ok.  If you have NOR flash, why couldn't you just put the dtb in a
separate partition of the NOR?

-- 
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