Breaking a BSP out of RTEMS

Joel Sherrill joel.sherrill at OARcorp.com
Fri Dec 1 19:24:52 UTC 2000


OUTWATER ~ KEITH J /5G3110 wrote:
> 
> Greetings all -
> 
> I think I fit Chris Johns' definition of a person for whom a BSP external
> to RTEMS makes sense.
> 
> I have read his README in the bare BSP directory; is there any other
> documentation or readme's that describe how to move the BSP out of RTEMS?
> 
> I though I read somewhere on the list that eventualy all of the BSP will be
> moved out of kernel tree.  Is this true?

That's the plan.  Ralf and myself have been working on that.  All
ports except the PowerPC can now be built in a bare bsp configuration
that mimics a variant when building in multilib fashion.  This means
that everything in the current source tree is built except libcpu and
libbsp.  WIth the bare BSP targets, the tests are built but no attempt
is made to link them.

Ralf is making progress on getting the real multilib build
infrastructure
in place while I am trying to restructure the code itself to get rid
of dependencies.  The key idea is that knowing RTEMS_CPU_MODEL tells
you a LOT more about the CPU than does its multilib configuration. 
Things have to move to libcpu when they cross the line.

The advantage of this layout is clear.  After this is complete,
you will be able to treat RTEMS more like the C Library.  It can
be installed in the same way as the tools and is BSP independent.
BSPs are the glue between that library and the hardware.  Since
RTEMS is "always there" and not BSP dependent, things built using
it will no longer be BSP dependent.  This opens the door to
precompiled add-on libraries (Tcl, ncurses, zlib, MicroWindows, 
OmniOrb, etc, etc.).  This is not feasible now because they depend
on RTEMS and are thus BSP dependent.

>From a scheduling perspective... Ralf, like many others, is a 
pure volunteer and we all need to thank you repeatedly.  
Even my involvement in RTEMS is split between paid and volunteer.
If you want this to happen sooner, sponsoring Ralf and myself
to work on this full-time will definitely speed things up.

> Thanks,
> Keith
> 
> Keith Outwater
> Principal Engineer
> Raytheon Missile Systems
> Tucson, AZ
> 
> (520) 794-2518
> vac4050 at cae597.rsc.raytheon.com

-- 
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



More information about the users mailing list