RTOS/rtems
1
0
Fork 0
forked from Imagelibrary/rtems
Code Pull Requests Activity

Merged changes from 4.5 branch and removed that branch.

Browse Source
This commit is contained in:
Joel Sherrill
2000-04-25 13:15:14 +00:00
parent 0765f9be43
commit bb4b574983
11 changed files with 152 additions and 47 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/Make.config
View File

@@ -4,12 +4,12 @@
# $Id$
#
RTEMS_VERSION=4.5-beta1b
RTEMS_VERSION=4.5-beta2
#DOC_INSTALL_BASE=/usr1/rtems/tmp/rtemsdoc-$(RTEMS_VERSION)
DOC_INSTALL_BASE=/home/httpd/html/rtems/rtemsdoc-$(RTEMS_VERSION)
# DOC_INSTALL_BASE=/home/httpd/html/rtems/doc/rtems
SRCDIR=/usr1/rtems/rtemsdoc-work
SRCDIR=/usr1/rtems/4.5-work/rtems-doc
BMENU=$(SRCDIR)/tools/bmenu/bmenu
PDL2TEXI=$(SRCDIR)/tools/pdl2texi/pdl2texi

8
doc/common/setup.texi
View File

@@ -10,11 +10,11 @@
@c Set Variables
@c
@set RTEMS-RELEASE 4.5-beta1b
@set RTEMS-RELEASE 4.5-beta2
@set RTEMS-EDITION 1
@set RTEMS-VERSION 4.5-beta1b
@set RTEMS-UPDATE-DATE February 23 2000
@set RTEMS-UPDATE-MONTH February 2000
@set RTEMS-VERSION 4.5-beta2
@set RTEMS-UPDATE-DATE April 13 2000
@set RTEMS-UPDATE-MONTH April 2000
@c
@c The following determines which set of the tables and figures we will use.

34
doc/porting/interrupts.t
View File

@@ -193,7 +193,7 @@ NOTE: This should be TRUE is CPU_HAS_SOFTWARE_INTERRUPT_STACK is TRUE.
#define CPU_ALLOCATE_INTERRUPT_STACK TRUE
@end example
If the CPU_HAS_SOFTWARE_INTERRUPT_STACK macro is set to TRUE, then RTEMS automatically allocates the stack memory in the initialization of the Interrupt Manager and the switch to that stack is performed in _ISR_Handler on the outermost interrupt. The _CPU_Interrupt_stack_low and _CPU_Interrupt_stack_high variables contain the addresses of the the lowest and highest addresses of the memory allocated for the interrupt stack. Although technically only one of these addresses is required to switch to the interrupt stack, by always providing both addresses, the port has more options avaialble to it without requiring modifications to the portable parts of the executive. Whether the stack grows up or down, this give the CPU dependent code the option of picking the version it wants to use.
If the CPU_HAS_SOFTWARE_INTERRUPT_STACK macro is set to TRUE, then RTEMS automatically allocates the stack memory in the initialization of the Interrupt Manager and the switch to that stack is performed in @code{_ISR_Handler} on the outermost interrupt. The _CPU_Interrupt_stack_low and _CPU_Interrupt_stack_high variables contain the addresses of the the lowest and highest addresses of the memory allocated for the interrupt stack. Although technically only one of these addresses is required to switch to the interrupt stack, by always providing both addresses, the port has more options avaialble to it without requiring modifications to the portable parts of the executive. Whether the stack grows up or down, this give the CPU dependent code the option of picking the version it wants to use.
@example
SCORE_EXTERN void *_CPU_Interrupt_stack_low;
@@ -283,7 +283,7 @@ _CPU_ISR_install_raw_handler( vector, new_handler, old_handler );
@end example
We put the actual user ISR address in _ISR_vector_table. This will be
used by the _ISR_Handler so the user gets control.
used by the @code{_ISR_Handler} so the user gets control.
@example
_ISR_Vector_table[ vector ] = new_handler;
@@ -312,7 +312,7 @@ typedef struct @{
@subsection Interrupt Dispatching
The _ISR_Handler routine provides the RTEMS interrupt management.
The @code{_ISR_Handler} routine provides the RTEMS interrupt management.
@example
void _ISR_Handler()
@@ -326,18 +326,26 @@ allowing the ISR to preserve only those that would normally be corrupted
by a subroutine call.
Also note that the exact order is to a large extent flexible. Hardware
will dictate a sequence for a certain subset of _ISR_Handler while
will dictate a sequence for a certain subset of @code{_ISR_Handler} while
requirements for setting the RTEMS state variables that indicate the
interrupt nest level (XX) and dispatching disable level (XXX) will also
interrupt nest level (@code{_ISR_Nest_level}) and dispatching disable
level (@code{_Thread_Dispatch_disable_level}) will also
restrict the allowable order.
Upon entry to the "common" _ISR_Handler, the vector number must be
Upon entry to @code{_ISR_Handler}, @code{_Thread_Dispatch_disable_level} is
zero if the interrupt occurred while outside an RTEMS service call.
Conversely, it will be non-zero if interrupting an RTEMS service
call. Thus, @code{_Thread_Dispatch_disable_level} will always be
greater than or equal to @code{_ISR_Nest_level} and not strictly
equal.
Upon entry to the "common" @code{_ISR_Handler}, the vector number must be
available. On some CPUs the hardware puts either the vector number or the
offset into the vector table for this ISR in a known place. If the
hardware does not provide this information, then the assembly portion of
RTEMS for this port will contain a set of distinct interrupt entry points
which somehow place the vector number in a known place (which is safe if
another interrupt nests this one) and branches to _ISR_Handler.
another interrupt nests this one) and branches to @code{_ISR_Handler}.
@example
save some or all context on stack
@@ -361,9 +369,10 @@ if ( !_Context_Switch_necessary )
goto the label "exit interrupt (simple case)"
if ( !_ISR_Signals_to_thread_executing )
_ISR_Signals_to_thread_executing = FALSE;
goto the label "exit interrupt (simple case)"
_ISR_Signals_to_thread_executing = FALSE;
call _Thread_Dispatch() or prepare to return to _ISR_Dispatch
prepare to get out of interrupt
return from interrupt (maybe to _ISR_Dispatch)
@@ -372,6 +381,15 @@ LABEL "exit interrupt (simple case):
prepare to get out of interrupt
return from interrupt
@end example
Some ports have the special routine @code{_ISR_Dispatch} because
the CPU has a special "interrupt mode" and RTEMS must switch back
to the task stack and/or non-interrupt mode before invoking
@code{_Thread_Dispatch}. For example, consider the MC68020 where
upon return from the outermost interrupt, the CPU must switch
from the interrupt stack to the master stack before invoking
@code{_Thread_Dispatch}. @code{_ISR_Dispatch} is the special port
specific wrapper for @code{_Thread_Dispatch} used in this case.
@subsection ISR Invoked with Frame Pointer

43
doc/porting/prioritybitmap.t
View File

@@ -27,9 +27,26 @@ ready task at that priority. The bit array can be efficiently searched to
determine the highest priority ready task. This family of data type and
routines is used to maintain and search the bit map array.
When manipulating the bitmap array, RTEMS internally divides the
8 bits of the task priority into "major" and "minor" components.
The most significant 4 bits are the major component, while the least
significant are the minor component. The major component of a priority
value is used to determine which 16-bit wide entry in the
@code{_Priority_Bit_map} array is associated with this priority.
Each element in the @code{_Priority_Bit_map} array has a bit
in the @code{_Priority_Major_bit_map} associated with it.
That bit is cleared when all of the bits in a particular
@code{_Priority_Bit_map} array entry are zero.
The minor component of a priority is used to determine
specifically which bit in @code{_Priority_Bit_map[major]}
indicates whether or not there is a ready to execute task
at the priority.
@section _Priority_Bit_map_control Type
The _Priority_Bit_map_Control type is the fundamental data type of the
The @code{_Priority_Bit_map_Control} type is the fundamental data type of the
priority bit map array used to determine which priorities have ready
tasks. This type may be either 16 or 32 bits wide although only the 16
least significant bits will be used. The data type is based upon what is
@@ -41,8 +58,8 @@ instruction.
@section Find First Bit Routine
The _CPU_Bitfield_Find_first_bit routine sets _output to the bit number of
the first bit set in _value. _value is of CPU dependent type
Priority_Bit_map_control. A stub version of this routine is as follows:
the first bit set in @code{_value}. @code{_value} is of CPU dependent type
@code{Priority_Bit_map_control}. A stub version of this routine is as follows:
@example
#define _CPU_Bitfield_Find_first_bit( _value, _output ) \
@@ -51,6 +68,8 @@ Priority_Bit_map_control. A stub version of this routine is as follows:
@}
@end example
There are a number of variables in using a "find first bit" type
instruction.
@@ -69,7 +88,7 @@ instruction.
RTEMS guarantees that (1) will never happen so it is not a concern.
Cases (2),(3), (4) are handled by the macros _CPU_Priority_mask() and
_CPU_Priority_bits_index(). These three form a set of routines which must
logically operate together. Bits in the _value are set and cleared based
logically operate together. Bits in the @code{_value} are set and cleared based
on masks built by CPU_Priority_mask(). The basic major and minor values
calculated by _Priority_Major() and _Priority_Minor() are "massaged" by
_CPU_Priority_bits_index() to properly range between the values returned
@@ -154,7 +173,21 @@ _CPU_Bitfield_Find_first_bit searches for the most significant bit set:
@section Bit Scan Support
The _CPU_Priority_bits_index routine translates the bit numbers returned by _CPU_Bitfield_Find_first_bit() into something suitable for use as a major or minor component of a priority. For example, the find first bit routine may number the bits in a way that is difficult to map into the major and minor components of the priority. This routine allows that unwieldy form to be converted into something easier to process. See the discussion of that routine for more details.
The @code{_CPU_Priority_bits_index} routine translates the bit numbers
returned by @code{_CPU_Bitfield_Find_first_bit()} into something
suitable for use as a major or minor component of a priority.
The find first bit routine may number the bits in a
way that is difficult to map into the major and minor components
of the priority. For example, when finding the first bit set in
the value 0x8000, a CPU may indicate that bit 15 or 16 is set
based on whether the least significant bit is "zero" or "one".
Similarly, a CPU may only scan 32-bit values and consider the
most significant bit to be bit zero or one. In this case, this
would be bit 16 or 17.
This routine allows that unwieldy form to be converted
into a normalized form that is easier to process and use
as an index.
@example
#if (CPU_USE_GENERIC_BITFIELD_CODE == FALSE)

57
doc/porting/taskcontext.t
View File

@@ -169,13 +169,27 @@ void _CPU_Context_Initialize(
);
@end example
This is_fp parameter is TRUE if the thread is to be a floating point
The @code{is_fp} parameter is TRUE if the thread is to be a floating point
thread. This is typically only used on CPUs where the FPU may be easily
disabled by software such as on the SPARC where the PSR contains an enable
FPU bit. The use of an FPU enable bit allows RTEMS to ensure that a
non-floating point task is unable to access the FPU. This guarantees that
a deferred floating point context switch is safe.
The @code{_stack_base} parameter is the base address of the memory area
allocated for use as the task stack. It is critical to understand that
@code{_stack_base} may not be the starting stack pointer for this task.
On CPU families where the stack grows from high addresses to lower ones,
(i.e. @code{CPU_STACK_GROWS_UP} is FALSE) the starting stack point
will be near the end of the stack memory area or close to
@code{_stack_base} + @code{_size}. Even on CPU families where the stack
grows from low to higher addresses, there may be some required
outermost stack frame that must be put at the address @code{_stack_base}.
The @code{_size} parameter is the requested size in bytes of the stack for
this task. It is assumed that the memory area @code{_stack_base}
is of this size.
XXX explain other parameters and check prototype
@subsection Performing a Context Switch
@@ -190,6 +204,47 @@ void _CPU_Context_switch(
);
@end example
This routine begins by saving the current state of the
CPU (i.e. the context) in the context area at @code{run}.
Then the routine should load the CPU context pointed to
by @code{heir}. Loading the new context will cause a
branch to its task code, so the task that invoked
@code{_CPU_Context_switch} will not run for a while.
When, eventually, a context switch is made to load
context from @code{*run} again, this task will resume
and @code{_CPU_Context_switch} will return to its caller.
Care should be exercise when writing this routine. All
registers assumed to be preserved across subroutine calls
must be preserved. These registers may be saved in
the task's context area or on its stack. However, the
stack pointer and address to resume executing the task
at must be included in the context (normally the subroutine
return address to the caller of @code{_Thread_Dispatch}.
The decision of where to store the task's context is based
on numerous factors including the capabilities of
the CPU architecture itself and simplicity as well
as external considerations such as debuggers wishing
to examine a task's context. In this case, it is
often simpler to save all data in the context area.
Also there may be special considerations
when loading the stack pointers or interrupt level of the
incoming task. Independent of CPU specific considerations,
if some context is saved on the task stack, then the porter
must ensure that the stack pointer is adjusted @b{BEFORE}
to make room for this context information before the
information is written. Otherwise, an interrupt could
occur writing over the context data. The following is
an example of an @b{INCORRECT} sequence:
@example
save part of context beyond current top of stack
interrupt pushes context -- overwriting written context
interrupt returns
adjust stack pointer
@end example
@subsection Restoring a Context
The _CPU_Context_restore routine is generally used only to restart the

9
doc/started/gdb.t
View File

@@ -67,15 +67,6 @@ find . -name "*.rej" -print
If any files are found with the .rej extension, a patch has been rejected.
This should not happen with a good patch file.
To see the files that have been modified use the sequence:
@example
cd tools/@value{GDB-UNTAR}
find . -name "*.orig" -print
@end example
The files that are found, have been modified by the patch file.
@end ifset
@section Using the bit_gdb script

13
doc/started/intro.t
View File

@@ -127,13 +127,14 @@ use to RTEMS users.
@subsection RTEMS Mailing List
rtems-list@@OARcorp.com
rtems-users@@OARcorp.com
This mailing list is dedicated to discussion of issues related
to RTEMS. If you have questions about RTEMS, wish to make
suggestions, or just want to pick up hints, this is a good
list to subscribe to. Subscribe by sending a message with
the one line "subscribe" to rtems-list-request@@OARcorp.com.
This mailing list is dedicated to the discussion of issues related
to RTEMS, including GNAT/RTEMS. If you have questions about RTEMS,
wish to make suggestions, or just want to pick up hints, this is a
good list to subscribe to. Subscribe by sending an empty mail
message to rtems-users-subscribe@@OARcorp.com. Messages sent
to rtems-users@@OARcorp.com are posted to the list.
@subsection CrossGCC Mailing List

7
doc/started/sample.t
View File

@@ -36,9 +36,12 @@ Use the following command to start the build of the sample application:
@example
cd tools/hello_world_c
gmake
make
@end example
NOTE: GNU make is the preferred @code{make} utility. Other @code{make}
implementations may work but all testing is done with GNU make.
If no errors are detected during the sample application build, it is
reasonable to assume that the build of the GNU C/C++ Cross Compiler Tools
for RTEMS and RTEMS itself for the selected host and target
@@ -50,7 +53,7 @@ If the sample application has successfully been build, then the application
executable is placed in the following directory:
@example
tools/hello_world_c/o-<BOARD_SUPPORT_PACKAGE>/<filename>.exe
tools/hello_world_c/o-optimize/<filename>.exe
@end example
How this executable is downloaded to the target board is very dependent

13
doc/started_ada/intro.t
View File

@@ -127,13 +127,14 @@ use to GNAT/RTEMS users.
@subsection RTEMS Mailing List
rtems-list@@OARcorp.com
rtems-users@@OARcorp.com
This mailing list is dedicated to discussion of issues related
to RTEMS. If you have questions about RTEMS, wish to make
suggestions, or just want to pick up hints, this is a good
list to subscribe to. Subscribe by sending a message with
the one line "subscribe" to rtems-list-request@@OARcorp.com.
This mailing list is dedicated to the discussion of issues related
to RTEMS, including GNAT/RTEMS. If you have questions about RTEMS,
wish to make suggestions, or just want to pick up hints, this is a
good list to subscribe to. Subscribe by sending an empty mail
message to rtems-users-subscribe@@OARcorp.com. Messages sent
to rtems-users@@OARcorp.com are posted to the list.
@subsection CrossGCC Mailing List

7
doc/started_ada/sample.t
View File

@@ -32,9 +32,12 @@ Use the following command to start the build of the sample application:
@example
cd tools/hello_world_ada
gmake -f Makefile.<BOARD_SUPPORT_PACKAGE>
make -f Makefile.<BOARD_SUPPORT_PACKAGE>
@end example
NOTE: GNU make is the preferred @code{make} utility. Other @code{make}
implementations may work but all testing is done with GNU make.
If the BSP specific modifications to the Makefile were correct and
no errors are detected during the sample application build, it is
reasonable to assume that the build of the GNAT/RTEMS Cross Compiler Tools
@@ -47,7 +50,7 @@ If the sample application has successfully been build, then the application
executable is placed in the following directory:
@example
tools/hello_world_ada/o-<BOARD_SUPPORT_PACKAGE>/<filename>.exe
tools/hello_world_ada/o-optimize/<filename>.exe
@end example
How this executable is downloaded to the target board is very dependent

4
doc/user/sem.t
View File

@@ -193,7 +193,7 @@ the set of valid semaphore attributes:
@item @code{@value{RPREFIX}COUNTING_SEMAPHORE} - no restriction on values
@item @code{@value{RPREFIX}SIMPLE_BINARY_SEMAPHORE} - restrict values to
0 and 1 and do not allow nested access.
0 and 1, do not allow nested access, allow deletion of locked semaphore.
@item @code{@value{RPREFIX}NO_INHERIT_PRIORITY} - do not use priority
inheritance (default)
@@ -452,7 +452,7 @@ defined by RTEMS:
@item @code{@value{RPREFIX}COUNTING_SEMAPHORE} - no restriction on values
@item @code{@value{RPREFIX}SIMPLE_BINARY_SEMAPHORE} - restrict values to
0 and 1 and do not allow nested access.
0 and 1, block on nested access, allow deletion of locked semaphore.
@item @code{@value{RPREFIX}NO_INHERIT_PRIORITY} - do not use priority
inheritance (default)