change log for rtems (2011-05-23)
rtems-vc at rtems.org
rtems-vc at rtems.org
Mon May 23 16:13:56 UTC 2011
*joel*:
2011-05-23 Marta Rybczynska <marta.rybczynska at kalray.eu>
PR 1805/cpukit
* sapi/include/confdefs.h: Currently unified areas are defined
per-application. For some memory constrained and/or very dynamic
environments (BSPs), it may be better to have per-BSP default value.
This patch introduces such option. The default behaviour is left
unchanged.
M 1.2844 cpukit/ChangeLog
M 1.167 cpukit/sapi/include/confdefs.h
diff -u rtems/cpukit/ChangeLog:1.2843 rtems/cpukit/ChangeLog:1.2844
--- rtems/cpukit/ChangeLog:1.2843 Mon May 23 09:55:58 2011
+++ rtems/cpukit/ChangeLog Mon May 23 11:06:22 2011
@@ -1,3 +1,12 @@
+2011-05-23 Marta Rybczynska <marta.rybczynska at kalray.eu>
+
+ PR 1805/cpukit
+ * sapi/include/confdefs.h: Currently unified areas are defined
+ per-application. For some memory constrained and/or very dynamic
+ environments (BSPs), it may be better to have per-BSP default value.
+ This patch introduces such option. The default behaviour is left
+ unchanged.
+
2011-05-23 Joel Sherrill <joel.sherrilL at OARcorp.com>
PR 1804/cpukit
diff -u rtems/cpukit/sapi/include/confdefs.h:1.166 rtems/cpukit/sapi/include/confdefs.h:1.167
--- rtems/cpukit/sapi/include/confdefs.h:1.166 Mon May 23 09:55:58 2011
+++ rtems/cpukit/sapi/include/confdefs.h Mon May 23 11:06:23 2011
@@ -798,6 +798,12 @@
* combined provided one larger memory pool. This is particularly
* useful in combination with the unlimited objects configuration.
*/
+ #ifdef BSP_DEFAULT_UNIFIED_WORK_AREAS
+ #ifndef CONFIGURE_UNIFIED_WORK_AREAS
+ #define CONFIGURE_UNIFIED_WORK_AREAS
+ #endif
+ #endif
+
#ifdef CONFIGURE_UNIFIED_WORK_AREAS
#include <rtems/score/wkspace.h>
Heap_Control *RTEMS_Malloc_Heap = &_Workspace_Area;
*joel*:
2011-05-23 Joel Sherrill <joel.sherrilL at OARcorp.com>
* bsp_howto/support.t: Add section describing configuration macros
which may be defined at the BSP level to alter defaults in
rtems/confdefs.h.
M 1.311 doc/ChangeLog
M 1.8 doc/bsp_howto/support.t
diff -u rtems/doc/ChangeLog:1.310 rtems/doc/ChangeLog:1.311
--- rtems/doc/ChangeLog:1.310 Thu May 19 10:40:42 2011
+++ rtems/doc/ChangeLog Mon May 23 11:07:35 2011
@@ -1,3 +1,9 @@
+2011-05-23 Joel Sherrill <joel.sherrilL at OARcorp.com>
+
+ * bsp_howto/support.t: Add section describing configuration macros
+ which may be defined at the BSP level to alter defaults in
+ rtems/confdefs.h.
+
2011-05-19 Gedare Bloom <giddyup44 at yahoo.com>
* user/conf.t: Fix typos.
diff -u rtems/doc/bsp_howto/support.t:1.7 rtems/doc/bsp_howto/support.t:1.8
--- rtems/doc/bsp_howto/support.t:1.7 Wed Oct 14 08:08:39 2009
+++ rtems/doc/bsp_howto/support.t Mon May 23 11:07:35 2011
@@ -34,11 +34,11 @@
@end group
@end example
-The first section of this file renames the built-in definition of
+The first section of this file renames the built-in definition of
some specification variables so they can be augmented without
embedded their original definition. The subsequent sections
specify what behavior is expected when the @code{-qrtems} or
- at code{-qrtems_debug} option is specified.
+ at code{-qrtems_debug} option is specified.
The @code{*startfile} section specifies that the BSP specific file
@code{start.o} will be used instead of @code{crt0.o}. In addition,
@@ -61,7 +61,7 @@
describes the board and its hardware configuration, provides vendor
information, local configuration information, information on downloading
code to the board, debugging, etc.. The intent of this
-file is to help someone begin to use the BSP faster.
+file is to help someone begin to use the BSP faster.
A @code{README} file in a BSP subdirectory typically explains something
about the contents of that subdirectory in greater detail. For example,
@@ -98,10 +98,10 @@
@section bsp.h Include File
-The file @code{include/bsp.h} contains prototypes and definitions
+The file @code{include/bsp.h} contains prototypes and definitions
specific to this board. Every BSP is required to provide a @code{bsp.h}.
The best approach to writing a @code{bsp.h} is copying an existing one
-as a starting point.
+as a starting point.
Many @code{bsp.h} files provide prototypes of variables defined
in the linker script (@code{linkcmds}).
@@ -113,7 +113,7 @@
@itemize @bullet
@item @code{MUST_WAIT_FOR_INTERRUPT} - modifies behavior of @code{tm27}.
- at item @code{Install_tm27_vector} - installs the interrupt service
+ at item @code{Install_tm27_vector} - installs the interrupt service
routine for the Interrupt Benchmark Test (@code{tm27}).
@item @code{Cause_tm27_intr} - generates the interrupt source
@@ -179,6 +179,7 @@
BSP's Pretasking Hook but now the BSP Boot Card Framework can perform
this operation.
+ at findex CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
If your BSP does not want to support dynamic heap extension, then you do not have to do anything special. However, if you want to support @code{sbrk}, you must provide an implementation of this method and define @code{CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK} in @code{bsp.h}. This informs @code{rtems/confdefs.h} to configure the Malloc Family Extensions which support @code{sbrk}.
@section bsp_cleanup() - Cleanup the Hardware
@@ -201,6 +202,43 @@
using the boards in a development environment and may be disabled for
production use.
+ at section Configuration Macros
+
+Each BSP can define macros in bsp.h which alter some of the the default configuration parameters in @code{rtems/confdefs.h}. This section describes those macros:
+
+ at itemize @bullet
+
+ at findex CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
+ at item @code{CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK} must be defined if the
+BSP has proper support for @code{sbrk}. This is discussed in more detail
+in the previous section.
+
+ at findex BSP_IDLE_TASK_BODY
+ at item @code{BSP_IDLE_TASK_BODY} may be defined to the entry point of a
+BSP specific IDLE thread implementation. This may be overridden if the
+application provides its own IDLE task implementation.
+
+ at findex BSP_IDLE_TASK_STACK_SIZE
+ at item @code{BSP_IDLE_TASK_STACK_SIZE} may be defined to the desired
+default stack size for the IDLE task as recommended when using this BSP.
+
+ at findex BSP_INTERRUPT_STACK_SIZE
+ at item @code{BSP_INTERRUPT_STACK_SIZE} may be defined to the desired default interrupt stack size as recommended when using this BSP. This is sometimes required when the BSP developer has knowledge of stack intensive interrupt handlers.
+
+ at findex BSP_ZERO_WORKSPACE_AUTOMATICALLY
+ at item @code{BSP_ZERO_WORKSPACE_AUTOMATICALLY} is defined when the BSP
+requires that RTEMS zero out the RTEMS C Program Heap at initialization.
+If the memory is already zeroed out by a test sequence or boot ROM,
+then the boot time can be reduced by not zeroing memory twice.
+
+ at findex BSP_DEFAULT_UNIFIED_WORK_AREAS
+ at item @code{BSP_DEFAULT_UNIFIED_WORK_AREAS} is defined when the BSP
+recommends that the unified work areas configuration should always
+be used. This is desirable when the BSP is known to always have very
+little RAM and thus saving memory by any means is desirable.
+
+ at end itemize
+
@section set_vector() - Install an Interrupt Vector
On targets with Simple Vectored Interrupts, the BSP must provide
@@ -222,8 +260,8 @@
rtems_isr_entry handler, /* isr routine */
rtems_vector_number vector, /* vector number */
int type /* RTEMS or RAW intr */
-)
-@{
+)
+@{
if the type is RAW
install the raw vector
else
--
Generated by Deluxe Loginfo [http://www.codewiz.org/projects/index.html#loginfo] 2.122 by Bernardo Innocenti <bernie at develer.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/vc/attachments/20110523/2098f625/attachment-0001.html>
More information about the vc
mailing list