Comtrol eCos - Manual (Page 345)

Chapter 11. Porting Guide
• hal_cache.h . This file contains cache access macros. If the architecture defines cache instructions, or
control registers, then the access macros should be defined here. Otherwise they must be defined in the
variant or platform HAL. Usually the cache dimensions (total size, line size, ways etc.) are defined in the
variant HAL.
• arch.inc and < architecture > .inc . These files are assembler headers used by vectors.S and con-
text.S . < architecture > .inc is a general purpose header that should contain things like register aliases,
ABI definitions and macros useful to general assembly code. If there are no such definitions, then this file
need not be provided.
arch.inc contains macros for performing various eCos related operations such as
initializing the CPU, caches, FPU etc. The definitions here may often be configured or overridden by defi-
nitions in the variant or platform HALs. See the MIPS HAL for an example of this.
6. Write vectors.S . This is the most important file in the HAL. It contains the CPU initialization code, exception
and interrupt handlers. While other HALs should be consulted for structures and techniques, there is very little
here that can be copied over without major edits.
The main pieces of code that need to be defined here are:
• Reset vector. This usually need to be positioned at the start of the ROM or FLASH, so should be in a linker
section of its own. It can then be placed correctly by the linker script. Normally this code is little more than
a jump to the label
_start .
• Exception vectors. These are the trampoline routines connected to the hardware exception entry points that
vector through the VSR table. In many architectures these are adjacent to the reset vector, and should occupy
the same linker section. If the architecture allow the vectors to be moved then it may be necessary for these
trampolines to be position independent so they can be relocated at runtime.
The trampolines should do the minimum necessary to transfer control from the hardware vector to the VSR
pointed to by the matching table entry. Exactly how this is done depends on the architecture. Usually the
trampoline needs to get some working registers by either saving them to CPU special registers (e.g. PowerPC
SPRs), using reserved general registers (MIPS K0 and K1), using only memory based operations (IA32),
or just jumping directly (ARM). The VSR table index to be used is either implicit in the entry point taken
(PowerPC, IA32, ARM), or must be determined from a CPU register (MIPS).
• Write kernel startup code. This is the location the reset vector jumps to, and can be in the main text section
of the executable, rather than a special section. The code here should first initialize the CPU and other
hardware subsystems. The best approach is to use a set of macro calls that are defined either in
arch.inc or
overridden in the variant or platform HALs. Other jobs that this code should do are: initialize stack pointer;
copy the data section from ROM to RAM if necessary; zero the BSS; call variant and platform initializers;
call
cyg_hal_invoke_constructors() ; call initialize_stub() if necessary. Finally it should call
cyg_start() . See the Section called HAL Startup in Chapter 10 for details.
• Write the default exception VSR. This VSR is installed in the VSR table for all synchronous exception
vectors. See
the Section called Default Synchronous Exception Handling in Chapter 10 for details of what
this VSR does.
• Write the default interrupt VSR. This is installed in all VSR table entries that correspond to external inter-
rupts. See
the Section called Default Synchronous Exception Handling in Chapter 10 for details of what this
VSR does.
241