Comtrol eCos - Manual (Page 297)

Chapter 9. HAL Interfaces
isters which can be used to serialize implementations of these operations. Whatever hardware facilities are
available, they are used in eCos to implement spinlocks.
• 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.
• Uniform addressing. It is assumed that all memory that is shared between CPUs is addressed at the same loca-
tion 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.
• 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.
• 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.
• 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.
• 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.
HAL Support
SMP support in any platform depends on the HAL supplying the appropriate operations. All HAL SMP
support is defined in the
cyg/hal/hal_smp.h header. Variant and platform specific definitions will be in
cyg/hal/var_smp.h and cyg/hal/plf_smp.h respectively. These files are include automatically by this
header, so need not be included explicitly.
SMP support falls into a number of functional groups.
CPU Control
This group consists of descriptive and control macros for managing the CPUs in an SMP system.
HAL_SMP_CPU_TYPE
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.
193