Stephen Neuendorffer wrote:
>
> -----Original Message-----
> From: [EMAIL PROTECTED] on behalf of Grant Likely
> Sent: Sat 11/24/2007 9:12 AM
> To: David H. Lynch Jr.
> Cc: linuxppc-embedded
> Subject: Re: Xilinx devicetrees
>
> On 11/24/07, David H. Lynch Jr. <[EMAIL PROTECTED]> wrote:
>
>
>>> I am having some difficulty grasping the significant advantages to
>>> this.
>>> If the firmware for a given target is not fairly static - and I load
>>> different firmware depending on what I am doing all the time, then I
>>> know have to manage both a bit file for the firmware, and a devicetree
>>> file describing it to the kernel.
>>>
>
> The device tree file is meta-information about your bitfile. Think of it as
> 'part of the firmware'. In the (hopefully short) future, it won't even have
> to be managed, it will just be one of the things that is generated by the EDK
> flow.
>
Part of the bad news is that I have been kept so busy on the
software side of things, I have had very very little time to play with
xilinx tools and firmware. But overall at Pico we have a love hate
relationship with them. Our products are primarily wrapped arround
FPGA's particularly Xilinx.
We love what we can do. But there are days that I here loud muttering
about completely rewriting all the xilinx software tools - there is a
surprisingly large amount that many of the Pico firmware people do not
use already.
Regardless, I think I saw a post of yours on the microblaze list
about exporting a devicetree list with the firmware.
that is probably a better solution that what exists now.
> You won't have to write a bunch of code that deciphers which fpga firmware
> you are running on.. That information will be found with the firmware and
> can be dealt with in a generic way. If you already HAVE that code, you can
> keep using it, but maintaining that kind of code is probably not where you
> want to spend your time.
>
I am curious - with the firmware is not the same as in the firmware.
But since you brought up deciphering firmware - to me and to Pico,
and I gather to alot of others, providing indentity information within
the firmware is a really really important issue - one which xilinx seems
to be unable to make up its mind about.
There are frequent posts addressing issues like this driver only
works with this version of some IP - but there is no way to query the IP
to enough detail to determine whether the driver will work. It is one
thing to make version registers an option. It is entirely different to
just omit them entirely or change the IP without changing the version.
Our clients beat us up for things like that. DevieTrees do nto solve
that problem.
Anyway, my .02 would be to put the device tree into the firmware. In
a perfect world - litterally in the firmware so that when the firmware
loads the device tree data is already in the FPGA somewhere that it can
be easily ready - oh and do that without consuming many FPGA resources.
But in a more likely realworld scenario - append the information to
the .bit file in some fashion so that if can easily be found and passed on.
Binding it to a kernel, is a non-starter for us. That means a
permuation of multiple different OS kernels for each bit file we might
have. That is huge number. I am tasked with getting one binary for each
OS to work with nearly every device(hardware) we make including
addressing options that change with firmware AND the whim of the user.
But life might not be to unpleasant - it might even actually be
better, if our kernel loader just extracted the devicetree from the end
of the currently executing firmware.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 [EMAIL PROTECTED] 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-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
