Blackfin BSP

[Joel Sherrill]

Allan Hessenflow wrote:
> Hello,
>
> I've started on a BSP for a bf537 based board.  I took a copy of the
> ezkit533 bsp and, with only trivial changes, got it to work on the
> bf537.  So I'm about to start writing drivers for some additional
> peripherals, most significantly the ethernet module in the bf537.
>
> Since this is a BSP I'll be able to contribute back to RTEMS, I
> thought I'd ask if there's any preference on how to do the peripheral
> definitions.  Currently, under cpukit, there's a bf533.h that defines
> the locations of the peripherals that chip has.  There is a lot in
> common between different members of the blackfin family, so the bf537
> definitions could easily be put in the same file, controlling the
> differences with a CPU model define.  In that case I'd rename it to
> something more generic.  Or, the definitions could be put in a new
> file, bf537.h; that file would then duplicate most, if not all, of the
> contents of bf533.h.  Personally I'd prefer the former to eliminate
> that duplication.  I only see a couple of advantages to the latter -
> there wouldn't be any additional #ifdef's, and it would cut down on the
> changes I'd be making to files that are maintained by someone else.
>
>   
Duplicating the bulk of a header file is definitely bad!

The solution to sharing the contents varies.  A single
.h file with conditionals for CPU models could become
very large and unwieldy.   It could also break under its
own complexity as the family grows.

If this is a case where there is a completely common
base bfin and each CPU model adds things to it, I would
probably lean to something like a base header file and
CPU model specific header file that includes the base
one and then adds on to it.

I see someone else replied to this message.  Hopefully
you all can make a suggestion based upon what the
bfin CPU model family is shaping up like.

We have spent a long time fighting back at similar
issues in the PowerPC port where it is hard to find
the common ground so making a good decision is
important to long term maintenance.

Without a lot other than experience on other architectures
to go by, I would lean to the second option -- a base
architecture .h and a model specific one.  It could even
be structured like this:

bfXXX.h
   + define feature flags
   include bfin shared header file
  add more definitions

Then BSPs include a specific bfXXX.h and the shared code
for maintenance is invisible to them.

\
--joel
> allan
>
>