definition of general terms, was: cpukit/bspkit split.

Wed Feb 23 07:44:56 UTC 2005

Hi,

> Ralf Corsepius <ralf.corsepius at rtems.org> writes:
> > On Tue, 2005-02-22 at 18:04 +0300, Sergei Organov wrote:
> > > 
> > > Now I tend to disagree in turn. What Thomas suggests is more natural
> > > place. Ask yourself a question: where would I put the code if the PIC is
> > > not integrated? The answer is: in libbsp. Right?
> >
> > Not necessarily. Implementing it under libbsp is just one possibility.
> 
> Too bad. It means RTEMS doesn't currently have obvious place to put IC
> code into.

Once again, I entered this discussion rather late, so maybe I 
missed a thing. But I think we all require some sort of 
clarification of terms and places. Especially the usage of the 
term "CPU" confuses me a bit. So let me start (maybe when the 
definitions have settled this should go to the WIKI):

-----------------------------------------------------
Terms:

Architecture:

a processor architecture (like m68k, powerpc, i386) defines a 
general set of properites (like instruction set, register set, 
general cache and MMU behaviour). A part of these properties 
might differ in each implementation of this architecture.

CORE:

a processor core is a well defined implementation of a certain 
architecture (like cpu32, ppc603e, 80486). Although this core 
might be integrated into various chips (you find a ppc603e built 
into a mpc8260, mpc5200 etc.), it always has the same properties 
from a software point of view.

CPU:

a CPU in the RTEMS way of speaking is a chip, which contains a 
processor core and possibly some or many peripheral functions, 
interrupt controller facilities and additional circuits. 
Examples are the MPC603 (a chip containing only the processor 
core) but also the MC68360 (QUICC) or mpc8260, which contain a 
processor core, memory controller, interrupt controllers, and 
serial/networking peripherals. (I personally would not call this 
a CPU, the terms "microcontroller" or SOC (System on Chip) would 
be more appropriate, but currently the term CPU seems to be 
settled for this). For a given complex CPU (like mpc8260), must 
boards might use the same software drivers for the integrated 
interfaces.

Board:

A board contains at least a CPU and some other units like bus 
interfaces, memory, other peripherals and/or interrupt 
controllers. 

------------------------------------------------------------
Places:
------------------------------------------------------------
RTEMS has various places for code, that is is adapted to  
architectures, cores, CPUs and boards (Ralf, I simply started to 
write things down as I think they are, would you please correct 
this, since you have much more background on this):

cpukit/score/cpu/<core>/ 

contains code that is/should be architecture specific but 
independent from the actual core implementation. Conditional 
statements might be neccesary to distinguish between core 
implementations. 

cpukit/ (except score/cpu/<core>) 

contains code that is totally architecture independent

c/src/lib/libcpu/<arch>/<cpu>/ 

contains code that is cpu dependent. It may contain code for 
integrated peripherals (like serial/networking drivers for 
MPC8260). It may contain code that is core specific (?).

c/src/lib/libbsp/<arch>/shared/

contains code for commonly used peripherals/interrupt 
controllers of a given architecture

c/src/lib/libbsp/<arch>/<board>/

contains code for a specific board, and the glue to put 
everything together (reference drivers from libchip, 
libbsp/<arch>/shared etc.)

c/src/libchip 

contains drivers, which can be shared between different 
architectures (like ide, some networking peripherals)

Any corrections welcome to this!

Currently, two things look a bit unstructured to me:

1.) c/src/lib/libcpu/<arch>/<cpu>/ is "CPU" dependent and there 
is no "Core" dependent directory. Therefore a MPC8620 uses a 
different directory than a MPC603e although the core specific 
code might be shared (like exceptions/, mmu/ etc). An additional 
hirarchy to contain core specific but cpu independent code 
really might help, something like lib/libcore/<arch>/<core>/ or 
lib/libcpu/<arch>/<core>

2.) The distinction between peripherals built on a chip (with 
drivers in libcpu) and peripherals built on a board (with 
drivers in libbsp) seems very arbitrary to me. Moveing these 
chip-specific drivers from libcpu somewhere to 
libbsp/<arch>/shared would seem more logical to me and would 
make libcpu/<arch> to only contain the core specific stuff, so 
this would solve point 1.) aswell.

Any opinions?

wkr,
Thomas.

> 
> > 
> > However, where is its API defined?
> 
> Good question.
> 
> > If either you implement a BSP specific API, then the BSP's headers is
> > the appropriate place, or you implement a cpu-family API. In this
> > case, a libcpu header is the appropriate location.
> 
> I believe I implement neither. I implement (non-existing) RTEMS
> interrupt API as applied to the particular IC. It has in fact little to
> do with particular CPU. Just imagine the day after tomorrow Motorola
> releases new MPC micro-controller that consists of mpc565 core and
> mpc8260 PIC. As for BSP, particular BSP should just select an
> appropriate IC code from those that are available. If there is no
> support for the IC the board contains, the BSP designer should implement
> the IC support in appropriate place in advance and then use it in the
> BSP.
> 
> > 
> > > Overall, my currently preferred suggestion is:
> > > 
> > > 1. Have exception management code in libcpu/shared.
> > > 2. Have interrupt management code in libbsp/shared.
> >
> > I am strongly opposed to implement anything below libbsp/shared or
> > libbsp/<cpu>/shared (I guess this is what you actually mean), because it
> > helps people to avoid thinking on APIs. Have a look at the currently
> > existing BSPs and how they use "<cpu>/shared".
> 
> Well, the contents of c/src/lib/libbsp/shared seems OK to me. What's a
> problem about it? Where do you think this code belongs?
> c/src/lib/libcpu/shared?
> 
> c/src/lib/libbsp/powerpc/shared... Hmm... The only somewhat relevant are
> 'start' and 'vectors' directories, but they well could be in
> c/src/libcpu/powerpc/shared instead, I think. I have absolutely no idea
> how to "share" (I mean reuse) the rest of contents of this, -- it all
> seems to be too dependent on particular CPU/board combination(s) to be
> reusable. Well, on the other hand people do need a place where to put
> code that is indeed shared between two or more supported BSPs.
> 
> Once again the above discussion shows that there is no clear
> understanding about how the code should be actually split between
> libraries and source directories. Everybody has his own opinion that has
> logical arguments behind it. It's too bad as it means developers will
> tend to put new code rather randomly depending on their own preferences
> and understanding.
> 
> -- 
> Sergei.

--------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at: http://www.imd-
systems.de/pgp_keys.htm