David Gibson wrote:
>>
>> It is not THE dtb, it is A dtb. Our systems support and typically use
>> multiple FPGA bit streams.
>>
>
> Ah, ok. And those multiple bitstreams all inhabit the same NOR flash?
> From what I read below I'm guessing not..
>
In my work they virtually always do,
David Gibson wrote:
>
>
> Ok. If you have NOR flash, why couldn't you just put the dtb in a
> separate partition of the NOR?
>
>
It is not THE dtb, it is A dtb. Our systems support and typically use
multiple FPGA bit streams.
Clients are
That means each bitstream must have its own dtb, clients
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 t
Are we all using the same meaning of firmware ?
While firmware == BIOS is the norm for PC's
atleast in the embedded FPGA space firmware could mean the FPGA
programing that creates the hardware.
For an FPGA based system a dtb generated by the same software that
created the "firmw
I am working on changes to xilinx_lltemac.c that support both
the SDMA and FIFO TEMAC's.
I was wondering if anyone else had done anything already ?
I have it pretty much working with a few issues:
every so often the read FIFO gets out of sync and I have to
reset
Stephen Neuendorffer wrote:
>
>> Many of our systems are LX systems but currently we are not running
>> Linux on them.
>>
>
> Master SelectMap, I presume? What FPGA family?
> Does the FPGA have access to the CPLD after boot, other than through the
> configuration pins?
>
>
One of the skill
Grant Likely wrote:
>
> What do you mean by "one size fits all solution?"
>
> The kernel doesn't care where the device tree comes from. All it
> cares about is that by the time the kernel is started the device tree
> must be fully formed and populated. It can be completely pre-canned
> (like s
Timur Tabi wrote:
> On Mon, May 11, 2009 at 1:32 AM, David H. Lynch Jr. wrote:
>
> So all you need to do is have your boot loader create a device tree
> from scratch. If you're using U-Boot, then you can already do this by
> making the appropriate libfdt calls. Otherwise,
Grant Likely wrote:
>
>>We are very actively headed in the opposite direction. It is my/our
>> intention to have a single linux executable that works accross
>>everyone of our cards and everyone of our bitfiles.
>>
>
> That is the direction we are already going in. U-Boot supports
Stephen Neuendorffer wrote:
>> You *could* generate the device tree dynamically, but I think that is
>> a path of diminishing returns considering that generating a .dts at
>> the same time as bitstream creation time is cheap and it is small. At
>> one time Steven Neuendorffer was playing with a sc
Sun, May 10, 2009 at 8:00 PM, Michael Ellerman
> wrote:
>
>> On Sat, 2009-05-09 at 14:51 -0600, Grant Likely wrote:
>>
>>> On Fri, May 8, 2009 at 10:03 AM, David H. Lynch Jr.
>>> wrote:
>>>
>>>>Is there an example
Is there an example somewhere that shows building a device tree on
the fly ?
As our products move forward it becomes increasingly clear that
static configurations are not going to work.
--
Dave Lynch DLA Systems
Software Development:
hey rarely work, and
you must think inside their box.
I would be ecstatic with just a cygwin-linux-ppc-uclibc tool chain.
Grant Likely wrote:
> On Thu, Mar 19, 2009 at 5:59 PM, David H. Lynch Jr. wrote:
>
>>Does anyone have experience sugestions for buildin
Does anyone have experience sugestions for building ppc/linux apps
or even ppc kernels under windows.
I work (and live) under Linux. I am very happy to work under Linux.
I only spend about 20 minutes a week in windows anymore.
But I have coworkers, and clients that live under windows
I have been using the mainline c67x00 driver on our boards for a while.
I am running 2.6.26-rc4 - basically the last arch/ppc version.
I can only detect devices on the first port of the first host but
otherwise it has been working.
Grant Likely wrote:
> Unfortunately, the 2.6.24-r
15 matches
Mail list logo
