The following sections detail the setup of many of the targets supported by eCos. This information is presented here only temporarily. It is intended that there will be separate documents detailing this information for each target in future releases. Consequently not much effort has been put into bringing the following documentation up to date -- much of it is obsolete, bogus or just plain wrong. The eCos Developer’s Kit package comes with a pair of EPROMs which provide GDB support for the Matsushita MN10300 (AM31) series evaluation board using CygMon, the Cygnus ROM monitor. Images of these EPROMs are also provided at BASE_DIR/loaders/mn10300-stdeval1/cygmon.bin. The LSB EPROM (LROM) is installed to socket IC8 on the board and the MSB EPROM (UROM) is installed to socket IC9. Attention should be paid to the correct orientation of these EPROMs during installation. The CygMon stubs allows communication with GDB by way of the serial port at connector CN2. 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 standard RS232C serial cable (not a null modem cable). A gender changer may also be required. The MN10300 simulator is an architectural simulator for the Matsushita MN10300 that implements all features of the microprocessor necessary to run eCos. The current implementation provides accurate simulation of the instruction set, interrupt controller, timers, and serial I/O. In this release, you can run the same eCos binaries in the simulator that can run on target hardware, if built for ROM start-up, with the exception of those that use the watchdog timer. However, note that AM33 devices required to run eCos are not simulated; therefore you cannot run eCos binaries built for the AM33 under the simulator. For the AM33, the simulator is effectively an instruction-set only simulator. To simplify connection to the simulator, you are advised to create a GDB macro by putting the following code in your personal GDB start-up file (gdb.ini on Windows and .gdbinit on UNIX). define msim target sim --board=stdeval1 --memory-region 0x34004000,0x8 rbreak cyg_test_exit rbreak cyg_assert_fail end You can then connect to the simulator by invoking the command msim on the command line: (gdb) msim You can achieve the same effect by typing out the macro’s content on the command line if necessary. The Matsushita AM33 STB System Reference Board may be used in two modes: via a JTAG debugger, or by means of a GDB stub ROM. The eCos Developer’s Kit package comes with a ROM image which provides GDB support for the Matsushita(R) AM33 STB System Reference Board. To install the GDB stub ROM requires the use of the JTAG debugger and the Flash ROM programming code available from Matsushita. An image of this ROM is also provided at loaders/am33-stb/gdbload.bin under the root of your eCos installation. Ensure that there is a Flash ROM card in MAIN MEMORY SLOT <0>. Follow the directions for programming a Flash ROM supplied with the programming software. The final programming of the ROM will need to be done with a command similar to the following: fdown "gdbload.bin",0x80000000,16,1 Once the ROM has been programmed, close down the JTAG debugger, turn the STB off, and disconnect the JTAG cable. Ensure that the hardware switches are in the following configuration: U U D D D U D D D = lower part of rocker switch pushed in U = upper part of rocker switch pushed in This is also the configuration required by the Flash programming code, so it should not be necessary to change these. Restart the STB and the stub ROM will now be able to communicate with GDB. eCos programs should be built with RAM startup. Programs can then be downloaded via a standard RS232 null modem serial cable connected to the SERIAL1 connector on the STB front panel (the AM33"s serial port 0). This line is programmed to run at 38400 baud, 8 data bits, no parity and 1 stop bit (8-N-1) with no flow control. A gender changer may also be required. Diagnostic output will be output to GDB using the same connection. This procedure also applies for programming ROM startup eCos programs into ROM, given a binary format image of the program from mn10300-elf-objcopy. To use eCos from the JTAG debugger, executables must be built with ROM startup and then downloaded via the JTAG debugger. For this to work there must be an SDRAM memory card in SUB MEMORY SLOT <0> and the hardware switches on the front panel set to the following: D U D D D U D D D = lower part of rocker switch pushed in U = upper part of rocker switch pushed in Connect the JTAG unit and run the debugger as described in the documentation that comes with it. eCos executables should be renamed to have a “.out” extension and may then be loaded using the debugger"s “l” or “lp” commands. Diagnostic output generated by the program will be sent out of the AM33"s serial port 0 which is connected to the SERIAL1 connector on the STB front panel. This line is programmed to run at 38400 baud, 8 data bits, no parity, and one stop bit (8-N-1) with no flow control. Connection to the host computer should be using a standard RS232 null modem serial cable. A gender changer may also be required. eCos comes with a pre-built GDB stub ROM image for the AM33-STB platform. This can be found at loaders/am33-stb/gdbload.bin relative to the eCos installation directory. If necessary, the ROM image can be re-built as follows: On Windows hosts, open a Bash session using Start->Programs->Red Hat eCos->eCos Development Environment Create a build directory and cd into it Run (all as one line): cygtclsh80 BASE_DIR/packages/pkgconf.tcl \ --target=mn10300_am33 --platform stb --startup rom \ --disable-kernel --disable-uitron --disable-libc --disable-libm \ --disable-io --disable-io_serial --disable-wallclock --disable-watchdog where BASE_DIR is the path to the eCos installation directory. Edit the configuration file pkgconf/hal.h in the build directory tree by ensuring the following configuration options are set as follows: #define CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS #define CYGDBG_HAL_DEBUG_GDB_BREAK_SUPPORT #undef CYGDBG_HAL_DEBUG_GDB_CTRLC_SUPPORT #define CYGDBG_HAL_DEBUG_GDB_THREAD_SUPPORT #define CYG_HAL_ROM_MONITOR Run: make Run: make -C hal/common/current/current/src/stubrom The file hal/common/current/src/stubrom will be an ELF format executable of the ROM image. Use mn10300-elf-objcopy to convert this to the appropriate format for loading into the Matsushita FLASH ROM programmer, mode “binary” in this case: $ mn10300-elf-objcopy -O binary hal/common/current/src/stubrom/ \ stubrom stubrom.img The eCos Developer’s Kit package comes with a pair of ROMs that provide GDB support for the Toshiba JMR-TX3904 RISC processor reference board by way of CygMon. Images of these ROMs are also provided at BASE_DIR/loaders/tx39-jmr3904/cygmon50.bin and BASE_DIR/loaders/tx39-jmr3904/cygmon66.bin for 50 MHz and 66 MHz boards respectively. The ROMs are installed to sockets IC6 and IC7 on the memory daughterboard according to their labels. Attention should be paid to the correct orientation of these ROMs during installation. The GDB stub allows communication with GDB using the serial port (channel C) at connector PJ1. The communication parameters are fixed at 38400 baud, 8 data bits, no parity bit, and 1 stop bit (8-N-1). No handshaking is employed. Connection to the host computer should be made using an RS232C null modem cable. CygMon and eCos currently provide support for a 16Mbyte 60ns 72pin DRAM SIMM fitted to the PJ21 connector. Different size DRAMs may require changes in the value stored in the DCCR0 register. This value may be found near line 211 in hal/mips/arch/&Version;/src/vectors.S in eCos, and near line 99 in libstub/mips/tx39jmr/tx39jmr-power.S in CygMon. eCos does not currently use the DRAM for any purpose itself, so it is entirely available for application use. The TX39 simulator is an architectural simulator which implements all the features of the Toshiba TX39 needed to run eCos. The current implementation provides accurate simulation of the instruction set, interrupt controller, and timers, as well as having generic support for diagnostic output, serial I/O, and exceptions. In this release, you can run the same eCos binaries in the simulator that can run on target hardware, if it is built for ROM start-up. To simplify connection to the simulator, you are advised to create a GDB macro by putting the following code in your personal GDB start-up file (gdb.ini on Windows and .gdbinit on UNIX). define tsim target sim --board=jmr3904pal --memory-region 0xffff8000,0x900 \ --memory-region 0xffffe000,0x4 \ --memory-region 0xb2100000,0x4 rbreak cyg_test_exit rbreak cyg_assert_fail end You can then connect to the simulator by invoking the command tsim on the command line: (gdb) tsim You can achieve the same effect by typing out the macro’s content on the command line if necessary. The eCos installation CD contains a copy of the eCos GDB stubs in SREC format which must be programmed into the board’s FLASH memory. These stub preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled stubs in the directory loaders/tx49-ref4955 relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the TX49 REF4955 hardware. While still displaying the Build->Templates dialog box, select the stubs package template to build a GDB stub. Click OK. Build eCos stubs using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new ref4955 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. Boot into the board’s firmware in little-endian mode: Set the switches like this: SW1: 10000000 (first lever up, the rest down) SW2: 10000010 Connect serial cable on the lower connector, configure terminal emulator for 38400, 8-N-1. When booting the board, you should get this prompt: HCP5 rev 0.9B . HCP5? Select o (option), a (FLASH) and b (boot write). You should see this: Boot ROM Write ROM address-ffffffffbd000000, Boot Bus-[32bit] ID2 0 4 ffffffffa002ad40 zzz SS-40000 IV-1 CS-20000 CC-2 Flash ROM-[28F640J5], [16bit chip] * 2 * 1 Block size-00040000 count-64 ROM adr ffffffffbd000000-ffffffffbe000000 mask-00fc0000 Send Srecord file sa=00000000 size=ffffffffffffffff ra=fffffffffe000000 Now send the stub SREC data down to the board using the terminal emulator’s ‘send ASCII’ (or similar) functionality. Red Hat has experienced some sensitivity to how fast the data is written to the board. Under Windows you should configure Minicom to use a line delay of 100 milliseconds. Under Linux, use the slow_cat.tcl script: % cd BASE_DIR/packages/hal/mips/ref4955/&Version;/misc % slow_cat.tcl < [path]/gdb_module.srec > /dev/ttyS0 Power off the board, and change it to boot the GDB stubs in big-endian mode by setting the switches like this: SW1: 00000000 (all levers down) SW2: 10001010 The GDB stubs allow communication with GDB using the serial port at connector PJ7A (lower connector). 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 straight through serial cable. The eCos Developer’s Kit package comes with an EPROM which provides GDB support for the NEC VRC4373 evaluation board. An image of this EPROM is also provided at loaders/vr4300-vrc4373/gdbload.bin under the root of your eCos installation. The EPROM is installed to socket U12 on the board. Attention should be paid to the correct orientation of the EPROM during installation. Only replace the board"s existing ROM using a proper PLCC extraction tool, as the socket would otherwise risk getting damaged. The GDB stub in the EPROM allows communication with GDB using the serial port at connector J1. 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 straight-through serial cable. For information about setting up the VRC4375 to run with RedBoot, consult the RedBoot User"s Guide. If using serial debugging, the serial line runs at 38400 baud 8-N-1 and should be connected to the debug host using the cable supplied with the board. For information about setting up the Atlas and Malta boards to run with RedBoot, consult the RedBoot User"s Guide. 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/powerpc-cogent/gdbload.bin under the root of your eCos installation. The same EPROM and image can be used on all three supported daughterboards: CMA287-23 (MPC823), CMA287-50 (MPC850), and CMA286-60 (MPC860). The EPROM is installed to socket U4 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 big-endian. If the EPROM burner software has a hex-editor, check that the first few bytes of the image look like: 00000000: 3c60 fff0 6063 2000 7c68 03a6 4e80 0020 <`..`c.|h..N.. If the byte order is wrong you will see 603c instead of 3c60 etc. Use the EPROM burner software to make a byte-swap before you burn to image to the EPROM. 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. These two binary preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled binaries in the directory loaders/powerpc-cogent relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the PowerPC CMA28x hardware. While still displaying the Build->Templates dialog box, select the “stubs” package template to build a GDB stub. Click OK. Build eCos using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new cma28x stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Program the binary image file gdb_module.bin into ROM or FLASH referring to the instructions of your ROM programmer. Plug the ROM/FLASH into socket U4 as described at the beginning of this Hardware Setup section. The eCos Developer’s Kit package comes with an EPROM which provides GDB support for the Motorola PowerPC MBX860 evaluation board. An image of this EPROM is also provided at loaders/powerpc-mbx/gdbload.bin under the root of your eCos installation. The EPROM is installed to socket XU1 on the board. Attention should be paid to the correct orientation of the EPROM during installation. Only replace the board"s existing ROM using a proper PLCC extraction tool, as the socket would otherwise risk getting damaged. The GDB stub in the EPROM allows communication with GDB using the serial port at connector SMC1/COM1. 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 suitable serial cable. In order to make the board execute the EPROM that you just installed (rather than the on-board FLASH memory), it may be necessary move some links on the board. Specifically, ensure that link J4 is in position 1-2. If in doubt, refer to the MBX documentation from Motorola, ensuring that Boot Port Size=8 Bits/ROM for BOOT (CS#7), in their terminology. These two binary preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled binaries in the directory loaders/powerpc-mbx relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the PowerPC Motorola MBX860/821 hardware. While still displaying the Build->Templates dialog box, select the “stubs” package template to build a GDB stub. Click OK. Build eCos using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new mbx stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Program the binary image file gdb_module.bin into ROM or FLASH referring to the instructions of your ROM programmer. Plug the ROM/FLASH into socket XU1 as described near the beginning of this Hardware Setup section. This assumes you have EPPC-Bug in the on-board FLASH. This can be determined by setting up the board according to the below instructions and powering up the board. The EPPC-Bug prompt should appear on the SMC1 connector at 9600 baud, 8N1. Set jumper 3 to 2-3 [allow XU2 FLASH to be programmed] Set jumper 4 to 2-3 [boot EPPC-Bug] Prepare EPPC-Bug for download: EPPC-Bug>lo 0 At this point the monitor is ready for input. It will not return the prompt until the file has been downloaded. Use the terminal emulator’s ASCII download feature (or a simple clipboard copy/paste operation) to download the gdb_module.srec data. Note that on Linux, Minicom’s ASCII download feature seems to be broken. A workaround is to load the file into Emacs (or another editor) and copy the full contents to the clipboard. Then press the mouse paste-button (usually the middle one) over the Minicom window. Program the FLASH with the downloaded data: EPPC-Bug>pflash 40000 60000 fc000000 Switch off the power, and change jumper 4 to 1-2. Turn on the power again. The board should now boot using the newly programmed stubs. The PowerPC simulator is an architectural simulator which implements all the features of the PowerPC needed to run eCos. The current implementation provides accurate simulation of the instruction set and timers, as well as having generic support for diagnostic output and exceptions. The simulator also allows devices to be simulated, but no device simulation support has been defined for the serial device drivers in this release. To simplify connection to the simulator, you are advised to create a GDB macro by putting the following code in your personal GDB start-up file (gdb.ini on Windows and .gdbinit on UNIX). define psim target sim -o ’/iobus/pal@0xf0001000/reg 0xf0001000 32’ rbreak cyg_test_exit rbreak cyg_assert_fail end You can then connect to the simulator by invoking the command psim on the command line: (gdb) psim You can achieve the same effect by typing out the macro’s content on the command line if necessary. The PowerPC simulator cannot execute binaries built for any of the supported hardware targets. You must generate a configuration using the PowerPC simulator platform: $ ecosconfig new psim or some such. The eCos Developer’s Kit package comes with a ROM which provides GDB support for the Fujitsu SPARClite Evaluation Board by way of CygMon. An image of this ROM is also provided at BASE_DIR/loaders/sparclite-sleb/cygmon.bin. The ROM is installed in socket IC9 on the evaluation board. Attention should be paid to the correct orientation of the ROM during installation. The GDB stub allows communication with GDB using a TCP channel via the ethernet port at connector J5. The ethernet setup is described in the board’s manual, but here is a recapitulation. Set the board’s ethernet address using SW1 on the motherboard: SW1-4 SW1-3 SW1-2 SW1-1 Ethernet Address ----- ----- ----- ----- ---------------- OFF OFF OFF OFF No ethernet, use serial OFF OFF OFF ON 00:00:0E:31:00:01 OFF OFF ON OFF 00:00:0E:31:00:02 OFF OFF ON ON 00:00:0E:31:00:03 OFF ON OFF OFF 00:00:0E:31:00:04 OFF ON OFF ON 00:00:0E:31:00:05 OFF ON ON OFF 00:00:0E:31:00:06 OFF ON ON ON 00:00:0E:31:00:07 ON OFF OFF OFF 00:00:0E:31:00:08 ON OFF OFF ON 00:00:0E:31:00:09 ON OFF ON OFF 00:00:0E:31:00:0A ON OFF ON ON 00:00:0E:31:00:0B ON ON OFF OFF 00:00:0E:31:00:0C ON ON OFF ON 00:00:0E:31:00:0D ON ON ON OFF 00:00:0E:31:00:0E ON ON ON ON 00:00:0E:31:00:0F Configure the BOOTP or DHCP server on the network to recognize the evaluation board’s ethernet address so it can assign the board an IP address. Below is a sample DHCP server configuration from a Linux system (/etc/dhcpd.conf). It shows a setup for three evaluation boards. # # DHCP server configuration. # allow bootp; subnet 192.168.1.0 netmask 255.255.255.0 { host mb831evb { hardware ethernet 00:00:0e:31:00:01; fixed-address mb831evb; } host mb832evb { hardware ethernet 00:00:0e:31:00:02; fixed-address mb832evb; } host mb833evb { hardware ethernet 00:00:0e:31:00:03; fixed-address mb833evb; } } Even when configured to use a TCP channel, CygMon will still print a boot message to the serial channel. If the BOOTP process was successful and an IP address was found, a message “BOOTP found xxx.xxx.xxx.xxx” will be printed where xxx.xxx.xxx.xxx is the IP address assigned by the BOOTP or DHCP server. If the BOOTP process fails, a message indicating failure will be printed and the serial port will be used as the debug channel. Once the board finds an IP address it will respond to ICMP echo request packets (ping). This gives a simple means to test the health of the board. As described in “Ethernet Setup” on page 72, it should now be possible to connect to the SPARClite board from within GDB by using the command: (gdb) target remote <host>:1000 The CygMon stubs also allow communication with GDB by way of the serial port at connector CON1. The communication parameters are fixed at 19200 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. The ESA SPARClite simulator is an architectural simulator which implements all the features of the SPARClite needed to run eCos. The current implementation provides accurate simulation of the instruction set, interrupt controller, and timers, as well as having generic support for diagnostic output and exceptions. Note that the ESA SPARClite simulator is unsupported, but is included in the release as a convenience. To simplify connection to the simulator, you are advised to create a GDB macro by putting the following code in your personal GDB start-up file (gdb.ini on Windows and .gdbinit on UNIX). define ssim target sim -nfp -sparclite -dumbio rbreak cyg_test_exit rbreak cyg_assert_fail end You can then connect to the simulator by invoking the command ssim on the command line: (gdb) ssim You can achieve the same effect by typing out the macro’s content on the command line if necessary. 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). Pre-built 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 pre-compiled binaries in the directory loaders/arm-pid relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build -> Templates menu item, and then select the ARM PID hardware. While still displaying the Build -> Templates dialog box, select either the "stubs" package template to build a GDB stub image, or the "cygmon" template to build the CygMon ROM Monitor. Click OK. Build eCos using Build -> Library When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix "gdb_module". CygMon images have the prefix "cygmon". Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new pid stubs or to build a CygMon ROM monitor image, enter the command: $ ecosconfig new pid cygmon Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix "gdb_module". CygMon images have the prefix "cygmon". Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the ARM PID hardware. Enable the "Build flash programming tool" option in the ARM PID HAL (CYGBLD_BUILD_FLASH_TOOL) and resolve any resulting configuration conflicts. Build eCos using Build -> Library When the build completes, the FLASH tool image file can be found in the bin/ subdirectory of the install tree, with the prefix "prog_flash" Make an empty directory to contain the build tree, and cd into it Enter the command: $ ecosconfig new pid Edit the file ecos.ecc and enable the option CYGBLD_BUILD_FLASH_TOOL by uncommenting its user_value property and setting it to 1. Enter the commands: $ ecosconfig resolve [there will be some output] $ ecosconfig tree $ make When the build completes, the FLASH tool image file can be found in the bin/ subdirectory of the install tree, with the prefix "prog_flash" 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: Set jumper 7-8 on LK6 [using the Angel code in the 16 bit EPROM] Set jumper 5-6 on LK6 [select 8bit ROM mode] Set jumper LK18 [ROM remap - this is also required for eCos] Set S1 to 0-0-1-1 [20MHz operation] Open jumper LK4 [enable little-endian operation] Attach a serial cable from Serial A on the PID board to connector 1 on the development system. This is the cable through which the binaries will be downloaded. Attach a serial cable from Serial B on the PID board to connector 2 on the development system (or any system that will work as a terminal). Through this cable, the FLASH tool will write its instructions (at 38400 baud). Download the FLASH ROM image onto the PID board. For example. for the GDB stubs image: bash$ arm-elf-gdb -nw gdb_module.img GNU gdb 4.18-DEVTOOLSVERSION Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i586-pc-cygwin32 --target=arm-elf". (no debugging symbols found)... (gdb) target rdi s=com1 Angel Debug Monitor for PID (Built with Serial(x1), Parallel, DCC) 1.00 (Advanced RISC Machines SDT 2.10) Angel Debug Monitor rebuilt on Jan 20 1997 at 02:33:43 Connected to ARM RDI target. (gdb) load Loading section .rom_vectors, size 0x44 lma 0x60000 Loading section .text, size 0x1f3c lma 0x60044 Loading section .rodata, size 0x2c lma 0x61f80 Loading section .data, size 0x124 lma 0x61fac Start address 0x60044 , load size 8400 Transfer rate: 5169 bits/sec. (gdb) q The program is running. Exit anyway? (y or n) y On a UNIX or Linux system, the serial port must be /dev/ttyS0 instead of COM1. You need to make sure that the /dev/ttyS0 files have the right permissions: $ su Password: # chmod o+rw /dev/ttyS0* # exit If you are programming the GDB stub image, it will now be located at 0x60000..0x64000. If you are programming the Cygmon ROM Monitor, it will be located at 0x60000..0x80000. Now download the FLASH programmer tool bash$ arm-elf-gdb prog_flash.img GNU gdb 4.18-DEVTOOLSVERSION Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i586-pc-cygwin32 --target=arm-elf". (gdb) target rdi s=com1 Angel Debug Monitor for PID (Built with Serial(x1), Parallel, DCC) 1.00 (Advanced RISC Machines SDT 2.10) Angel Debug Monitor rebuilt on Jan 20 1997 at 02:33:43 Connected to ARM RDI target. (gdb) load Loading section .rom_vectors, size 0x44 lma 0x40000 Loading section .text, size 0x44a4 lma 0x40044 Loading section .rodata, size 0x318 lma 0x444e8 Loading section .data, size 0x1c8 lma 0x44800 Start address 0x40044 , load size 18888 Transfer rate: 5596 bits/sec. (gdb) c The FLASH tool will output some text on the board serial port B at 38400 baud: ARM eCos FLASH here! manuf: 8, device: 40 Error: Wrong Manufaturer: 08 ... Please change FLASH jumper This text is repeated until you remove the jumper 7-8 on LK6. Then the output will be: manuf: 1F, device: A4 AT29C040A recognised About to program FLASH using data at 60000..64000 *** Press RESET now to abort! You have about 10 seconds to abort the operation by pressing reset. After this timeout, the FLASH programming happens: ...Programming FLASH All done! Quit/kill the GDB process, which will hang. Next time you reset the board, the stub will be in control, communicating on Serial A at 38400 baud. 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: Program FLASH using the little-endian FLASH tool. After powering off, replace the ROM controller with the special big-endian version which can be acquired from ARM. (This has not been tested by Red Hat). Use a special big-endian version of the FLASH tool which byte-swaps all the words as they are written to the FLASH. 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. Program the binary image file gdb_module.bin into ROM referring to the instructions of your ROM programmer. Plug the ROM into socket U12 and install jumper LK6 pins 7-8 to enable the ROM. 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: talk to the AEB-1 board with a terminal emulator (or a real terminal!) use the board's rom menu to download a UU-encoded version of the GDB stubs which will act as a ROM monitor tell the board to use this new monitor, and then hook GDB up to it for real debugging 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. Pre-built 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. Start with a new document - selecting the File -> New menu item if necessary to do this. Choose the Build -> Templates menu item, and then select the ARM AEB-1 hardware. While still displaying the Build->Templates dialog box, select the "stubs" package template to build a GDB stub image. Click OK. If applicable, set the "AEB board revision" option to "C" from "B" depending on the board revision being used. Build eCos using Build -> Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new aeb stubs If applicable, edit ecos.ecc and set the AEB board revision. (CYGHWR_HAL_ARM_AEB_REVISION) from the default "B" to "C" by uncommenting the user_value property and setting it to "C". Enter the commands $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". 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. Pre-built 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). 1. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the ARM CMA230 hardware. While still displaying the Build -> Templates dialog box, select the "stubs" package template to build a GDB stub image. Click OK. Build eCos using Build -> Library When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". 1. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new cma230 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". 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. Pre-built 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). Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the "Cirrus Logic development board" hardware. While still displaying the Build -> Templates dialog box, select either the "stubs" package template to build a GDB stub image, or the "cygmon" template to build the CygMon ROM Monitor. Click OK. Build eCos using Build -> Library When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix "gdb_module". CygMon images have the prefix "cygmon". Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new edb7xxx stubs or to build a CygMon ROM monitor image, enter the command: $ ecosconfig new edb7xxx cygmon Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix "gdb_module". CygMon images have the prefix "cygmon". 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. Connect a serial line to 'UART 1'. Power off the EDB7211. Install jumper 'PROGRAM ENABLE' which enables this special mode for downloading Flash images. Note that some board revisions have this jumper labelled “BOOT ENABLE”. Power on the EDB7211. Execute the Flash writing program on your host. On Linux, this would be: # dl_edb7xxx <PATH>/gdb_module.bin where '<PATH>' is the path to the binary format version of the ROM image you wish to load, either as built in the previous section or the "loaders/arm-edb7211/" subdirectory of your eCos installation. The download tool defaults to 38400 baud and device /dev/ttyS1 for communication. To change these, specify them as parameters, e.g. # dl_edb7xxx <PATH>/gdb_module.bin 9600 /dev/ttyS0 The download program will indicate that it is waiting for the board to come alive. At this point, press 'RESET' and then 'WAKEUP' switches in order. There should be some indication of progress, first of the code being downloaded, then of the programming process. Upon completion of the programming, power off the EDB7211. Remove the 'PROGRAM ENABLE/BOOT ENABLE' jumper. Power on the EDB7211, press 'RESET' and 'WAKEUP'. The new ROM image should now be running on the board. The GDB debugger will now be able to communicate with the board to download and debug RAM based programs. 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 GDB Stub ROM/CygMon in Flash, so you would have to reload the GDB Stub ROM/CygMon to return to normal RAM-startup program development. 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/&Version;/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: The first serial port is silk screened as "UART 1" on the EP7211 Development Board, but is silk screened as "Serial Port 0" on the EP7212 Development Board. Similarly "UART 2" is silk screened as "Serial Port 1" on the EP7212 Development Board. JP2 (used to control reprogramming of the FLASH) is not silkscreened with "Boot Enable". To setup the EP7212 Development Board for use with the ARM Multi-ICE JTAG debugging interface unit, it is necessary to connect TEST0 and TEST1 of the EP7212 to ground. On the Development Board, this is accomplished by placing shorting blocks on JP47 and JP48. When the shorting blocks are fitted, the board can only be operated through the Multi-ICE - debugging over a serial line is not possible. Pre-built GDB stubs are provided in the directory loaders/arm-edb7212 relative to the root of your eCos installation When rebuilding the GDB stub ROM image, change the "Cirrus Logic processor variant" option (CYGHWR_HAL_ARM_EDB7XXX_VARIANT) from the EP7211 to the EP7212. This can be selected in the eCos Configuration Tool , or if using ecosconfig, can be set by uncommenting the user_value property of this option in ecos.ecc and setting it to "EP7212". The Cirrus Logic EP7312 Development Board is similar to the EP7212 Development Board from a hardware setup viewpoint, and is based on the same port of eCos. When rebuilding the RedBoot ROM image or an eCos application, change the "Cirrus Logic processor variant" option (CYGHWR_HAL_ARM_EDB7XXX_VARIANT) from the EP7211 to the EP7312. This can be selected in the eCos Configuration Tool , or if using ecosconfig, can be set by uncommenting the user_value property of this option in ecos.ecc and setting it to "EP7312". See the RedBoot documentation for building and installing RedBoot for this target. Only RedBoot is supported as a boot image; ROMRAM startup is recommended. The EP7xxx targets offer a choice of clock speeds, from 18MHz to a maximum, normally, of 72MHz. These are described as kHz values 18432 36864 49152 and 73728 within the configuration tool. If you have a release which supports it, you will also see 90317 as an available option here, for 90MHz operation. This option only applies to certain EP7312 hardware, not all EP7312 boards support it. Do not select 90MHz when building RedBoot or your eCos application unless you are absolutely sure that your board supports it. If you do have a 90MHz board and wish to execute at 90MHz, it is in fact not necessary to build RedBoot specially, if you build your eCos application configured for 90MHz. RedBoot will run at 72MHz and your application will run at 90MHz. If you do install a 90MHz RedBoot, then you must build eCos for 90MHz or timing and baud rates on serial I/O will be wrong. In other words, code (either eCos app or RedBoot) built for 90MHz will “change up a gear” when it starts up; but code built for 72MHz, because it needs to run correctly on boards without the “gearbox” does not change back down, so if you mix the two, unexpected timing can result. To run a non-eCos application without any hardware initialization code at 90MHz, you must install a specially-built RedBoot. 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 Cygmon ROM monitor is not supported The ARM Multi-ICE is not supported Pre-built GDB stubs are provided in the directory loaders/arm-eb7111 relative to the root of your eCos installation If rebuilding the GDB stub ROM image, change the "Cirrus Logic processor variant" option (CYGHWR_HAL_ARM_EDB7XXX_VARIANT) from the EP7211 to the CL_PS7111. This can be selected in the eCos Configuration Tool , or if using ecosconfig, can be set by uncommenting the user_value property of this option in ecos.ecc and setting it to "CL_PS7111" All remote serial communication is done with the serial I/O connector /misc % slow_cat.tcl < [path]/gdb_module.srec > /dev/ttyS0 Power off the board, and change it to boot the GDB stubs in big-endian mode by setting the switches like this: SW1: 00000000 (all levers down) SW2: 10001010 The GDB stubs allow communication with GDB using the serial port at connector PJ7A (lower connector). 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 straight through serial cable. 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. Pre-built 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. Start with a new document - selecting the File -> New menu item if necessary to do this. Choose the Build -> Templates menu item, and then select the StrongARM EBSA285 hardware. While still displaying the Build -> Templates dialog box, select the "stubs" package template to build a GDB stub image. Click OK. Build eCos using Build -> Library When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". (See “Using ecosconfig on UNIX” on page 72) Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new ebsa285 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. The GDB stub ROM images have the prefix "gdb_module". 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 <BASE_DIR>/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. make 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. You must first load the StubROM image into the flash memory on the EBSA-285 board before doing this. See “Loading the ROM Image into On-board Flash”, page 93 for details. Connect to the StubROM in the board and run your eCos program <PROGRAM> as follows: $ arm-elf-gdb -nw <PROGRAM> (gdb) set remotebaud 38400 (gdb) target remote <DEVICE> Where <DEVICE> is /dev/ttyS0 or COM1: or similar, depending on your environment and how you connected your serial line to the host computer. Expect some output here, for example: Remote debugging using /dev/ttyS0 0x410026a4 in ?? () then, to load the program (gdb) load which will report locations and sizes of sections as they load, then begin execution using (gdb) continue If you have no eCos program yet, but you want to connect to the board just to verify serial communications, tell gdb "set endian little" before anything else, so that it understands the board (GDB normally infers this from information within the eCos program). When an eCos program is run on the EBSA-285 board, the GDB stub in ROM loses control. This means that if you require the ability to stop execution on the target remotely, or want thread debugging capabilities, you must include GDB stub support when configuring eCos. For setting up the iPAQ to run with RedBoot, see the the RedBoot User's Guide. Connections may be made using the Compact Flash Ethernet interface. A serial cable may be connected directly, or via the cradle. Serial communication uses the parameters 38400,8,N,1. The LCD/Touchscreen may also be used as an interface to RedBoot and eCos applications. The Arm Industrial Module AIM 711 comes with RedBoot installed as the default boot loader. For developing without having a finished custom board, a starter-kit with a minimally configured board is available. It offers all the connectors needed for development, including serial device, Ethernet, power supply and an extra connector for the external bus. A 6V - 7.5V power supply must be connected to J2 or TB1. At J2 the inner pin is V+ and at TB1 it is pin 1. The AIM 711 has 3 serial devices, which are the debug and diagnostic channel COM0 (/dev/ser0), the high performance 16550 UART COM1 (/dev/ser1) and the second internal device COM2 (/dev/ser2). To use the debug channel, which is also the default for RedBoot, the supplied DB9-male cable must be connected to CN4. If the also available service board is used, the above connector must be disabled by setting JP1. COM1 is available over the RJ45 connector CN2. This device can be configured as a RS232, RS422, RS485 or TTL level COM2 is only available with TTL level at CN5. The RJ45 connector CN1 is for Ethernet. In order that Redboot can overwrite itself, Redboot is built as a ROMRAM image. Load the RedBoot binary to the next free space: RedBoot> load -m tftp -h 192.168.1.36 -r -b 0x40000 redboot.bin Raw file loaded 0x00040000-0x00063233, assumed entry at 0x00040000 Store it in FLASH: RedBoot> fis create RedBoot An image named 'RedBoot' exists - continue (y/n)? y ... Erase from 0x02000000-0x02025000: ..................................... ... Program from 0x00040000-0x00063234 at 0x02000000: .......................... .......... ... Erase from 0x021ff000-0x02200000: . ... Program from 0x007ff000-0x00800000 at 0x021ff000: . Restart the AIM 711: RedBoot> reset ... Resetting. To rewrite the FLASH using JTAG the service board must be used, which includes a JTAG connector. For more information please look at http://www.visionsystems.de/arm7.html. The eCos Developer’s Kit package comes with a ROM which provides GDB support for the Hitachi EDK7708 board (a big-endian and a little-endian version). Images of these ROMs are also provided at loaders/sh-edk7708/gdbload.bin and loaders/sh-edk7708le/gdbload.bin under the root of your eCos installation. The ROM is installed to socket U6 on the board. When using the big-endian ROM, jumper 9 must be set to 2-3. When using the little-endian ROM, jumper 9 must be set to 1-2. Attention should be paid to the correct orientation of the ROM during installation. Only replace the board"s existing ROM using a proper PLCC extraction tool, as the socket would otherwise risk being damaged. If you are going to program a new ROM or FLASH using the binary image, you may have to experiment to get the right byte-order in the device. Depending on the programming software you use, it might be necessary to enable byte-swapping. If the GDB stub ROM/FLASH you program does not work, try reversing the byte-order. The GDB stub in the EPROM allows communication with GDB using the serial port at connector J1. 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 the dedicated serial cable included in the EDK package. These two binary preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled binaries in the directory loaders/sh-edk7708 and loaders/sh-edk7708le relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the SH EDK7708 hardware. While still displaying the Build->Templates dialog box, select the “stubs” package template to build a GDB stub. Click OK. If building a little-endian image, disable the “Use big-endian mode” option in the SH EDK7708 HAL (CYGHWR_HAL_SH_BIGENDIAN). Build eCos using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new edk7708 stubs If building a little-endian image, uncomment the user value in ecos.ecc for CYGHWR_HAL_SH_BIGENDIAN and change it to 0. Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Program the binary image file gdb_module.bin into ROM or FLASH referring to the instructions of your ROM programmer. Plug the ROM/FLASH into socket U6. If the image is little-endian set jumper 9 to 1-2. If the image is big-endian set jumper 9 to 2-3. Make sure the DIP switches on the board are set as follows: SW1-1 ON SW1-2 OFF SW1-3 ON SW1-4 OFF SW2-1 ON SW2-2 ON SW2-3 OFF SW2-4 OFF If you are using a straight through serial cable which has flow control lines, you will also need to cut JP12 (5-6) as the flow control lines can cause NMIs. The eCos installation CD contains a copy of the eCos GDB stubs in binary format which must be programmed into an EPROM or FLASH and installed on the board. These stub preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled stubs in the directory loaders/sh3-cq7708 relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the SH3 cq7708 hardware. While still displaying the Build->Templates dialog box, select the stubs package template to build a GDB stub. Click OK. Build eCos stubs using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new cq7708 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. The board can use different sizes of ROMs. Use this table to adjust the board’s jumpers to the ROM sizes you are using. size(kbit) JP7 JP9 JP10 JP11 256 2-3 2-3 open open 512 1-2 2-3 open open 1000 1-2 open open 2-3 2000 1-2 1-2 open 2-3 4000 1-2 1-2 short 2-3 8000 1-2 1-2 short 1-2 There are two ways to program the stubs. We advise you to use method 1, since it is simpler. Method 2 is unsupported and requires a bit of fiddling. Method 1: Program the binary stub image into two EPROMs, E and O. EPROM E should contain the even bytes, and O the odd bytes (your EPROM programmer should have the ability to split the image). EPROM E should be installed in socket IC8, and EPROM O should be installed in socket IC4. Set JP6 to 16 bit mode (1-2 soldered, 2-3 cut) Set SW1-4 to ON and SW2-1 to OFF. Method2: Assuming that the stub binary is smaller than 32 KB, you can install it in a single EPROM. Compile the mkcqrom.c program found in the misc directory. Use it to convert the binary image to the required format. See the mkcqrom.c source for a description of what is done, and why it is necessary. % mkcqrom gdb_module.bin gdb_mangled.bin Program the gdb_mangled.bin file into an EPROM and install it in socket IC4 Set JP6 to 8 bit mode (cut 1-2, solder 2-3) The GDB stubs allow communication with GDB using the serial port at connector CN7. 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 straight through serial cable. Please see the RedBoot manual for instructions on how to prepare the board for use with eCos. Please see the RedBoot manual for instructions on how to prepare the board for use with eCos. Make sure the DIP switches on the board are set as follows: SW1-1 ON SW1-2 OFF SW1-3 ON SW1-4 OFF SW2-1 ON SW2-2 ON SW2-3 OFF SW2-4 OFF If you are using a straight through serial cable which has flow control lines, you will also need to cut JP12 (5-6) as the flow control lines can cause NMIs. The eCos installation CD contains a copy of the eCos GDB stubs in binary format which must be programmed into an EPROM or FLASH and installed on the board. These stub preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled stubs in the directory loaders/sh3-cq7708 relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the SH3 cq7708 hardware. While still displaying the Build->Templates dialog box, select the stubs package template to build a GDB stub. Click OK. Build eCos stubs using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new cq7708 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub images have the prefix gdb_module. The board can use different sizes of ROMs. Use this table to adjust the board’s jumpers to the ROM sizes you are using. size(kbit) JP7 JP9 JP10 JP11 256 2-3 2-3 open open 512 1-2 2-3 open open 1000 1-2 open open 2-3 2000 1-2 1-2 open 2-3 4000 1-2 1-2 short 2-3 8000 1-2 1-2 short 1-2 There are two ways to program the stubs. We advise you to use method 1, since it is simpler. Method 2 is unsupported and requires a bit of fiddling. Method 1: Program the binary stub image into two EPROMs, E and O. EPROM E should contain the even bytes, and O the odd bytes (your EPROM programmer should have the ability to split the image). EPROM E should be installed in socket IC8, and EPROM O should be installed in socket IC4. Set JP6 to 16 bit mode (1-2 soldered, 2-3 cut) Set SW1-4 to ON and SW2-1 to OFF. Method2: Assuming that the stub binary is smaller than 32 KB, you can install it in a single EPROM. Compile the mkcqrom.c program found in the misc directory. Use it to convert the binary image to the required format. See the mkcqrom.c source for a description of what is done, and why it is necessary. % mkcqrom gdb_module.bin gdb_mangled.bin Program the gdb_mangled.bin file into an EPROM and install it in socket IC4 Set JP6 to 8 bit mode (cut 1-2, solder 2-3) The GDB stubs allow communication with GDB using the serial port at connector CN7. 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 straight through serial cable. Please see the RedBoot manual for instructions on how to prepare the board for use with eCos. The CEB-V850 board is fitted with a socketed EPROM. The internal Flash of the V850 supplied with the CEB-V850 boards defaults to vectoring into this EPROM. A GDB stub image should be programmed into an EPROM fitted to this board, and a pre-built image is provided at loaders/v850-ceb_v850/v850sa1/gdb_module.bin under the root of your eCos installation. The EPROM is installed to the socket labelled U7 on the board. Attention should be paid to the correct orientation of the EPROM during installation. When programming an EPROM using the binary image, be careful to get the byte order correct. It needs to be little-endian. If the EPROM burner software has a hex-editor, check that the first few bytes of the image look similar to: 00000000: 0018 8007 5e02 0000 0000 0000 0000 0000 If the byte order is wrong you will see 1800 instead of 0018 etc. Use the EPROM burner software to make a byte-swap before you burn to image to the EPROM. 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. 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 CEB-V850/SA1 manual. These two binary preparation steps are not strictly necessary as the eCos distribution ships with pre-compiled binaries in the directory loaders/v850-ceb_v850 relative to the installation root. Start with a new document - selecting the File->New menu item if necessary to do this. Choose the Build->Templates menu item, and then select the NEC CEB-V850/SA1 hardware. While still displaying the Build->Templates dialog box, select the “stubs” package template to build a GDB stub. Click OK. Build eCos using Build->Library. When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Make an empty directory to contain the build tree, and cd into it. To build a GDB stub ROM image, enter the command: $ ecosconfig new ceb-v850 stubs Enter the commands: $ ecosconfig tree $ make When the build completes, the image files can be found in the bin/ subdirectory of the install tree. GDB stub ROM images have the prefix “gdb_module”. Program the binary image file gdb_module.bin into ROM or FLASH referring to the instructions of your ROM programmer. Plug the ROM/FLASH into the socket as described at the beginning of this section. eCos applications may be debugged using the NEC V850 In Circuit Emulator (I.C.E.) A PC running Microsoft Windows is required in order to run the NEC ICE software and drivers. In addition Red Hat have developed a “libremote” server application named v850ice.exe which is used on the PC connected to the I.C.E. in order to allow connections from GDB. The I.C.E. must be physically connected to a Windows NT system through NEC"s PCI or PC Card interface. A driver, DLLs, and application are provided by NEC to control the I.C.E. v850ice is a Cygwin based server that runs on the NT system and provides an interface between the gdb client and the I.C.E. software. v850-elf-gdb may be run on the Windows NT system or on a remote system. v850-elf-gdb communicates with the libremote server using the gdb remote protocol over a TCP/IP socket. v850ice communicates with the I.C.E. by calling functions in the NECMSG.DLL provided by NEC. Configure the hardware including the I.C.E., SA1 or SB1 Option Module, and target board. Install the interface card in the Windows NT system. Reference NEC"s documentation for interface installation, jumper settings, etc. Install the Windows NT device driver provided by NEC. Copy the NEC DLLs, MDI application, and other support files to a directory on the Windows NT system. The standard location is C:\NecTools32. This directory will be referred to as the "libremote server directory" in this document. v850ice.exe must also be copied to this directory after being built. The required files are: cpu.cfg, Nec.cfg, MDI.EXE, NECMSG.DLL, EX85032.DLL, V850E.DLL, IE850.MON, IE850E.MON, and D3037A.800. Make certain the file cpu.cfg contains the line: CpuOption=SA1 if using a V850/SA1 module, or: CpuOption=SB1 if using a V850/SB1 module. Set the environment variable IEPATH to point to the libremote server directory. A pre-built v850ice.exe executable is supplied in the loaders/v850-ceb_v850 directory relative to the root of the eCos installation. However the following process will allow the rebuilding of this executable if required: For this example assume the v850ice libremote tree has been copied to a directory named "server". The directory structure will be similar to the following diagram: server | devo / \ config libremote / \ lib v850ice Build the v850ice source as follows. Be sure to use the native Cygwin compiler tools that were supplied alongside eCos. cd server mkdir build cd build ../devo/configure --target=v850-elf --host=i686-pc-cygwin make The resultant libremote server image (v850ice.exe) can be found in build/libremote/v850ice. Copy v850ice.exe to the lib remote server directory. The v850ice command line syntax is: v850ice [-d] [-t addr] [port number] The optional -d option enables debug output. The -t option is associated with thread debugging - see the "eCos thread debugging" section below for details. By default v850ice listens on port 2345 for an attach request from a gdb client. A different port number may be specified on the command line. To run the libremote server: Power on the I.C.E. and target board. Open a Cygwin window. Run v850ice. You will see the MDI interface window appear. In this window you should see the "Connected to In-Circuit Emulator" message. In the Cygwin window, the libremote server will indicate it is ready to accept a gdb client connection with the message "v850ice: listening on port 2345." Run the v850-elf-gdb client to debug the V850 target. It is necessary to issue certain configuration commands to the I.C.E. software. These commands may be issued directly in the MDI window or they may be issued from the gdb client through the "monitor" command. On the Cosmo CEB-V850 board, on-chip Flash is mapped at address 0x0, the on-board EPROM at 0x100000 and the on-board RAM at 0xfc0000. Since a stand alone V850 will start executing from address 0x0 on reset, it is normal to load either an application or a bootstrap loader for Flash at this address. eCos programs may be built to boot from Flash or the on-board EPROM. If building for the on-board EPROM, it would be expected that the Flash will contain the default CEB-V850 flash contents. An ELF format version of the default contents may be found in the eCos distribution with the name v850flash.img. In stand alone operation, normally the code in this flash image would have been programmed into the V850 on the Cosmo board, and this would cause it to vector into the on-board EPROM to run the application located there. In the case of eCos, this application may be a GDB stub ROM application, allowing the further download to RAM over serial of actual applications to debug. As an example, we shall demonstrate how to use the I.C.E. to download the v850flash.img and GDB stub EPROM image using I.C.E. emulator memory only, and not requiring any actual programming of devices. v850-elf-gdb -nw (gdb) file v850flash.img (gdb) target remote localhost:2345 (gdb) monitor reset (gdb) monitor cpu r=256 a=16 (gdb) monitor map r=0x100000-L 0x80000 (gdb) monitor map u=0xfc0000-L 0x40000 (gdb) monitor pinmask k (gdb) monitor step (gdb) monitor step (gdb) monitor step (gdb) monitor step (gdb) load (gdb) detach (gdb) file gdb_module.img (gdb) target remote localhost:2345 (gdb) load (gdb) continue NOTE: The four "monitor step" commands are only required the first time the board is connected to the I.C.E., otherwise the program will fail. This is because of a limitation of the I.C.E. hardware that means that the first time it is used, the "map" commands are not acted on and the addresses "0x100000" and "0xfc0000" are not mapped. This can be observed using the command "td e-20" in the MDI application"s console to display the trace buffer, which will show that the contents of address 0x100000 are not valid. Subsequent runs do not require the "monitor step" commands. It is unusual to load two executable images to a target through gdb. From the example above notice that this is accomplished by attaching to the libremote server, loading the flash image, detaching, reattaching, and loading the ROM/RAM image. It is more normal to build an executable image that can be executed directly. In eCos this is achieved by selecting either the ROM or ROMRAM startup type, and optionally enable building for the internal FLASH. The I.C.E. emulator memory can emulate both the internal FLASH and the EPROM, so real hardware programming is not required. Upon running this example you will notice that the libremote server does not exit upon detecting a detach request, but simply begins listening for the next attach request. To cause v850ice to terminate, issue the "monitor quit" or "monitor exit" command from the gdb client. v850ice will then terminate with the next detach request. (You can also enter control-c in the Cygwin/DOS window where v850ice is running.) If a filename is referenced in an MDI command, whether the command is entered in the MDI window or issued from the gdb client with the monitor command, the file must reside on the Windows NT libremote server system. When specifying a filename when entering a command in the MDI window it is obvious that a server local file is being referenced. When issuing an MDI command from the gdb client, the user must remember that the command line is simply passed to the I.C.E. software on the server system. The command is executed by the I.C.E. software as though it were entered locally. Executable images may be loaded into the V850 target by entering the "load" command in the MDI window or with the gdb "load" command. If the MDI load command is used, the executable image must be located on the server system and must be in S Record format. If the gdb load command is used, the executable image must be located on the client system and must be in ELF format. Be aware that the gdb client is not aware of debugger commands issued from the MDI window. It is possible to cause the gdb client and the I.C.E. software to get out of sync by issuing commands from both interfaces during the same debugging session. eCos and the V850 I.C.E. libremote server have been written to work together to allow debugging of eCos threads. This is an optional feature, disabled by default because of the overheads trying to detect a threaded program involves. Obviously thread debugging is not possible for programs with "RAM" startup type, as they are expected to operate underneath a separate ROM monitor (such as a GDB stub ROM), that itself would provide its own thread debugging capabilities over the serial line. Thread debugging is relevant only for programs built for Flash, ROM, or ROMRAM startup. To configure the libremote server to support thread debugging, use the command: (gdb) monitor syscallinfo ADDRESS at the GDB console prompt, where ADDRESS is the address of the syscall information structure included in the applications. In eCos this has been designed to be located at a consistent address for each CPU model (V850/SA1 or V850/SB1). It may be determined from an eCos executable using the following command at a cygwin bash prompt: v850-elf-nm EXECUTABLE | grep hal_v85x_ice_syscall_info At the current time, this address is 0xfc0400 for a Cosmo board fitted with a V850/SA1, or 0xfc0540 for a Cosmo board fitted with a V850/SB1. So for example, the GDB command for the SB1 would be: (gdb) monitor syscallinfo 0xfc0540 Given that the syscallinfo address is fixed over all eCos executables for a given target, it is possible to define it on the libremote command line as well using the "-t" option, for example: bash$ v850ice -t 0xfc0400 v850ice: listening on port 2345 The instructions for setting up the CEB-V850/SB1 are virtually identical to those of the CEB-V850/SA1 above. The only significant differences are that pre-built loaders are available at loaders/v850-ceb_v850/v850sb1 within the eCos installation. Binaries supporting boards with both 16MHz and 8MHz clock speeds are supplied. Also when building applications, or rebuilding the stubs for a V850/SB1 target, then the V850 CPU variant must be changed in the CEB-V850 HAL to the SB1. eCos application on the PC can be run in three ways: via RedBoot, loaded directly from a floppy disk, or loaded by the GRUB bootloader. For information about setting up the PC to run with RedBoot, consult the RedBoot User"s Guide. If using serial debugging, the serial line runs at 38400 baud 8-N-1 and should be connected to the debug host using a null modem cable. If ethernet debugging is required, an i82559 compatible network interface card, such as an Intel EtherExpress Pro 10/100, should be installed on the target PC and connected to the development PC running GDB. When RedBoot is configured appropriately to have an IP address set, then GDB will be able to debug directly over TCP/IP to the target PC. If an application is built with a startup type of FLOPPY, then it is configured to be a self-booting image that must be written onto a formatted floppy disk. This will erase any existing file system or data that is already on the disk, so proceed with caution. To write an application to floppy disk, it must first be converted to a pure binary format. This is done with the following command: $ i386-elf-objcopy -O binary app.elf app.bin Here app.elf is the final linked application executable, in ELF format (it may not have a .elf extension). The file app.bin is the resulting pure binary file. This must be written to the floppy disk with the following command: $ dd conv=sync if=app.bin of=/dev/fd0 For NT Cygwin users, this can be done by first ensuring that the raw floppy device is mounted as /dev/fd0. To check if this is the case, type the command mount at the Cygwin bash prompt. If the floppy drive is already mounted, it will be listed as something similar to the following line: \\.\a: /dev/fd0 user binmode If this line is not listed, then mount the floppy drive using the command: $ mount -f -b //./a: /dev/fd0 To actually install the boot image on the floppy, use the command: $ dd conv=sync if=app.bin of=/dev/fd0 Insert this floppy in the A: drive of the PC to be used as a target and ensure that the BIOS is configured to boot from A: by default. On reset, the PC will boot from the floppy and the eCos application will load itself and execute immediately. Unreliable floppy media may cause the write to silently fail. This can be determined if the RedBoot image does not correctly boot. In such cases, the floppy should be (unconditionally) reformatted using the fdformat command on Linux, or format a: /u on DOS/Windows. If this fails, try a different disk. If an application is built with the GRUB startup type, it is configured to be loaded by the GRUB bootloader. GRUB is an open source boot loader that supports many different operating systems. It is available from http://www.gnu.org/software/grub. The latest version of GRUB should be downloaded from there and installed. In Red Hat Linux version 7.2 and later it is the default bootloader for Linux and therefore is already installed. To install GRUB on a floppy disk from Linux you need to execute the following commands: $ mformat a: $ mount /mnt/floppy $ grub-install --root-directory=/mnt/floppy '(fd0)' Probing devices to guess BIOS drives. This may take a long time. Installation finished. No error reported. This is the contents of the device map /mnt/floppy/boot/grub/device.map. Check if this is correct or not. If any of the lines is incorrect, fix it and re-run the script `grub-install'. (fd0) /dev/fd0 $ cp $ECOS_REPOSITORY/packages/hal/i386/pc/current/misc/menu.lst /mnt/floppy/boot/grub $ umount /mnt/floppy The file menu.lst is an example GRUB menu configuration file. It contains menu items to load some of the standard eCos tests from floppy or from partition zero of the first hard disk. You should, of course, customize this file to load your own application. Alternatively you can use the command-line interface of GRUB to input commands yourself. Applications can be installed, or updated simply by copying them to the floppy disk at the location expected by the menu.lst file. For booting from floppy disks it is recommended that the executable be stripped of all debug and symbol table information before copying. This reduces the size of the file and can make booting faster. To install GRUB on a hard disk, refer to the GRUB documentation. Be warned, however, that if you get this wrong it may compromise any existing bootloader that exists on the hard disk and may make any other operating systems unbootable. Practice on floppy disks or sacrificial hard disks first. On machines running Red Hat Linux version 7.2 and later, you can just add your own menu items to the /boot/grub/menu.lst file that already exists. If an application is built with the GRUB startup type, it is configured to be loaded by the GRUB bootloader. GRUB 2 is an open source boot loader that supports many different operating systems. GRUB 2 is the sucessor to the legacy GRUB boot loader. It has been rewritten and requires a new configuration file that is different from the legacy GRUB loader. It is available from http://www.gnu.org/software/grub. The latest version of GRUB should be downloaded from there and installed. Cygwin users will need to install the GRand Unified Bootloader package on their system. To install GRUB 2 on a disk drive from Cygwin you will first need to format your disk. Begin by launching a windows Command Prompt with ADMINISTRATOR priviledges. This example assumes that your destination drive is E and the filesystem type is FAT32. $ format e: /fs:fat32 /q The type of the file system is FAT32. WARNING, ALL DATA ON NON-REMOVABLE DISK DRIVE E: WILL BE LOST! Proceed with Format (Y/N)? y QuickFormatting 512M Initializing the File Allocation Table (FAT)... Volume label (11 characters, ENTER for none)? Format complete. When your drive is finished formatting, Cygwin will automatically mount the drive under /cygdrive/e. Next, launch a bash shell. Cygwin users should run their shell as ADMINISTRATOR otherwise the grub-install program will fail. To install GRUB we need to know the device name for your disk. A second disk drive is usually called /dev/sdb. The C: drive is usually called /dev/sda. Determine your device name by reading the /proc/partitions file. This example uses /dev/sdb as input to the GRUB install program. $ cat /proc/partitions major minor #blocks name 8 0 156290904 sda 8 1 102400 sda1 8 2 156185600 sda2 8 16 156290904 sdb 8 17 524288 sdb1 $ grub-install --root-directory=/cygdrive/e /dev/sdb Installation finished. No error reported. $ cp $ECOS_REPOSITORY/packages/hal/i386/pc/current/misc/grub.cfg /cygdrive/e/boot/grub $ cp redboot.elf /cygdrive/e/boot After installing GRUB 2, we need to a copy a configuration file for grub to use. The file grub.cfg is an example configuration file that loads redboot.elf. You should, of course, customize this file to load your own application. Alternatively you can use the command-line interface of GRUB to input commands yourself. Applications can be installed or updated simply by copying them to the location expected by the grub.cfg file. In this example the /boot directory is used. When installing GRUB on a hard disk, refer to the GRUB documentation. Be warned, however, that if you get this wrong it may compromise any existing bootloader that exists on the hard disk and may make any other operating systems unbootable. Practice on a spare disk or sacrificial hard disks first. When RedBoot loads an application it also provides debugging services in the form of GDB remote protocol stubs. When an application is loaded stand-alone from a floppy disk, or by GRUB, these services are not present. To allow these application to be debugged, it is possible to include GDB stubs into the application. To do this, set the "Support for GDB stubs" (CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS) configuration option. Following this any application built will allow GDB to connect to the debug serial port (by default serial device 0, also known as COM1) whenever the application takes an exception, or if a Control-C is typed to the debug port. Ethernet debugging is not supported. The option "Enable initial breakpoint" (CYGDBG_HAL_DEBUG_GDB_INITIAL_BREAK) causes the HAL to take a breakpoint immediately before calling cyg_start(). This gives the developer a chance to set any breakpoints or inspect the system state before it proceeds. The configuration sets this option by default if GDB stubs are included, and this is not a RedBoot build. To make the application execute immediately either disable this option, or disable CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS. 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 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 editing 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://ecos.sourceware.org/getstart.html