This chapter documents the configuration of eCos. The process is the same for any of the supported targets: you may select a hardware target (if you have a board available), any one of the simulators, or a synthetic target (if your host platform has synthetic target support).
There are various ways to download an executable image to a target board, and these involve different ways of preparing the executable image. In the eCos Hardware Abstraction Layer (HAL package) there are configuration options to support the different download methods. Table 11-1 summarizes the ways in which an eCos image can be prepared for different types of download. This is not an exhaustive list, some targets define additional start-up types of their own. Where a ROM Monitor is mentioned, this will usually be RedBoot, although on some older, or low resource, targets you may need to use CygMon or the GDB stubs ROM, see the target documentation for details.
Table 11-1. Configuration for various download methods
| Download method | HAL configuration |
|---|---|
| Burn hardware ROM | ROM or ROMRAM start-up |
| Download to ROM emulator | ROM or ROMRAM start-up |
| Download to board with ROM Monitor | RAM start-up |
| Download to simulator without ROM Monitor | ROM start-up |
| Download to simulator with ROM Monitor | RAM start-up |
| Download to simulator ignoring devices | SIM configuration |
| Run synthetic target | RAM start-up |
| Caution |
You cannot run an application configured for RAM start-up on the simulator directly: it will fail during start-up. You can only download it to the simulator if you are already running RedBoot in the simulator, as described in the toolchain documentation or you load through the SID GDB debugging component. This is not the same as the simulated stub, since it does not require a target program to be running to get GDB to talk to it. It can be done before letting the simulator run or you use the ELF loader component to get a program into memory. |
Note: Configuring eCos' HAL package for simulation should rarely be needed for real development; binaries built with such a kernel will not run on target boards at all, and the MN10300 and TX39 simulators can run binaries built for stdeval1 and jmr3904 target boards. The main use for a ``simulation'' configuration is if you are trying to work around problems with the device drivers or with the simulator. Also note that when using a TX39 system configured for simulator start-up you should then invoke the simulator with the --board=jmr3904pal option instead of --board=jmr3904
Note: If your chosen architecture does not have simulator support, then the combinations above that refer to the simulator do not apply. Similarly, if your chosen platform does not have RedBoot ROM support, the combinations listed above that use RedBoot do not apply.
The debugging environment for most developers will be either a hardware board or the simulator, in which case they will be able to select a single HAL configuration.