Auxiliary hal, Virtual vectors, Initialization (or mechanism vs. policy) – Comtrol eCos User Manual

Page 312

Advertising
background image

Chapter 11. Porting Guide

File

Description

src/plf_stub.c

Platform specific stub initialization and possibly the
low-level device driver.

The platform HAL also contains files specifying the platform’s memory layout. These files are located in

in-

clude/pkgconf

.

Auxiliary HAL

Auxiliary HALs contain whatever files are necessary to provide the required functionality. There are no predefined
set of files required in an auxiliary HAL.

Virtual Vectors (eCos/ROM Monitor Calling Interface)

Some eCos platforms have supported full debugging capabilities via CygMon since day one. Platforms of the ar-
chitectures PowerPC, ARM, and SH do not provide those features unless a GDB stub is included in the application.

This is going to change. All platforms will (eventually) support all the debugging features by relying on a
ROM/RAM calling interface (also referred to as virtual vector table) provided by the ROM monitor. This calling
interface is based on the tables used by libbsp and is thus backwards compatible with the existing CygMon
supported platforms.

Virtual Vectors

What are virtual vectors, what do they do, and why are they needed?

"Virtual vectors" is the name of a table located at a static location in the target address space. This table contains
64 vectors that point to service functions or data.

The fact that the vectors are always placed at the same location in the address space means that both ROM and
RAM startup configurations can access these and thus the services pointed to.

The primary goal is to allow services to be provided by ROM configurations (ROM monitors such as RedBoot in
particular) with clients in RAM configurations being able to use these services.

Without the table of pointers this would be impossible since the ROM and RAM applications would be linked
separately - in effect having separate name spaces - preventing direct references from one to the other.

This decoupling of service from client is needed by RedBoot, allowing among other things debugging of applica-
tions which do not contain debugging client code (stubs).

Initialization (or Mechanism vs. Policy)

Virtual vectors are a mechanism for decoupling services from clients in the address space.

The mechanism allows services to be implemented by a ROM monitor, a RAM application, to be switched out at
run-time, to be disabled by installing pointers to dummy functions, etc.

208

Advertising