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
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
