RTEMS 4.6.2 BSP support
Joel Sherrill <joel@OARcorp.com>
joel.sherrill at OARcorp.com
Fri Oct 22 12:08:47 UTC 2004
Thomas Doerfler wrote:
> apart from the comments of Joel and Ralf: Surely it
> is possible to extract the new BSPs from CVS and
> integrate them locally into the RTEMS 4.6.2 source
> tree, but this might require a lot of tinkering...
At this point, there have been mostly changes to:
+ reduce Makefiles from ~1400 -> ~400
+ eliminate trailing spaces in files
+ move c/src/tests to testsuites
+ transition to ISO C 99 types like int32_t
So the Makefile's have to be completely different
is the current biggest issue. The 1st and 3rd
make merging patches like the heap modifications
difficult (hint, hint .. please update those)
Other source issues will be creeping in...
+ Tiny RTEMS features like
- alternate 16 bit ID implementation
- configure lower number of priorities
- disable priority inheritance/ceiling
+ I am converting .h files to Doxygen
- SuperCore is probably 60+% complete
+ cleaner build of CPU Kit and BSP Kit so
binary release of CPU Kit is possible
So in theory it is possible but it is becoming harder
and harder depending upon where you are patching.
>>Haberhausen, Dierk wrote:
>>>one question about the new RTEMS 4.6.2 Release.
>>>In CVS the ARM BSP for the CSB336 and CSB337 Boards are available.
>>>Why are they not included in the new RTEMS 4.6.2?
>>In general, .Z revisions in any version X.Y.Z will NOT contain
>>new BSPs or functionalities. THis is because these are supposed
>>to be bug fix releases. Proactically something like a BSP into two
>>places is extra (unpaid) work.
>>There are two exceptions to this rule:
>> + NFS was added to the 4.6 series because it was in an Add-On
>> and had no impact on RTEMS itself.
>> + Rarely, someone will pay to get a BSP merged into both
>> a development tree and a release tree. This solves the
>> duplicate (unpaid) work part. The BSP has to have
>> virtually no impact outside its own BSP directory for this
>> to even be discussed. For a large highly CMed project,
>> this may be the only way they will use RTEMS -- to get a
>> formal release with their bug fixes and submitted BSP.
>>In general, Ralf's comments were correct -- bug fixes only.
>>At this point, there may have been only 1 or 2 cases where the
>>rule was bent.
>>Long term, I would like to see RTEMS be more like the Linux model
>>where a stable branch or even an older release gets new .z releases.
>>4.6 and 4.7 use versioned tools and special install locations to
>>make this easier. So it should be possible to support multiple
>>active release branches in the future if there is interest,
>>significant volunteering, and/or sponsorship.
>>There was a technical issue, now there is an issue of resources
>>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
> 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-
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