diff options
author | Joel Sherrill <joel@rtems.org> | 2016-11-15 10:37:59 -0600 |
---|---|---|
committer | Joel Sherrill <joel@rtems.org> | 2017-01-11 12:13:21 -0600 |
commit | 48a7fa31f918a6fc88719b3c9393a9ba2829f42a (patch) | |
tree | 10bf638de133099fcabe5fe713ca98a546a27ab2 /doc/user/bsp.t | |
parent | Remove obsolete __RTEMS_HAVE_SYS_CPUSET_H__ (diff) | |
download | rtems-48a7fa31f918a6fc88719b3c9393a9ba2829f42a.tar.bz2 |
Remove texinfo format documentation. Replaced by Sphinx formatted documentation.
closes #2812.
Diffstat (limited to '')
-rw-r--r-- | doc/user/bsp.t | 300 |
1 files changed, 0 insertions, 300 deletions
diff --git a/doc/user/bsp.t b/doc/user/bsp.t deleted file mode 100644 index 8af054a663..0000000000 --- a/doc/user/bsp.t +++ /dev/null @@ -1,300 +0,0 @@ -@c -@c COPYRIGHT (c) 1988-2008. -@c On-Line Applications Research Corporation (OAR). -@c All rights reserved. - -@chapter Board Support Packages - -@cindex Board Support Packages -@cindex BSPs - -@section Introduction - -@cindex BSP, definition - -A board support package (BSP) is a collection of -user-provided facilities which interface RTEMS and an -application with a specific hardware platform. These facilities -may include hardware initialization, device drivers, user -extensions, and a Multiprocessor Communications Interface -(MPCI). However, a minimal BSP need only support processor -reset and initialization and, if needed, a clock tick. - -@section Reset and Initialization - -An RTEMS based application is initiated or -re-initiated when the processor is reset. This initialization -code is responsible for preparing the target platform for the -RTEMS application. Although the exact actions performed by the -initialization code are highly processor and target dependent, -the logical functionality of these actions are similar across a -variety of processors and target platforms. - -Normally, the BSP and some of the application initialization is -intertwined in the RTEMS initialization sequence controlled by -the shared function @code{boot_card()}. - -The reset application initialization code is executed -first when the processor is reset. All of the hardware must be -initialized to a quiescent state by this software before -initializing RTEMS. When in quiescent state, devices do not -generate any interrupts or require any servicing by the -application. Some of the hardware components may be initialized -in this code as well as any application initialization that does -not involve calls to RTEMS directives. - -The processor's Interrupt Vector Table which will be used by the -application may need to be set to the required value by the reset -application initialization code. Because interrupts are enabled -automatically by RTEMS as part of the context switch to the first task, -the Interrupt Vector Table MUST be set before this directive is invoked -to ensure correct interrupt vectoring. The processor's Interrupt Vector -Table must be accessible by RTEMS as it will be modified by the when -installing user Interrupt Service Routines (ISRs) On some CPUs, RTEMS -installs it's own Interrupt Vector Table as part of initialization and -thus these requirements are met automatically. The reset code which is -executed before the call to any RTEMS initialization routines has the -following requirements: - -@itemize @bullet -@item Must not make any blocking RTEMS directive calls. - -@item If the processor supports multiple privilege levels, must leave -the processor in the most privileged, or supervisory, state. - -@item Must allocate a stack of sufficient size to execute the initialization -and shutdown of the system. This stack area will NOT be used by any task -once the system is initialized. This stack is often reserved via the -linker script or in the assembly language start up file. - -@item Must initialize the stack pointer for the initialization process to -that allocated. - -@item Must initialize the processor's Interrupt Vector Table. - -@item Must disable all maskable interrupts. - -@item If the processor supports a separate interrupt stack, must allocate -the interrupt stack and initialize the interrupt stack pointer. - -@end itemize - -At the end of the initialization sequence, RTEMS does not return to the -BSP initialization code, but instead context switches to the highest -priority task to begin application execution. This task is typically -a User Initialization Task which is responsible for performing both -local and global application initialization which is dependent on RTEMS -facilities. It is also responsible for initializing any higher level -RTEMS services the application uses such as networking and blocking -device drivers. - -@subsection Interrupt Stack Requirements - -The worst-case stack usage by interrupt service -routines must be taken into account when designing an -application. If the processor supports interrupt nesting, the -stack usage must include the deepest nest level. The worst-case -stack usage must account for the following requirements: - -@itemize @bullet -@item Processor's interrupt stack frame - -@item Processor's subroutine call stack frame - -@item RTEMS system calls - -@item Registers saved on stack - -@item Application subroutine calls -@end itemize - -The size of the interrupt stack must be greater than or equal to the -confugured minimum stack size. - -@subsection Processors with a Separate Interrupt Stack - -Some processors support a separate stack for interrupts. When an -interrupt is vectored and the interrupt is not nested, the processor -will automatically switch from the current stack to the interrupt stack. -The size of this stack is based solely on the worst-case stack usage by -interrupt service routines. - -The dedicated interrupt stack for the entire application on some -architectures is supplied and initialized by the reset and initialization -code of the user's Board Support Package. Whether allocated and -initialized by the BSP or RTEMS, since all ISRs use this stack, the -stack size must take into account the worst case stack usage by any -combination of nested ISRs. - -@subsection Processors Without a Separate Interrupt Stack - -Some processors do not support a separate stack for interrupts. In this -case, without special assistance every task's stack must include -enough space to handle the task's worst-case stack usage as well as -the worst-case interrupt stack usage. This is necessary because the -worst-case interrupt nesting could occur while any task is executing. - -On many processors without dedicated hardware managed interrupt stacks, -RTEMS manages a dedicated interrupt stack in software. If this capability -is supported on a CPU, then it is logically equivalent to the processor -supporting a separate interrupt stack in hardware. - -@section Device Drivers - -Device drivers consist of control software for -special peripheral devices and provide a logical interface for -the application developer. The RTEMS I/O manager provides -directives which allow applications to access these device -drivers in a consistent fashion. A Board Support Package may -include device drivers to access the hardware on the target -platform. These devices typically include serial and parallel -ports, counter/timer peripherals, real-time clocks, disk -interfaces, and network controllers. - -For more information on device drivers, refer to the -I/O Manager chapter. - -@subsection Clock Tick Device Driver - -Most RTEMS applications will include a clock tick -device driver which invokes the @code{@value{DIRPREFIX}clock_tick} -directive at regular intervals. The clock tick is necessary if -the application is to utilize timeslicing, the clock manager, the -timer manager, the rate monotonic manager, or the timeout option on blocking -directives. - -The clock tick is usually provided as an interrupt from a counter/timer -or a real-time clock device. When a counter/timer is used to provide the -clock tick, the device is typically programmed to operate in continuous -mode. This mode selection causes the device to automatically reload the -initial count and continue the countdown without programmer intervention. -This reduces the overhead required to manipulate the counter/timer in -the clock tick ISR and increases the accuracy of tick occurrences. -The initial count can be based on the microseconds_per_tick field -in the RTEMS Configuration Table. An alternate approach is to set -the initial count for a fixed time period (such as one millisecond) -and have the ISR invoke @code{@value{DIRPREFIX}clock_tick} on the -configured @code{microseconds_per_tick} boundaries. Obviously, this -can induce some error if the configured @code{microseconds_per_tick} -is not evenly divisible by the chosen clock interrupt quantum. - -It is important to note that the interval between -clock ticks directly impacts the granularity of RTEMS timing -operations. In addition, the frequency of clock ticks is an -important factor in the overall level of system overhead. A -high clock tick frequency results in less processor time being -available for task execution due to the increased number of -clock tick ISRs. - -@section User Extensions - -RTEMS allows the application developer to augment -selected features by invoking user-supplied extension routines -when the following system events occur: - -@itemize @bullet -@item Task creation -@item Task initiation -@item Task reinitiation -@item Task deletion -@item Task context switch -@item Post task context switch -@item Task begin -@item Task exits -@item Fatal error detection -@end itemize - -User extensions can be used to implement a wide variety of -functions including execution profiling, non-standard -coprocessor support, debug support, and error detection and -recovery. For example, the context of a non-standard numeric -coprocessor may be maintained via the user extensions. In this -example, the task creation and deletion extensions are -responsible for allocating and deallocating the context area, -the task initiation and reinitiation extensions would be -responsible for priming the context area, and the task context -switch extension would save and restore the context of the -device. - -For more information on user extensions, refer to the -@ref{User Extensions Manager} chapter. - -@section Multiprocessor Communications Interface (MPCI) - -RTEMS requires that an MPCI layer be provided when a -multiple node application is developed. This MPCI layer must -provide an efficient and reliable communications mechanism -between the multiple nodes. Tasks on different nodes -communicate and synchronize with one another via the MPCI. Each -MPCI layer must be tailored to support the architecture of the -target platform. - -For more information on the MPCI, refer to the -Multiprocessing Manager chapter. - -@subsection Tightly-Coupled Systems - -A tightly-coupled system is a multiprocessor -configuration in which the processors communicate solely via -shared global memory. The MPCI can simply place the RTEMS -packets in the shared memory space. The two primary -considerations when designing an MPCI for a tightly-coupled -system are data consistency and informing another node of a -packet. - -The data consistency problem may be solved using -atomic "test and set" operations to provide a "lock" in the -shared memory. It is important to minimize the length of time -any particular processor locks a shared data structure. - -The problem of informing another node of a packet can -be addressed using one of two techniques. The first technique -is to use an interprocessor interrupt capability to cause an -interrupt on the receiving node. This technique requires that -special support hardware be provided by either the processor -itself or the target platform. The second technique is to have -a node poll for arrival of packets. The drawback to this -technique is the overhead associated with polling. - -@subsection Loosely-Coupled Systems - -A loosely-coupled system is a multiprocessor -configuration in which the processors communicate via some type -of communications link which is not shared global memory. The -MPCI sends the RTEMS packets across the communications link to -the destination node. The characteristics of the communications -link vary widely and have a significant impact on the MPCI -layer. For example, the bandwidth of the communications link -has an obvious impact on the maximum MPCI throughput. - -The characteristics of a shared network, such as -Ethernet, lend themselves to supporting an MPCI layer. These -networks provide both the point-to-point and broadcast -capabilities which are expected by RTEMS. - -@subsection Systems with Mixed Coupling - -A mixed-coupling system is a multiprocessor -configuration in which the processors communicate via both -shared memory and communications links. A unique characteristic -of mixed-coupling systems is that a node may not have access to -all communication methods. There may be multiple shared memory -areas and communication links. Therefore, one of the primary -functions of the MPCI layer is to efficiently route RTEMS -packets between nodes. This routing may be based on numerous -algorithms. In addition, the router may provide alternate -communications paths in the event of an overload or a partial -failure. - -@subsection Heterogeneous Systems - -Designing an MPCI layer for a heterogeneous system -requires special considerations by the developer. RTEMS is -designed to eliminate many of the problems associated with -sharing data in a heterogeneous environment. The MPCI layer -need only address the representation of thirty-two (32) bit -unsigned quantities. - -For more information on supporting a heterogeneous -system, refer the Supporting Heterogeneous Environments in the -Multiprocessing Manager chapter. |