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.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dh...@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too
numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
