+++ /dev/null
-<!-- Copyright (C) 2003 Red Hat, Inc. -->
-<!-- This material may be distributed only subject to the terms -->
-<!-- and conditions set forth in the Open Publication License, v1.0 -->
-<!-- or later (the latest version is presently available at -->
-<!-- http://www.opencontent.org/openpub/). -->
-<!-- Distribution of the work or derivative of the work in any -->
-<!-- standard (paper) book form is prohibited unless prior -->
-<!-- permission is obtained from the copyright holder. -->
-<HTML
-><HEAD
-><TITLE
->SMP Support</TITLE
-><meta name="MSSmartTagsPreventParsing" content="TRUE">
-<META
-NAME="GENERATOR"
-CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
-"><LINK
-REL="HOME"
-TITLE="eCos Reference Manual"
-HREF="ecos-ref.html"><LINK
-REL="UP"
-TITLE="HAL Interfaces"
-HREF="hal-interfaces.html"><LINK
-REL="PREVIOUS"
-TITLE="Diagnostic Support"
-HREF="hal-diagnostic-support.html"><LINK
-REL="NEXT"
-TITLE="Exception Handling"
-HREF="hal-exception-handling.html"></HEAD
-><BODY
-CLASS="SECTION"
-BGCOLOR="#FFFFFF"
-TEXT="#000000"
-LINK="#0000FF"
-VLINK="#840084"
-ALINK="#0000FF"
-><DIV
-CLASS="NAVHEADER"
-><TABLE
-SUMMARY="Header navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TH
-COLSPAN="3"
-ALIGN="center"
->eCos Reference Manual</TH
-></TR
-><TR
-><TD
-WIDTH="10%"
-ALIGN="left"
-VALIGN="bottom"
-><A
-HREF="hal-diagnostic-support.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="80%"
-ALIGN="center"
-VALIGN="bottom"
->Chapter 9. HAL Interfaces</TD
-><TD
-WIDTH="10%"
-ALIGN="right"
-VALIGN="bottom"
-><A
-HREF="hal-exception-handling.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-></TABLE
-><HR
-ALIGN="LEFT"
-WIDTH="100%"></DIV
-><DIV
-CLASS="SECTION"
-><H1
-CLASS="SECTION"
-><A
-NAME="HAL-SMP-SUPPORT">SMP Support</H1
-><P
->eCos contains support for limited Symmetric Multi-Processing
-(SMP). This is only available on selected architectures and platforms.</P
-><DIV
-CLASS="SECTION"
-><H2
-CLASS="SECTION"
-><A
-NAME="AEN8275">Target Hardware Limitations</H2
-><P
->To allow a reasonable implementation of SMP, and to reduce the
-disruption to the existing source base, a number of assumptions have
-been made about the features of the target hardware.</P
-><P
-></P
-><UL
-><LI
-><P
->Modest multiprocessing. The typical number of CPUs supported is two
-to four, with an upper limit around eight. While there are no
-inherent limits in the code, hardware and algorithmic limitations
-will probably become significant beyond this point.</P
-></LI
-><LI
-><P
->SMP synchronization support. The hardware must supply a mechanism to
-allow software on two CPUs to synchronize. This is normally provided
-as part of the instruction set in the form of test-and-set,
-compare-and-swap or load-link/store-conditional instructions. An
-alternative approach is the provision of hardware semaphore
-registers which can be used to serialize implementations of these
-operations. Whatever hardware facilities are available, they are
-used in eCos to implement spinlocks.</P
-></LI
-><LI
-><P
->Coherent caches. It is assumed that no extra effort will be required
-to access shared memory from any processor. This means that either
-there are no caches, they are shared by all processors, or are
-maintained in a coherent state by the hardware. It would be too
-disruptive to the eCos sources if every memory access had to be
-bracketed by cache load/flush operations. Any hardware that requires
-this is not supported.</P
-></LI
-><LI
-><P
->Uniform addressing. It is assumed that all memory that is
-shared between CPUs is addressed at the same location from all
-CPUs. Like non-coherent caches, dealing with CPU-specific address
-translation is considered too disruptive to the eCos source
-base. This does not, however, preclude systems with non-uniform
-access costs for different CPUs.</P
-></LI
-><LI
-><P
->Uniform device addressing. As with access to memory, it is assumed
-that all devices are equally accessible to all CPUs. Since device
-access is often made from thread contexts, it is not possible to
-restrict access to device control registers to certain CPUs, since
-there is currently no support for binding or migrating threads to CPUs.</P
-></LI
-><LI
-><P
->Interrupt routing. The target hardware must have an interrupt
-controller that can route interrupts to specific CPUs. It is
-acceptable for all interrupts to be delivered to just one CPU, or
-for some interrupts to be bound to specific CPUs, or for some
-interrupts to be local to each CPU. At present dynamic routing,
-where a different CPU may be chosen each time an interrupt is
-delivered, is not supported. ECos cannot support hardware where all
-interrupts are delivered to all CPUs simultaneously with the
-expectation that software will resolve any conflicts.</P
-></LI
-><LI
-><P
->Inter-CPU interrupts. A mechanism to allow one CPU to interrupt
-another is needed. This is necessary so that events on one CPU can
-cause rescheduling on other CPUs.</P
-></LI
-><LI
-><P
->CPU Identifiers. Code running on a CPU must be able to determine
-which CPU it is running on. The CPU Id is usually provided either in
-a CPU status register, or in a register associated with the
-inter-CPU interrupt delivery subsystem. ECos expects CPU Ids to be
-small positive integers, although alternative representations, such
-as bitmaps, can be converted relatively easily. Complex mechanisms
-for getting the CPU Id cannot be supported. Getting the CPU Id must
-be a cheap operation, since it is done often, and in performance
-critical places such as interrupt handlers and the scheduler.</P
-></LI
-></UL
-></DIV
-><DIV
-CLASS="SECTION"
-><H2
-CLASS="SECTION"
-><A
-NAME="AEN8295">HAL Support</H2
-><P
->SMP support in any platform depends on the HAL supplying the
-appropriate operations. All HAL SMP support is defined in the
-<TT
-CLASS="FILENAME"
->cyg/hal/hal_smp.h</TT
-> header. Variant and platform
-specific definitions will be in <TT
-CLASS="FILENAME"
->cyg/hal/var_smp.h</TT
->
-and <TT
-CLASS="FILENAME"
->cyg/hal/plf_smp.h</TT
-> respectively. These files
-are include automatically by this header, so need not be included
-explicitly.</P
-><P
->SMP support falls into a number of functional groups.</P
-><DIV
-CLASS="SECTION"
-><H3
-CLASS="SECTION"
-><A
-NAME="AEN8302">CPU Control</H3
-><P
->This group consists of descriptive and control macros for managing the
-CPUs in an SMP system.</P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_TYPE</TT
-></DT
-><DD
-><P
->A type that can contain a CPU id. A CPU id is
-usually a small integer that is used to index
-arrays of variables that are managed on an
-per-CPU basis.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_MAX</TT
-></DT
-><DD
-><P
->The maximum number of CPUs that can be
-supported. This is used to provide the size of
-any arrays that have an element per CPU.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_COUNT()</TT
-></DT
-><DD
-><P
->Returns the number of CPUs currently
-operational. This may differ from
-HAL_SMP_CPU_MAX depending on the runtime
-environment.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_THIS()</TT
-></DT
-><DD
-><P
->Returns the CPU id of the current CPU.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_NONE</TT
-></DT
-><DD
-><P
->A value that does not match any real CPU
-id. This is uses where a CPU type variable
-must be set to a null value.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_START( cpu )</TT
-></DT
-><DD
-><P
->Starts the given CPU executing at a defined
-HAL entry point. After performing any HAL
-level initialization, the CPU calls up into
-the kernel at <TT
-CLASS="FUNCTION"
->cyg_kernel_cpu_startup()</TT
->.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_RESCHEDULE_INTERRUPT( cpu, wait )</TT
-></DT
-><DD
-><P
->Sends the CPU a reschedule interrupt, and if
-<TT
-CLASS="PARAMETER"
-><I
->wait</I
-></TT
-> is non-zero, waits for an
-acknowledgment. The interrupted CPU should call
-<TT
-CLASS="FUNCTION"
->cyg_scheduler_set_need_reschedule()</TT
-> in its DSR to
-cause the reschedule to occur.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_CPU_TIMESLICE_INTERRUPT( cpu, wait )</TT
-></DT
-><DD
-><P
->Sends the CPU a timeslice interrupt, and if
-<TT
-CLASS="PARAMETER"
-><I
->wait</I
-></TT
-> is non-zero, waits for an
-acknowledgment. The interrupted CPU should call
-<TT
-CLASS="FUNCTION"
->cyg_scheduler_timeslice_cpu()</TT
-> to cause the
-timeslice event to be processed.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="SECTION"
-><H3
-CLASS="SECTION"
-><A
-NAME="AEN8351">Test-and-set Support</H3
-><P
->Test-and-set is the foundation of the SMP synchronization
-mechanisms.</P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="LITERAL"
->HAL_TAS_TYPE</TT
-></DT
-><DD
-><P
->The type for all test-and-set variables. The
-test-and-set macros only support operations on
-a single bit (usually the least significant
-bit) of this location. This allows for maximum
-flexibility in the implementation.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_TAS_SET( tas, oldb )</TT
-></DT
-><DD
-><P
->Performs a test and set operation on the
-location <TT
-CLASS="PARAMETER"
-><I
->tas</I
-></TT
->. <TT
-CLASS="PARAMETER"
-><I
->oldb</I
-></TT
-> will contain <TT
-CLASS="LITERAL"
->true</TT
-> if
-the location was already set, and <TT
-CLASS="LITERAL"
->false</TT
-> if
-it was clear.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_TAS_CLEAR( tas, oldb )</TT
-></DT
-><DD
-><P
->Performs a test and clear operation on the
-location <TT
-CLASS="PARAMETER"
-><I
->tas</I
-></TT
->. <TT
-CLASS="PARAMETER"
-><I
->oldb</I
-></TT
-> will contain <TT
-CLASS="LITERAL"
->true</TT
-> if
-the location was already set, and <TT
-CLASS="LITERAL"
->false</TT
-> if
-it was clear.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="SECTION"
-><H3
-CLASS="SECTION"
-><A
-NAME="AEN8378">Spinlocks</H3
-><P
->Spinlocks provide inter-CPU locking. Normally they will be implemented
-on top of the test-and-set mechanism above, but may also be
-implemented by other means if, for example, the hardware has more
-direct support for spinlocks.</P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_TYPE</TT
-></DT
-><DD
-><P
->The type for all spinlock variables.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_INIT_CLEAR</TT
-></DT
-><DD
-><P
->A value that may be assigned to a spinlock
-variable to initialize it to clear.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_INIT_SET</TT
-></DT
-><DD
-><P
->A value that may be assigned to a spinlock
-variable to initialize it to set.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_SPIN( lock )</TT
-></DT
-><DD
-><P
->The caller spins in a busy loop waiting for
-the lock to become clear. It then sets it and
-continues. This is all handled atomically, so
-that there are no race conditions between CPUs.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_CLEAR( lock )</TT
-></DT
-><DD
-><P
->The caller clears the lock. One of any waiting
-spinners will then be able to proceed.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_TRY( lock, val )</TT
-></DT
-><DD
-><P
->Attempts to set the lock. The value put in
-<TT
-CLASS="PARAMETER"
-><I
->val</I
-></TT
-> will be <TT
-CLASS="LITERAL"
->true</TT
-> if the lock was
-claimed successfully, and <TT
-CLASS="LITERAL"
->false</TT
-> if it was
-not.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SPINLOCK_TEST( lock, val )</TT
-></DT
-><DD
-><P
->Tests the current value of the lock. The value
-put in <TT
-CLASS="PARAMETER"
-><I
->val</I
-></TT
-> will be <TT
-CLASS="LITERAL"
->true</TT
-> if the lock is
-claimed and <TT
-CLASS="LITERAL"
->false</TT
-> of it is clear.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="SECTION"
-><H3
-CLASS="SECTION"
-><A
-NAME="AEN8423">Scheduler Lock</H3
-><P
->The scheduler lock is the main protection for all kernel data
-structures. By default the kernel implements the scheduler lock itself
-using a spinlock. However, if spinlocks cannot be supported by the
-hardware, or there is a more efficient implementation available, the
-HAL may provide macros to implement the scheduler lock.</P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_SCHEDLOCK_DATA_TYPE</TT
-></DT
-><DD
-><P
->A data type, possibly a structure, that
-contains any data items needed by the
-scheduler lock implementation. A variable of
-this type will be instantiated as a static
-member of the Cyg_Scheduler_SchedLock class
-and passed to all the following macros.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_SCHEDLOCK_INIT( lock, data )</TT
-></DT
-><DD
-><P
->Initialize the scheduler lock. The <TT
-CLASS="PARAMETER"
-><I
->lock</I
-></TT
->
-argument is the scheduler lock counter and the
-<TT
-CLASS="PARAMETER"
-><I
->data</I
-></TT
-> argument is a variable of
-HAL_SMP_SCHEDLOCK_DATA_TYPE type.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_SCHEDLOCK_INC( lock, data )</TT
-></DT
-><DD
-><P
->Increment the scheduler lock. The first
-increment of the lock from zero to one for any
-CPU may cause it to wait until the lock is
-zeroed by another CPU. Subsequent increments
-should be less expensive since this CPU
-already holds the lock.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_SCHEDLOCK_ZERO( lock, data )</TT
-></DT
-><DD
-><P
->Zero the scheduler lock. This operation will
-also clear the lock so that other CPUs may
-claim it.</P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_SMP_SCHEDLOCK_SET( lock, data, new )</TT
-></DT
-><DD
-><P
->Set the lock to a different value, in
-<TT
-CLASS="PARAMETER"
-><I
->new</I
-></TT
->. This is only called when the lock is
-already known to be owned by the current CPU. It is never called to
-zero the lock, or to increment it from zero.</P
-></DD
-></DL
-></DIV
-></DIV
-><DIV
-CLASS="SECTION"
-><H3
-CLASS="SECTION"
-><A
-NAME="AEN8455">Interrupt Routing</H3
-><P
->The routing of interrupts to different CPUs is supported by two new
-interfaces in hal_intr.h.</P
-><P
->Once an interrupt has been routed to a new CPU, the existing vector
-masking and configuration operations should take account of the CPU
-routing. For example, if the operation is not invoked on the
-destination CPU itself, then the HAL may need to arrange to transfer
-the operation to the destination CPU for correct application.</P
-><P
-></P
-><DIV
-CLASS="VARIABLELIST"
-><DL
-><DT
-><TT
-CLASS="LITERAL"
->HAL_INTERRUPT_SET_CPU( vector, cpu )</TT
-></DT
-><DD
-><P
->Route the interrupt for the given <TT
-CLASS="PARAMETER"
-><I
->vector</I
-></TT
-> to
-the given <TT
-CLASS="PARAMETER"
-><I
->cpu</I
-></TT
->. </P
-></DD
-><DT
-><TT
-CLASS="LITERAL"
->HAL_INTERRUPT_GET_CPU( vector, cpu )</TT
-></DT
-><DD
-><P
->Set <TT
-CLASS="PARAMETER"
-><I
->cpu</I
-></TT
-> to the id of the CPU to which this
-vector is routed.</P
-></DD
-></DL
-></DIV
-></DIV
-></DIV
-></DIV
-><DIV
-CLASS="NAVFOOTER"
-><HR
-ALIGN="LEFT"
-WIDTH="100%"><TABLE
-SUMMARY="Footer navigation table"
-WIDTH="100%"
-BORDER="0"
-CELLPADDING="0"
-CELLSPACING="0"
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
-><A
-HREF="hal-diagnostic-support.html"
-ACCESSKEY="P"
->Prev</A
-></TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="ecos-ref.html"
-ACCESSKEY="H"
->Home</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
-><A
-HREF="hal-exception-handling.html"
-ACCESSKEY="N"
->Next</A
-></TD
-></TR
-><TR
-><TD
-WIDTH="33%"
-ALIGN="left"
-VALIGN="top"
->Diagnostic Support</TD
-><TD
-WIDTH="34%"
-ALIGN="center"
-VALIGN="top"
-><A
-HREF="hal-interfaces.html"
-ACCESSKEY="U"
->Up</A
-></TD
-><TD
-WIDTH="33%"
-ALIGN="right"
-VALIGN="top"
->Exception Handling</TD
-></TR
-></TABLE
-></DIV
-></BODY
-></HTML
->
\ No newline at end of file
projects / karo-tx-redboot.git / blobdiff