[PATCH] ZYNQ BSP

[Joel Sherrill]

On 4/22/2013 11:17 AM, Claus, Ric wrote:
> Hi Chris,
>
> 1) There's quite a bit of code in those libraries.  Basically, they provide all the 'action' where I provided just 'framework'.
> 2) I had an idea yesterday that made this seem fairly simple.  It took care of all the '#include's, functions and macros.  Then I realized there are still the register definition macros to deal with.  Besides being an awful lot of typing or copying, I wonder at what point doing that becomes a copyright infringement.  In essence, I'd effectively be taking the header files.
This sounds like what was mentioned with a recent libgloss submission.
The libgloss code was just glue to generated code from the synthesis tool.

This is a general multi-vendor/architecture problem. The synthesizable
system on chips generate at least .h files and often near complete
device driver guts. We need a general solution.

This class of BSPs can't be built without this code (which can change
from user to user) and we don't want to duplicate it. But you can't build
this class of BSP without it.

Assuming the generated code is OK to distribute, my first thought would be
have a "generic" set of it which can be used to generate the BSP available
in a subdirectory of the BSP.  Then a clearly documented and easy to use
configure option to override the use of this directory. With any luck, the
"generic" version can build all code in the BSP. With even more luck, it
could correspond to a simulator configuration.

Thinking grander, the scheme COULD allow for multiple sets within the
tree and an arbitrary set outside the tree. Then you could have reference
board X, simulator Y, etc.

This is becoming a general problem. The SoC vendors work to provide the
code and we should let the BSP glue to it. Customers of those vendors using
those chips expect it to work this way.
> Ric
>
> ________________________________________
> From: Chris Johns [chrisj at rtems.org]
> Sent: Sunday, April 21, 2013 3:53 PM
> To: Claus, Ric
> Cc: Gedare Bloom; RTEMS Devel
> Subject: Re: [PATCH] ZYNQ BSP
>
> Hi Ric,
>
> Many thanks for submitting this BSP.
>
> Claus, Ric wrote:
>> Answers:
>> 1) No, not at this stage.
> What are these libraries providing ?
> How much code is this ?
>
>> 2) No, unfortunately not.  I had hoped to provide a way to deal with this, but there are too many things pressing.
> Great to know it is just a matter of effort.
>
> Chris
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985