Looking for BSP for Atmel AT91SAM7X-EK

[Joel Sherrill]

Ralf Corsepius wrote:
> On Fri, 2007-12-14 at 00:33 -0800, Till Straumann wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> On Wed, 2007-12-12 at 21:27 -0700, Andrei Chichak wrote:
>>>   
>>>       
>>>> Thanks Joel,
>>>>
>>>> Are there any docs around dealing with putting together a new BSP? I 
>>>> have taken a look at the BSP and porting guides but there doesn't 
>>>> seem to be a section on which configuration files to munge to get the 
>>>> bootstrap procedure to pick up the new BSP.
>>>>     
>>>>         
>>> Well, actually, it's pretty simple.
>>>
>>> 1. cd <src>/c/src/lib/libbsp/<cpu>
>>> and copy over the BSP which resembles to your BSP most
>>> cp <bsp> <mybsp>
>>>
>>> 2. edit your bsp's files below <mybsp>/
>>> [The actual act of porting]
>>>
>>>   
>>>       
>> If I may comment: that would be pretty bad practice.
>>     
>
> I disagree.
>   
Applied blindly it can be a bad thing from a maintenance
perspective.  It results in drivers not migrating to libchip
or libcpu.  It results in copies of files with minor differences
that often serve no real purpose but no one is sure about that.

I have been doing a lot of BSP clean up and maintenance lately.
I am trying to move more code into the shared framework in order
to make the BSP specific code smaller and clearly more necessary.

>   
>> A better way would be
>>  - make parts in <bsp> that are similar enough to what
>>    'mybsp' needs a library that supports both, <bsp> and
>>    <mybsp>. Try to make interfaces generic enough so that
>>    they could be useful to a yet more similar BSP that
>>    may be created in the future (but also: try to keep it simple).
>>  - modify <bsp> so it uses the (new) library
>>  - let <mybsp> use the library
>>  - only add new parts that are really specific to <mybsp>
>>
>> The myriad of powerpc BSPs are a painful example of
>> the result of the 'copy + edit' strategy when creating new
>> BSPs. It's maintenance hell.
>>     
> The poor shape the powerpc BSPs are in is a result of lack of RTEMS
> internal APIs and structural defects of the source code (esp. the
> "shared" dirs).
>   
I think things have improved quite a bit in the past 8 years
and there has been a lot of work to make the PCI and IRQ
API the same on the ARM, x86, and PowerPC.    Thomas
and Till have both taken stabs at reducing copies of code.

The simple vectored versus PIC IRQ model is unfortunate
but it is a necessity dictated by the lowest levels of the
CPU architecture.   The fact that we didn't toss out all
simple vectored PowerPC BSPs and didn't convert them
into "compiles may not work" simple IRQ versions has
made this take years. 

Again this is another case where copies of code got
submitted rather than someone trying to make single
shared copies.  That makes it harder and harder to
convert.

I think we are down to only a few "old/simple vectored"
PowerPC BSPs and if those were converted to "new" PIC
IRQs in a best faith "it compiles now" effort, we could
kill the entire old exceptions tree.

Having lots of copies makes it harder to begin to make
the API changes reliably.  

No the BSP code isn't perfect but unnecessary duplication
is bad.  It puts more code on the leaves of the RTEMS source
tree where there are the fewest users and makes more copies
to maintain.

--joel
> Ralf
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>