OverviewNameeCos Support for the Freescale M5282EVB Board -- Overview DescriptionThe Freescale M5282EVB board has an MCF5282 ColdFire processor, 16MB of
external SDRAM, 2MB of external flash memory, plus
required support chips for the on-chip peripherals. By default the
board comes with its own dBUG ROM monitor, located in the bottom half
of the flash.
For typical eCos development a RedBoot image is programmed into the
top half of the flash memory, and the board is made to boot this image
rather than the existing dBUG monitor. RedBoot provides gdb stub
functionality so it is then possible to download and debug eCos
applications via the gdb debugger. This can happen over either a
serial line or over ethernet.
Supported HardwareThe memory map used by both eCos and RedBoot is as follows:
eCos can be configured for one of four startup types:
- RAM
This is the startup type normally used during application
development. RedBoot is programmed into flash and performs the initial
bootstrap. m68k-elf-gdb is then used to
load a RAM startup application into memory and debug it. By default
the application will use eCos' virtual vectors mechanism to obtain
certain services from RedBoot, including diagnostic output.
With a minor change to the eCos configuration this startup type can
also be used to debug applications via BDM.
- DBUG
This is a variant of the RAM startup which allows applications to be
loaded via the board's dBUG ROM monitor rather than via RedBoot. Once
the application has started it will take over all the hardware, and it
will not depend on any services provided by dBUG. This startup type
does not provide gdb debug facilities. It is used primarily for
building a special version of RedBoot, used during hardware setup.
- ROM
This startup type can be used for finished applications which will be
programmed into flash at location 0xFFF00000. The application will be
self-contained with no dependencies on services provided by other
software. eCos startup code will perform all necessary hardware
initialization. This startup type is used for building the
flash-resident version of RedBoot but can also be used for application
code.
- ROMFFE
This is a variant of the ROM startup type which can be used if the
application will be programmed into flash at location 0xFFE00000,
overwriting the board's dBUG ROM monitor.
For all startup types the external SDRAM is used to hold all data. For
RAM and dBUG startup the code also resides in external SDRAM, with the
first 64K reserved for use by the ROM monitor. The 64K of internal RAM
is not used, either by RedBoot or by eCos, so all of it is available
to the application. The 512K of internal flash is not currently used.
In a typical setup the bottom half of the external flash is reserved
for the dBUG ROM monitor and is not accessible to eCos. That leaves 16
flash blocks of 64K each. Of these the first two are used for the
RedBoot image and another is used for managing the flash and holding
RedBoot fconfig values. The remaining 13 blocks from 0xFFF20000 to
0xFFFF0000 can be used by application code.
Alternatively it is possible to build an application for ROM startup
and program it into flash at 0xFFF00000, replacing RedBoot. For a
larger application ROMFFE startup can be used instead, making all of
external flash available to application code.
RedBoot can communicate with the host using either ethernet or one of
the UARTs - usually uart0 corresponding to the terminal port on the
m5282evb board.
All configurations for the M5282EVB target include an ethernet driver
package CYGPKG_DEVS_ETH_MCFxxxx. If the application
does not actually require ethernet functionality then the package is
inactive and the final executable will not suffer any overheads from
unused functionality. This is determined by the presence of the
generic ethernet I/O package CYGPKG_IO_ETH_DRIVERS.
Typically the choice of eCos template causes the right thing to
happen. For example the default template does not include any TCP/IP
stack so CYGPKG_IO_ETH_DRIVERS is not included, but
both the net and redboot templates do include a TCP/IP stack so will
specify that package and hence enable the ethernet driver. The
ethernet device can be shared by RedBoot and the application, so it is
possible to debug a networked application over ethernet.
The M5282EVB board does not have a serial EPROM or similar hardware
providing a unique network MAC address. Instead a suitable address has
to be programmed into flash via RedBoot's fconfig
command.
All configurations for the M5282EVB target include a serial device
driver package CYGPKG_DEVS_SERIAL_MCFxxxx. The
driver as a whole is inactive unless the generic serial support,
CYGPKG_IO_SERIAL_DEVICES is enabled. Exactly which
of the on-chip UARTs are supported is controlled by configuration
options within the platform HAL. By default both uart0 and uart1 are
supported, corresponding to the terminal and auxiliary ports. If the
UART is needed by the application then it cannot also be used by
RedBoot for gdb traffic, so another communication channel such as
ethernet should be used instead.
All configurations for the M5282EVB target also include a watchdog
device driver CYGPKG_DEVS_WATCHDOG_MCF5282. This
driver is inactive unless the generic watchdog support
CYGPKG_IO_WATCHDOG is loaded.
The on-chip interrupt controllers and the edge port module are managed
by eCos using macros provided by the MCF5282 processor HAL. PIT timer
3 is normally used to implement the eCos system clock. If gprof-based
profiling is enabled then that will use PIT timer 2. PIT timers 0 and
1 are unused and can be manipulated by the application. The GPIO pins
are manipulated only as needed to get the UART(s) and ethernet
working. eCos will reset the remaining on-chip peripherals (DMA,
GPT, DMA timers, QSPI, I2C, FlexCAN, and QADC) during system
startup or soft reset, but will not otherwise manipulate them.
ToolsThe M5282EVB port is intended to work with GNU tools configured for an
m68k-elf target. The original port was done using
m68k-elf-gcc version 3.2.1,
m68k-elf-gdb version 5.3, and binutils
version 2.13.1.
By default eCos is built using the compiler flag
-fomit-frame-pointer. Omitting the frame pointer
eliminates some work on every function call and makes another register
available, so the code should be smaller and faster. However without a
frame pointer m68k-elf-gdb is not always able to identify stack
frames, so it may be unable to provide accurate backtrace information.
Removing this compiler flag from the configuration option
CYGBLD_GLOBAL_CFLAGS avoids such debug problems.
A typical setup involves m68k-elf-gdb
interacting with RedBoot using either serial or ethernet.
Alternatively it is possible to debug via the BDM port. The package's
misc subdirectory contains a
script bdm.gdb that contains macros for the
low-level hardware initialization normally performed by the ROM
startup code. The application should be linked with an eCos
configuration using RAM startup, and with the options
CYGSEM_HAL_ROM_MONITOR and
CYGSEM_HAL_USE_ROM_MONITOR disabled to stop eCos
accessing any services provided by RedBoot. Diagnostic output will be
sent out of uart0.
|