libcpu vs libbsp vs libchip wasRe: MPC555 BSP, Where to start?

[Joel Sherrill]

I ended up writing more than I thought so am putting this back 
on the list so it will get archived. :)

ahuitzot at mindspring.com wrote:
> 
> Just to make sure I have things streight, libcpu is where drivers for onchip
> stuff goes right?  

Right.  libcpu is the functionality on the CPU that is CPU model
specific.
For example, you couldhave a 603e core with a UART on it.  The 
CPU can share the 603e multilib and 603e cache/interrupt code in libcpu.
The UART code would be in libcpu as well since anyone with that CPU
would
want to use it.

The configure script in libcpu/powerpc would enable the appropriate
pieces for CPU model X.

> Or would that go in the BSP code?  

Only glue type code such as might be needed to let the libcpu code
know that you did some configuration that it could not detect.
Say you could put a resistor on a pin on the CPU model to say
16 vs 32 bit bus or something like that.  The general idea is that
the CPU model has some configurable options you as a board designer
get to choose.  The libcpu code accounts for the general behavior
of the CPU model and the libbsp code in this case accounts for
the board designer options.

> For example, if I wrote
> (or imported) code for the SCI, that would go in libcpu?  Possibly in an
> mpc5xx directory?

If it is on the CPU, then yes put it in libcpu.  If it is an off-cpu
peripheral, then the BSP or in libchip.  Remember that libchip has 
drivers for peripheral chips that can be "glued" to BSP specific
code just like the libcpu model.  You as a board designer choose
UART X and answer 12 questions.  The libchip driver needs those
12 questions answered by its BSP provided glue.

Ideally the BSP would contain no functionality that was not board
specific -- it would simply assemble pieces for the off the shelf
parts it is built plus whatever was required to glue it together.
That type of information is generally memory map, order of
initialization,
etc.

Sometimes a board is going to have a custom FPGA or other type of
part on it and that has to go in the BSP.  

> I do not have the code immediately available to look at, but I seem to
> remember it going this way?  (Ill be rebooting into linux in a bit to
> check...)

The general rule of thumb is that you want code to go as high in the
reuse food chain as possible.  

  + Fully portable
  + CPU architecture dependent
  + Component dependent
    - CPU model dependent
    - peripheral chip depdendent
  + Shareable between family of boards 
  + Board dependent

I hope this helps everyone.  The goal is to share your work with as
many people as possible and leverage as much work as possible. 
Ultimately,
it increases the number of users for each line of code and thus
reduces the maintenance burden.  Who wants every board to have its
own unique 16550 driver?
 
> Thanks,
> Mike
> 
> On Wed, 13 Nov 2002 10:12:47 -0600 "Joel Sherrill <joel at OARcorp.com>"
> <joel.sherrill at OARcorp.com> wrote:
> 
> > ahuitzot at mindspring.com wrote:
> > >
> > > I am working with an MPC555 based board (a
> > Phytec phyCORE MPC555 to be exact)
> > > and I am thinking about the possibility of
> > running RTEMS on it.  I was
> > > wondering where a good place to start would
> > be if I were to write a BSP for
> > > the MPC555 (assuming there isnt already one I
> > am not aware of...) and for the
> > > phyCORE board in particular.
> >
> > There is some 505 support in libcpu submitted a
> > long time ago and
> > based upon the 40x support.  Unless someone
> > dumps more code in your
> > lap, I would recommend taking one of the 8xx
> > CPUs/BSPs and turning it
> > into 555 support.  That gives you a model for
> > splitting code
> > between libcpu and the BSP specific issues.
> >
> > > At the moment the project only calls for a
> > simple loop and some ISR's to do
> > > the work, but I think eventually we will grow
> > into using an RTOS (possibly 3
> > > months or so from now, maybe sooner), and
> > RTEMS I think would be my choice (I
> > > have used it non professionally on a 68332
> > based SBC) so I want to figure out
> > > what my options are now, rather then at the
> > last minute :)
> > >
> > > Thanks,
> > > Mike
> >
> > --
> > Joel Sherrill, Ph.D.             Director of
> > Research & Development
> > joel at OARcorp.com                 On-Line
> > Applications Research
> > Ask me about RTEMS: a free RTOS  Huntsville AL
> > 35805
> >    Support Available             (256) 722-9985
> >

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