[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
definition of general terms, was: cpukit/bspkit split.
> Ralf Corsepius <firstname.lastname@example.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):
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.
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.
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
A board contains at least a CPU and some other units like bus
interfaces, memory, other peripherals and/or interrupt
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):
contains code that is/should be architecture specific but
independent from the actual core implementation. Conditional
statements might be neccesary to distinguish between core
cpukit/ (except score/cpu/<core>)
contains code that is totally architecture independent
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 (?).
contains code for commonly used peripherals/interrupt
controllers of a given architecture
contains code for a specific board, and the glue to put
everything together (reference drivers from 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
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.
> > 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
> > > 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/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.
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
PGP public key available at: http://www.imd-