While eCos supports a variety of targets, communication with the targets happens in one of four ways. These are descibed in general below.
The descriptions are followed by descriptions of each target, providing specific details of how to set up the target (if hardware) and the necessary communication information (such as baud rate for hardware targets, or special connection options for simulator targets).
Most targets will have eCos GDB stubs or CygMon installed. These normally wait for GDB to connect at 38400 baud, using 8 data bit, no parity bit and 1 stop-bit (no hardware flow control). Check the section for your target to ensure it uses this speed. If not, adjust the following instructions accordingly.
The following instructions depend on you to select the appropriate serial port on the host - the serial port which connects to the target's (primary) serial port. On Linux this could be /dev/ttyS0, while the same port on Windows would be named COM1, or
/dev/ttya on Solaris. Substitute the proper serial port name in the below.
Connect to the target by issuing the following commands in GDB console mode:
(gdb) set remotebaud 38400 (gdb) set mips-force-32bit-saved-gpregs (gdb) target remote /dev/ttyS0
In Insight, connect by opening the File->Target Settings ... window and enter:
Target: Remote/Serial Baud Rate: 38400 Port: /dev/ttyS0
You will also need to open the GDB console window with View->Console and enter "set mips-force-32bit-saved-gpregs" at the prompt
Set other options according to preference, close the window and select
Run->Connect to target
.
Some targets allow GDB to connect via Ethernet - if so, it will be mentioned in the section describing the target. Substitute the target's assigned IP address or hostname for <hostname> in the following. The <port> is the TCP port which the eCos GDB stub or CygWin is listening on. It is also listed in the section describing the target.
Connect to the target by issuing the following command in GDB console mode:
(gdb) target remote <hostname>:<port>
In Insight, connect by opening the File->Target Settings ... window and enter:
Target: Remote/TCP Hostname: <hostname> Port: <port>
Set other options according to preference, close the window and select
Run->Connect to target
.
GDB connects to all simulator targets using the same basic command, although each simulator may require additional options. These are listed in the section describing the target, and should be used when connecting.
Connect to the target by issuing the following command in GDB console mode:
(gdb) target sim [target specific options]
In Insight, connect by opening the File->Target Settings ... window and enter:
Target: Simulator Options: [target specific options]
Set other options according to preference, close the window and select
Run->Connect to target
.
Synthetic targets are special in that the built tests and applications actually run as native applications on the host. This means that there is no target to connect to - the test or application can be run directly from the GDB console using:
(gdb) run
or from Insight by pressing the Run icon. There is therefore no need to connect to the target or download the application, so you should ignore GDB "target" and "load" commands in any instructions found in other places in the documentation.
eCos comes with two ROM images that provide GDB support for the ARM PID board. The first ROM image provides a port of the CygMon ROM monitor, which includes a command-line interface and a GDB remote stub. The second ROM image provides a remote GDB stub only, which is a minimal environment for downloading and debugging eCos programs solely using GDB.
eCos, CygMon and the GDB stubs all support the PID fitted with both ARM7T and ARM9 daughterboards. CygMon and the stubs can be programmed into either the programmable ROM (U12) or the FLASH (U13). Prebuilt forms of both ROM images are provided in the directory loaders/arm-pid under the root of your eCos installation, along with a tool that will program the stubs into the FLASH memory on the board. CygMon images are prefixed with the name 'cygmon' and GDB stub ROM images are given the prefix 'gdb_module'. Images may be provided in a number of formats including ELF (.img extension), binary (.bin extension) and SREC (.srec extension). Note that some unreliability has been experienced in downloading files using Angel 1.00. Angel 1.02 appears to be more robust in this application.
These two binary preparation steps are not strictly necessary as the eCos distribution ships with precompiled binaries in the directory loaders/arm-pid relative to the installation root.
(See Using ecosconfig on UNIX )
(See Using ecosconfig on UNIX )
Each time a new image is to be programmed in the FLASH, the jumpers on the board must be set to allow Angel to run:
If you do not have two serial ports available on your host computer, you may still verify the flash programming completed successfully by quitting/killing the GDB process after running "c" in step 2 above. Then switch the serial cable on the PID from Serial A to Serial B and run a terminal emulator on the host computer. In a few seconds you should see the the repeated text described in step 2 above and you may continue the remaining steps as normal.
The process is almost identical to the previous instructions which apply to a PID board running in little-endian mode only.
The only adjustments to make are that if programming a GDB stub ROM image (or CygMon ROM monitor image), you must enable the option "Use Big-endian mode" in the eCos Configuration Tool (CYGHWR_HAL_ARM_BIGENDIAN if using ecosconfig and editing ecos.ecc).
When programming the FLASH there are two options:
Build this tool by enabling the "Build flash programming tool for BE images on LE boards" option (CYGBLD_BUILD_FLASH_TOOL_BE), resulting in a utility with the prefix "prog_flash_BE_image_LE_system" which should be used instead of "prog_flash".
Note that there is a limitation to this method: no sub-word data can be read from the ROM. To work around this, the .rodata section is folded into the .data section and thus copied to RAM before the system starts.
Given that Thumb instructions are 16 bit, it is not possible to run ROM-startup Thumb binaries on the PID board using this method.
When the image has been programmed, power off the board, and set jumper LK4 to enable big-endian operation.
The ARM AEB-1 comes with tools in ROM. These include a simple FLASH management tool and the Angel® monitor. eCos for the ARM AEB-1 comes with GDB stubs suitable for programming into the onboard FLASH. GDB is the preferred debug environment for GDB, and while Angel provides a subset of the features in the eCos GDB stub, Angel is unsupported.
Both eCos and the stubs support both Revision B and Revision C of the AEB-1 board. Stub ROM images for both types of board can be found in the loaders/arm-aeb directory under the root of your eCos installation. You can select which board you are using by selecting either the aeb or aebC platform by selecting the appropriate platform HAL in the eCos Configuration Tool .
The GDB stub can be downloaded to the board for programming in the FLASH using the board's on-board ROM monitor:
Connect a terminal or computer's serial port to the ARM AEB-1. On a PC with a 9-pin serial port, you can use the cable shipped by ARM with no modification.
Set the terminal or terminal emulator to 9600N1 (9600 baud, no parity, 1 stop bit).
Reset the board by pressing the little reset button on the top. You will see the following text:
ARM Evaluation Board Boot Monitor 0.01 (19 APR 1998) Press ENTER within 2 seconds to stop autoboot
Press ENTER quickly, and you will get the boot prompt:
Boot:
Using the AEB-1 rom menu to download the GDB stubs from the provided ".UU" file.
This is an annotated 'terminal' session with the AEB-1 monitor:
+Boot: help Module is BootStrap 1.00 (14 Aug 1998)
Help is available on:
Help Modules ROMModules UnPlug PlugIn Kill SetEnv UnSetEnv PrintEnv DownLoad Go GoS Boot PC FlashWrite FlashLoad FlashErase
Boot: download c000 Ready to download. Use 'transmit' option on terminal emulator to download file.
... at this point, download the ASCII file "loaders/arm-aeb/ gdb_module.img.UU". The details of this operation differ depending on which terminal emulator is used. It may be necessary to enter "^D" (control+D) when the download completes to get the monitor to return to command mode.
Loaded file gdb_module.img.bin at address 0000c000, size = 19392
Commit the GDB stubs module to flash:
Boot: flashwrite 4018000 C000 8000
Verify that the eCos/"GDB stubs" module is now added in the list of modules in the board:
Boot: rommodules
You should see output similar to the following:
Header Base Limit 04000004 04000000 040034a8 BootStrap 1.00 (14 Aug 1998) 04003a74 04003800 04003bc0 Production Test 1.00 (13 Aug 1998) 0400e4f4 04004000 0400e60f Angel 1.02 (12 MAY 1998) 0401c810 04018000 0401cbc0 eCos 1.3 (27 Jan 2000) GDB stubs
Now make the eCos/"GDB stubs" module be the default monitor:
Boot: plugin eCos
Since the GDB stubs are always linked at the same address (0x4018000), the operation of writing to the flash and selecting the stubs as default monitor is an idempotent operation. You can download a new set of stubs following the same procedure - you do not have to unregister or delete anything.
Prebuilt GDB stubs images are provided in the directory loaders/arm-aeb relative to the root of your eCos installation, but here are instructions on how to rebuild them if you should ever need to.
(See Using ecosconfig on UNIX )
The eCos Developer's Kit package comes with an EPROM which provides GDB support for the Cogent evaluation board. An image of this EPROM is also provided at loaders/arm-cma230/gdbload.bin under the root of your eCos installation.
The EPROM is installed to socket U3 on the board. Attention should be paid to the correct orientation of the EPROM during installation.
If you are going to burn a new EPROM using the binary image, be careful to get the byte order correct. It needs to be little-endian, which is usually the default in PC based programmer software.
If the GDB stub EPROM you burn does not work, try reversing the byte-order, even if you think you have it the right way around. At least one DOS-based EPROM burner program is known to have the byte-order upside down.
The GDB stub in the EPROM allows communication with GDB using the serial port at connector P12 (CMA101) or P3 (CMA102). The communication parameters are fixed at 38400 baud, 8 data bits, no parity bit and 1 stop bit (8-N-1). No flow control is employed. Connection to the host computer should be made using a dedicated serial cable as specified in the Cogent CMA manual.
Prebuilt GDB stubs images are provided in the directory loaders/arm-cma230 relative to the root of your eCos installation, but here are instructions on how to rebuild them if you should ever need to.
CygMon images are prefixed with the name 'cygmon' and GDB stub ROM images
are given the prefix 'gdb_module'. Images may be provided in a number of formats including ELF (.img extension), binary (.bin extension) and SREC (.srec extension).
(See Using ecosconfig on UNIX )
eCos comes with two Flash ROM images that provide GDB support for the Cirrus Logic EP7211 Development Board (also known as the EDB7211).. Note that on some board revisions, the board is silk-screened as EDB7111-2. The first Flash ROM image provides a port of the CygMon ROM monitor, which includes a command-line interface and a GDB remote stub. The second Flash ROM image provides a remote GDB stub only.
Both ROM images are provided in the directory loaders/arm-edb7211 under the root of your eCos installation. CygMon images are prefixed with the name 'edb7211_cygmon' and are provided in a number of formats including binary (.bin extension) and SREC (.srec) extension. GDB stub ROM images are given the prefix 'edb7211_gdb_module'.
The ROM images provided for the EP7211 Development Board must be programmed into the flash. Please refer to the section titled "Loading the ROM image into On-Board flash" on how to program the ROM onto the board.
Both Cygmon and GDB Stub ROMS allow communication with GDB via the serial connector labelled 'UART 1'. The communication parameters are fixed at 38400 baud, 8 data bits, no parity bit and 1 stop bit (8-N-1). No flow control is employed. Connection to the host computer should be made using a null modem cable. A gender changer may also be required. Note that the GDB Configuration tool uses the serial port identifiers 0 and 1 to identify the EB7211 serial ports UART1 and UART2 respectively.
Both eCos and the ROM images assume the core clock is generated with a 3.6864 MHz PLL input. The CPU will be configured to run at 73.728MHz.
Note: The EP7211 CPU needs a two step RESET process. After pressing the `URESET' pushbutton, the `WAKEUP' pushbutton must be pressed to complete the process.
When an eCos program is run on an EDB7211 board fitted with either CygMon or a GDB stub ROM, then the code in ROM loses control. This means that if you require the ability to remotely stop execution on the target, or want thread debugging capabilities, you must include GDB stub support when configuring eCos.
If your application is to be run directly from flash, you must configure eCos appropriately for "ROM" startup. This can be done in the eCos Configuration Tool by setting the "Startup type" HAL option to "ROM". If using the ecosconfig utility, set the user_value of the CYG_HAL_STARTUP option in ecos.ecc to "ROM".
When you have linked your application with eCos, you will then have an ELF executable. To convert this into a format appropriate for the Cirrus Logic flash download utility, or the dl_7xxx utility on linux, you can use the utility arm-elf-objcopy, as in the following example:
$ arm-elf-objcopy -O binary helloworld.exe helloworld.bin
This will produce a binary format image helloworld.bin which can be downloaded into flash.
Prebuilt GDB stubs images are provided in the directory loaders/arm-edb7211 relative to the root of your eCos installation, but here are instructions on how to rebuild them if you should ever need to.
CygMon images are prefixed with the name 'cygmon' and GDB stub ROM images are given the prefix 'gdb_module'. Images may be provided in a number of formats including ELF (.img extension), binary (.bin extension) and SREC (.srec extension).
(See Using ecosconfig on UNIX )
Program images can be written into Flash memory by means of a bootstrap program which is built into the EDB7211. This program communicates with a support program on your host to download and program an image into the Flash memory.
Cirrus Logic provides such a program for use with Windows/DOS. eCos comes with a similar program which will run under Linux. The basic operation of both programs is the same.
eCos provides a Flash download program suitable for use with the EP7211 Development Board which will run on Linux. Follow these steps to build this program. Note: at the time of the writing of these instructions, the download program is built directly within the eCos source repository since it is not configuration specific.
# cd <eCos install dir>/packages/hal/arm/edb7xxx/v1_3_1/support
# make
(where '# ' is your shell prompt)
Note: this program was adapted from the Cirrus Logic original DOS program and still contains some vestiges of that environment.
The EP7211 Development Board supports use of the ARM Multi-processor EmbeddedICE(tm), also known as the Multi-ICE. Full instructions on how to install and use the Multi-ICE in conjunction with GDB are provided in the "GNUPro Toolkit Reference for eCos ARM/Thumb" manual. However, the following platform-specific details should be noted.
You will need an ARM Multi-ICE Server configuration file for the EP7211 Development Board. Here is a suggested configuration file to use:
======== File "720T.cfg" ======== ;Total IR length = 4 [TITLE] Multi-ICE configuration for EP7211 [TAP 0] ARM720T [TAPINFO] YES [Timing] Low=0 High=0 Adaptive=OFF ==================================
You must ensure that the board has the appropriate soldered connections. For the EP7211 this involves connecting TEST0 and TEST1 of the EP7211 to ground. To do this you must solder a wire from ground at JP33 to TP8 and TP9.
With respect to using multiple devices simultaneously, note that the EP7211 is not ID sensitive.
If you wish to view diagnostic output from your program that was downloaded via the Multi-ICE, you will note that by default the output on the serial line (as viewed by a terminal such as Hyperterm in Windows, or cu in Unix) is in the form of GDB packets.
To get legible output, the solution is to set the "GDB Serial port" to a different device from the "Diagnostic serial port", and you should use the Diagnostic serial port to view the diagnostic output.
Warning: The multi-ice-gdb-server will fail on startup if the board has not been both reset and awakened before running the server.
To resolve this, it is necessary to free up the connection from within the ARM Multi-ICE server itself. However when this happens, the next time you use GDB to load the program into the board, you will see lots of "Readback did not match original data" messages in the output of the multi-ice-gdb-server program. This indicates your program did not load correctly, and you should restart the multi-ice-gdb-server program, taking care to reset the board correctly before reconnecting.
As a reminder, you must specify --config-dialog to the multi-ice-gdb-server program to connect to the board correctly. If you do not, the multi-ice-gdb-server program will not be able to connect.
The Cirrus Logic EP7212 Development Board is almost identical to the EP7211 Development Board from a hardware setup viewpoint, and is based on the same port of eCos. Therefore the earlier documentation for the EP7211 Development Board can be considered equivalent, but with the following changes:
Note: At time of writing, no EP7209 Development Board is available, and consequently eCos has not been verified for use with the EP7209 Development Board.
The Cirrus Logic EP7209 Development Board is almost identical to the EP7212 Board in all respects, except that it is not fitted with DRAM, nor has it a DRAM controller.
The only valid configuration for the EDB7209 is ROM based. The STUBS and RAM startup modes are not available as no DRAM is fitted.
The implementation of the port of eCos to the Cirrus Logic ARM CL-PS7111 Evaluation Board (also known as EB7111) is based on the EP7211 Development Board port.
For that reason, the setup required is identical to the EP7211 Development Board as described above, with the following exceptions:
The eCos Developer's Kit package comes with a ROM image which provides GDB support for the Intel® StrongARM® Evaluation Board EBSA-285. Both eCos and the Stub ROM image assume the clocks are: 3.6864 MHz PLL input for generating the core clock, and 50MHz osc input for external clocks. An image of this ROM is also provided at loaders/arm-ebsa285/gdbload.bin under the root of your eCos installation.
The ROM monitor image (an eCos GDB stub) provided for the EBSA-285 board must be programmed into the flash, replacing the Angel monitor on the board. Please refer to the section titled "Loading the ROM Image into On-Board flash" on how to program the ROM onto the board.
The Stub ROM allows communication with GDB via the serial connector on the bulkhead mounting bracket COM0. The communication parameters are fixed at 38400 baud, 8 data bits, no parity bit and 1 stop bit (8-N-1). No flow control is employed.
Prebuilt GDB stubs images are provided in the directory loaders/arm-ebsa285 relative to the root of your eCos installation, but here are instructions on how to rebuild them if you should ever need to.
(See Using ecosconfig on UNIX )
There are several ways to install the eCos gdb stub ROM image in the EBSA board's flash memory. Once installed, the gdb stub ROM provides standard eCos download and debug via the EBSA board's serial port. The options available include the Linux based EBSA flash upgrade utility provided by Red Hat, direct writing of the flash via MultiICE (JTAG) hardware debugger, and other flash management utilities from Intel (these only support DOS, and proprietary ARM tools and image formats). Only the Red Hat flash upgrade tool is supported and tested in this release.
The flash upgrade tool requires the EBSA board to be configured as a PCI slave (rather than a master, its normal operating mode) and plugged into a Linux host computer's PCI bus.
Configuring the board for flash loading: Follow the instructions in the EBSA-285 Reference Manual, pages A-2 and A-3 to configure the board as an add-in card, and enable flash blank programming. Briefly: assuming the board was in the default setting to execute as a bus master ("Host Bridge") make jumper 9 (J9), move jumper 10 (J10) to external reset (PCI_RST), and move jumper 15 (J15) link 4-6-5 to connect 5-6 instead of 4-6.
Configuring the board for execution of eCos programs: Follow the instructions in the EBSA-285 Reference Manual, pages A-2 and A-3 to configure the board as a "Host Bridge" with "Central Function". Briefly: unset J9, move J10 to on-board reset (BRD_RST), and set J15 to make 4-6 instead of 5-6 (see page A-8 also). Plug the card into its own PCI bus, not the Linux PC used for the flash-programming process.
Building the Linux software: the Linux software sources are in directory
<BASEDIR>/packages/hal/arm/ebsa285/v1_3/support/linux/safl_util
in the eCos source repository. There are two parts to the system: a loadable kernel module and the flash utility. The loadable kernel module is safl.o and the utility is sa_flash. To build:
cd to this directory, or a copy of it.
This builds safl.o and sa_flash. The kernel module must be installed, and a device file created for it. Both of these operations require root permissions. Create the device file by:
% mknod /dev/safl c 10 178
Programming the flash: switch off the EBSA-285, and remove the EBSA-285 board from its PCI bus. Take appropriate anti-static precautions. Configure it for flash loading as above, halt your Linux system and turn it off. Install the EBSA-285 board in the PCI bus of the Linux system and boot it up. (Single user is good enough, assuming your image and safl_util build dir are on a local disc partition.) Change directory to the safl_util directory, then, to load the kernel module and flash an image onto the eval board (as root):
% insmod safl.o % sa_flash <image_file>
Halt and turn off the Linux machine and remove the EBSA-285 card. Take appropriate anti-static precautions. Configure it for execution of eCos programs as above, and plug it into its own PCI bus. Restart the Linux machine however you wish.
This information is replicated in the README file within the safl_util directory and its parents, and in the EBSA-285 Reference Manual from Intel, appendix A "Configuration Guide". If in doubt, please refer to those documents also.
This procedure also applies for loading ROM-startup eCos programs into the on-board flash memory, given a binary format image of the program from arm-elf-objcopy. Loading a ROM-startup eCos program into flash will overwrite the StubROM in flash, so you would have to reload the StubROM to return to normal RAM-startup program development.
When building for the synthetic Linux target, the resulting binaries are native Linux applications with the HAL providing suitable bindings between the eCos kernel and the Linux kernel.
Please be aware that the current implementation of the Linux synthetic target does not allow thread-aware debugging.
These Linux applications cannot be run on a Windows system. However, it is possible to write a similar HAL emulation for the Windows kernel if such a testing target is desired.
For the synthetic target, eCos relies on features not available in native compilers earlier than gcc-2.95.1. It also requires version 2.9.5 or later of the GNU linker. If you have gcc-2.95.1 or later and ld version 2.9.5 or later, then you do not need to build new tools. eCos does not support earlier versions. You can check the compiler version using gcc -v or egcs -v , and the linker version using ld -v .
If you have native tools that are sufficiently recent for use with eCos, you should be aware that by default eCos assumes that the tools i686-pc-linux-gnu-gcc, i686-pc-linux-gnu-ar, i686-pc-linux-gnu-ld, and i686-pc-linux-gnu-objcopy are on your system and are the correct versions for use with eCos. But instead, you can tell eCos to use your native tools by editting the configuration value "Global command prefix" (CYGBLD_GLOBAL_COMMAND_PREFIX) in your eCos configuration. If left empty (i.e. set to the empty string) eCos will use your native tools when building.
If you have any difficulties, it is almost certainly easiest overall to rebuild the tools as described on:
http://sourceware.cygnus.com/ecos/getstart.html
Target Setup | ||
---|---|---|