Overview

In a typical development environment the M5272C3 board boots from flash into the RedBoot ROM monitor. eCos applications are configured for a RAM startup, and then downloaded and run on the board via the debugger m68k-elf-gdb. Preparing the board therefore involves programming a suitable RedBoot image into flash memory.

The following RedBoot configurations are supported:

For serial communications all versions run with 8 bits, no parity, and 1 stop bit. The dBUG version runs at 19200 baud. The ROM and RAM versions run at 38400 baud. These baud rates can be changed via the configuration option CYGNUM_HAL_M68K_MCFxxxx_DIAGNOSTICS_BAUD and rebuilding RedBoot. By default RedBoot will use the board's terminal port, corresponding to uart0, but this can also be changed via the configuration option CYGHWR_HAL_M68K_MCFxxxx_DIAGNOSTICS_PORT. On an M5272C3 platform RedBoot also supports ethernet communication and flash management.

Initial Installation

This process assumes that the board still has its original dBUG ROM monitor and does not require any special debug hardware. It leaves the existing ROM monitor in place, allowing the setup process to be repeated just in case that should ever prove necessary.

Programming the RedBoot rom monitor into flash memory requires an application that can manage flash blocks. RedBoot itself has this capability. Rather than have a separate application that is used only for flash management during the initial installation, a special RAM-resident version of RedBoot is loaded into memory and run. This version can then be used to load the normal flash-resident version of RedBoot and program it into the flash.

The first step is to connect an RS232 cable between the M5272C3 terminal port and the host PC. A suitable cable is supplied with the board. Next start a terminal emulation application such as HyperTerminal or minicom on the host PC and set the serial communication parameters to 19200 baud, 8 data bits, no parity, 1 stop bit (8N1) and no flow control (handshaking). Make sure that the jumper next to the flash chip is set for bootstrap from the bottom of flash, location 0xFFE00000. The details of this jumper depend on the revision of the board, so the supplied board documentation should be consulted for more details. Apply power to the board and you should see a dBUG> prompt.

Once dBUG is up and running the RAM-resident version of RedBoot can be downloaded:

dBUG> dl
Escape to local host and send S-records now...

The required S-records file is redboot_dbug.srec, which is normally supplied with the eCos release in the loaders directory. If it needs to be rebuilt then instructions for this are supplied below. The file should be sent to the target as raw text using the terminal emulator:

S-record download successful!
dBUG>

It is now possible to run the RAM-resident version of RedBoot:

dBUG> go 0x20000
+FLASH configuration checksum error or invalid key
Ethernet eth0: MAC address 00:00:00:00:00:03
Can't get BOOTP info for device!

RedBoot(tm) bootstrap and debug environment [DBUG]
Non-certified release, version v2_0_1 - built 09:55:34, Jun 24 2003

Platform: M5272C3 (Freescale MCF5272)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.

RAM: 0x00000000-0x00400000, 0x0003f478-0x003bd000 available
FLASH: 0xffe00000 - 0x00000000, 8 blocks of 0x00040000 bytes each.
RedBoot>

At this stage the RedBoot flash management initialization has not yet happened so the warning about the configuration checksum error is expected. To perform this initialization use the fis init -f command:

RedBoot> fis init -f
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xfff40000-0xfffc0000: ..
... Erase from 0x00000000-0x00000000:
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot>

The flash chip on the M5272C3 board is slow at erasing flash blocks so this operation can take some time. At the end the block of flash at location 0xFFFC0000 holds information about the various flash blocks, allowing other flash management operations to be performed. The next step is to set up RedBoot's non-volatile configuration values:

RedBoot> fconfig -i
Initialize non-volatile configuration - continue (y/n)? y
Run script at boot: false
Use BOOTP for network configuration: true
DNS server IP address:
GDB connection port: 9000
Force console for special debug messages: false
Network hardware address [MAC]: 0x00:0x00:0x00:0x00:0x00:0x03
Network debug at boot time: false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot>

For most of these configuration variables the default value is correct. If there is no suitable BOOTP service running on the local network then BOOTP should be disabled, and instead RedBoot will prompt for a fixed IP address, netmask, and addresses for the local gateway and DNS server. The other exception is the network hardware address, also known as MAC address. All boards should be given a unique MAC address, not the one in the above example. If there are two boards on the same network trying to use the same MAC address then the resulting behaviour is undefined.

It is now possible to load the flash-resident version of RedBoot. Because of the way that flash chips work it is better to first load it into RAM and then program it into flash.

RedBoot> load -r -m ymodem -b %{freememlo}

The file redboot_rom.bin should now be uploaded using the terminal emulator. The file is a raw binary and should be transferred using the Y-modem protocol.

Raw file loaded 0x0003f800-0x000545a3, assumed entry at 0x0003f800
xyzModem - CRC mode, 2(SOH)/84(STX)/0(CAN) packets, 5 retries
RedBoot>

Once RedBoot has been loaded into RAM it can be programmed into flash:

RedBoot> fis create RedBoot -b %{freememlo}
An image named 'RedBoot' exists - continue (y/n)? y
... Erase from 0xfff00000-0xfff40000: .
... Program from 0x0003f800-0x0007f800 at 0xfff00000: .
... Erase from 0xfffc0000-0xffffffff: .
... Program from 0x003bf000-0x003ff000 at 0xfffc0000: .
RedBoot>

The flash-resident version of RedBoot has now programmed at location 0xFFF00000, and the flash info block at 0xFFFC0000 has been updated. The initial setup is now complete. Power off the board and set the flash jumper to boot from location 0xFFF00000 instead of 0xFFE00000. Also set the terminal emulator to run at 38400 baud (the usual baud rate for RedBoot), and power up the board again.

+Ethernet eth0: MAC address 00:00:00:00:00:03
Can't get BOOTP info for device!

RedBoot(tm) bootstrap and debug environment [ROM]
Non-certified release, version v2_0_1 - built 09:57:50, Jun 24 2003

Platform: M5272C3 (Freescale MCF5272)
Copyright (C) 2000, 2001, 2002, Free Software Foundation, Inc.

RAM: 0x00000000-0x00400000, 0x0000b400-0x003bd000 available
FLASH: 0xffe00000 - 0x00000000, 8 blocks of 0x00040000 bytes each.
RedBoot>

When RedBoot issues its prompt it is also ready to accept connections from m68k-elf-gdb, allowing eCos applications to be downloaded and debugged.

Occasionally it may prove necessary to update the installed RedBoot image. This can be done simply by repeating the above process, using dBUG to load the dBUG version of RedBoot redboot_dbug.srec. Alternatively the existing RedBoot install can be used to load a RAM-resident version, redboot_ram.bin.

The ROMFFE version of RedBoot can be installed at location 0xFFE00000, replacing dBUG. This may be useful if the system needs more flash blocks than are available with the usual ROM RedBoot. Installing this RedBoot image will typically involve a BDM-based utility.

Rebuilding RedBoot

Should it prove necessary to rebuild a RedBoot binary, this is done most conveniently at the command line. The steps needed to rebuild the dBUG version of RedBoot are:

$ mkdir redboot_dbug
$ cd redboot_dbug
$ ecosconfig new m5272c3 redboot
$ ecosconfig import $ECOS_REPOSITORY/hal/m68k/mcf52xx/mcf5272/m5272c3/v2_0_1/misc/redboot_DBUG.ecm
$ ecosconfig resolve
$ ecosconfig tree
$ make

At the end of the build the install/bin subdirectory should contain the required file redboot_dbug.srec.

Rebuilding the RAM and ROM versions involves basically the same process. The RAM version uses the file redboot_RAM.ecm and generates a file redboot_ram.bin. The ROM version uses the file redboot_ROM.ecm and generates a file redboot_rom.bin.

BDM

An alternative to debugging an application on top of Redboot is to use a BDM hardware debug solution. On the eCos side this requires building the configuration for RAM startup and with CYGSEM_HAL_USE_ROM_MONITOR disabled. Note that a RAM build of RedBoot automatically has the latter configuration option disabled, so it is possible to run a RAM RedBoot via BDM and bypass the dBUG stages of the installation process.

On the host-side the details depend on exactly which BDM solution is in use. The recommended BDM debug solution is the Ronetix PEEDI. Other solutions such as the P&E USBMultilink device have proved unreliable, so if a PEEDI is not available then it is recommended that application developers should debug their applications on top of RedBoot's gdb stubs.

The PEEDI requires a configuration file peedi.cfg which can be found in the platform HAL's misc directory. The configuration file will initialize the hardware in the same way as standard eCos applications, so applications can be loaded into RAM and run as normal. The configuration file will need minor edits, for example to specify the correct license keys. For full details see the Ronetix documentation. Once the PEEDI is correctly set up m68k-elf-gdb can then connect to it in the usual way:

$ m68k-elf-gdb install/tests/kernel/current/tests/tm_basic
GNU gdb 6.4.50.20060226-cvs (eCosCentric)
Copyright (C) 2006 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=i686-pc-linux-gnu --target=m68k-elf"...
(gdb) target remote peedi:9000
0x400008f6 in ?? ()
(gdb) load
Loading section .m68k_start, size 0x98 lma 0x40010000
Loading section .text, size 0xa918 lma 0x40010098
Loading section .rodata, size 0x114a lma 0x4001a9b0
Loading section .data, size 0x18c lma 0x4001bafc
Start address 0x40010000, load size 48262
Transfer rate: 260172 bits/sec, 3217 bytes/write.
(gdb) break cyg_test_exit
Breakpoint 1 at 0x40016172: file /home/bartv/ecos/ecospro-common/infra/current/src/tcdiag.cxx, line 310.
void cyg_test_exit(void);
(gdb) continue
Continuing.

Breakpoint 1, cyg_test_exit () at /home/bartv/ecos/ecospro-common/infra/current/src/tcdiag.cxx:310
310         if (code_checksum != cyg_crc16(_stext, _etext - _stext)) {
(gdb) quit
The program is running.  Exit anyway? (y or n) y
$

Unlike the PEEDI, some BDM solutions will not automatically initialize the hardware. Instead this can be achieved using a set of example gdb macros which can be found in the bdm.gdb file in the platform HAL's misc subdirectory. The macros need to be called either through a configuration file or directly to initialize the hardware prior to downloading the eCos application.