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.lik...@secretlab.ca] > > Sent: Monday, May 11, 2009 10:30 PM > > To: Stephen Neuendorffer > > Cc: David H. Lynch Jr.; linuxppc-dev@ozlabs.org > > Subject: Re: device trees. > > > > On Mon, May 11, 2009 at 10:27 PM, Stephen Neuendorffer > > <stephen.neuendorf...@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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
