Name
eCos Support for the Freescale M5208EVBe and M5208EVB (Intec Automation) Boards — Overview
Description
This package CYGPKG_HAL_M68K_M5208EVBE
provides a
port to the Freescale M5208EVBe board. The older M5208EVB is also
supported via CDL configuration. The port supports RedBoot programmed
into the external flash. This can be used for application
bootstrap. It also provides gdb stub functionality, allowing
developers to download and debug eCos applications via the gdb
debugger. This can happen over either a serial line or over
ethernet. Alternatively
a BDM hardware debug
module can be used.
The eCos port can be configured for one of three 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. The RAM startup type can also be used for finished applications: RedBoot can be made to load and run such applications automatically following bootstrap.
- RAMBDM
- This is a variant of RAM startup which can be used for debugging using a BDM hardware debug module, if for some reason an application cannot be run on top of RedBoot. The main difference between RAMBDM and RAM startup is that the former does not assume the presence of RedBoot and hence will not make any virtual vector calls to obtain RedBoot services.
- ROM
- This startup type can be used for finished applications which will be programmed into external flash at location 0x00000000, and which will execute as soon as the processor starts running. The application will be self-contained with no dependencies on services provided by other software. This startup type is used for building the flash-resident version of RedBoot but can also be used for application code.
Hardware
The memory map used by both eCos and RedBoot for the M5208EVBe is as follows:
Memory | Base | Length | Write-protected |
---|---|---|---|
External Flash | 0x00000000 | 0x00800000 | Yes |
External SDRAM | 0x40000000 | 0x02000000 | No |
Internal RAM | 0x80000000 | 0x00004000 | No |
On-chip Peripherals | 0xF0000000 | 0x10000000 | No |
For the older M5208EVB platform the eCos and RedBoot memory map is:
Memory | Base | Length | Write-protected |
---|---|---|---|
External Flash | 0x00000000 | 0x00200000 | Yes |
External SDRAM | 0x40000000 | 0x02000000 | No |
Internal RAM | 0x80000000 | 0x00004000 | No |
On-chip Peripherals | 0xF0000000 | 0x10000000 | No |
By default caching is enabled for the external flash and SDRAM. There is no need to cache the internal RAM, and caching the peripherals would break all device drivers. As a debugging aid the flash is set to write-protected, which should catch some null pointer indirections. The flash driver will temporarily set this part of the address space to read-write when modifying the flash.
For all startup types the M68K exception vectors, the eCos virtual vector table, and a small amount of additional data is placed at the base of SDRAM. For ROM startup the application's data starts immediately afterwards. For RAM and RAMBDM startup application code starts at 0x40010000, with just under 64K reserved for use by RedBoot, and data follows after the code.
Typically the first 128K of flash is used for RedBoot, and the last
64K of flash is used for RedBoot's FIS and fconfig data. The
remainder of the flash is available for use by the application, and is
supported via the V2 AMD flash driver
CYGPKG_DEVS_FLASH_AMD_AM29XXXXX_V2
. That driver is
inactive unless the generic flash support
CYGPKG_IO_FLASH
has been included in the
configuration. The amount of flash available is the main difference
between the newer M5208EVBe board and the older M5208EVB. The default
M5208EVBe platform HAL uses CFI to determine the actual flash chips
present, with the M5208EVB being restricted to the known/fixed 2MB
flash due to hardware mapping of the flash chip. The generic flash
support provides an API that ensures an application need not worry
about the details of which flash chips are present.
Code and data can be placed in the internal RAM using the linker
script section “.iram_text” for code, and
“.iram_data” and “.iram_bss” for initialized
and unitialized data respectively. The M68K architectural HAL contains
a testcase iram1.c
which demonstrates how to use
these linker sections.
Of the three on-chip UARTs, UART0 and UART1 have on-board RS232 transceivers and UART2 is available via GPIO configuration on the CN1 I/O header. Normally UART0 will be used as the default diagnostics channel for RedBoot and for stand-alone applications, and may also be inherited as the diagnostics/debug channel when debugging a RAM startup application over serial.
The on-chip ethernet device is supported via the device driver
CYGPKG_DEVS_ETH_MCFxxxx
. This driver will be
inactive unless the generic ethernet support
CYGPKG_IO_ETH_DRIVERS
is included in the
configuration. Typically that will happen automatically when the
configuration is created using the net
template.
For RedBoot or applications run on top of RedBoot the ethernet MAC
address will typically be supplied by an fconfig
setting. Otherwise the address will be set by a configuration option
in the ethernet driver. Care should be taken that no two boards on the
same network segment accidentally use the same MAC address.
The I²C bus is supported by the generic package
CYGPKG_IO_I2C
and the device driver
CYGPKG_DEVS_I2C_MCFxxxx
. Both of these will be
included automatically in any configuration for the M5208EVBe, but
will be eliminated at link-time if the application does not use any
I²C functionality. The I²C bus instance is called
hal_mcfxxxx_i2c_bus
.
The QSPI bus is supported by the generic package
CYGPKG_IO_SPI
and the device driver
CYGPKG_DEVS_SPI_MCFxxxx_QSPI
. Both of these will be
included automatically in any configuration for the M5208EVBe, but
will be eliminated at link-time if the application does not use any
SPI functionality. The SPI bus instance is called
hal_mcfxxxx_qspi_bus
, and the platform HAL also
instantiates an SPI device object hal_m5208evbe_m13192
.
All eCos configurations for the M5208EVBe also include a watchdog
device driver CYGPKG_DEVS_WATCHDOG_MCFxxxx_SCM
. That
driver is inactive unless the generic watchdog support
CYGPKG_IO_WATCHDOG
has been added to the
configuration, and should be accessed via the API provided by that
package.
eCos also manages the interrupt controllers, the FlexBus settings, and
the SDRAM controller. The Crossbar switch is set to favour I/O rather
than the cpu, avoiding problems with DMA underruns. Timer PIT0 is
normally used for the eCos system clock, and when using the profiling
package CYGPKG_PROFILE_GPROF
PIT1 will be used for
the profiling timer. The remaining hardware is available for use by
the application.
Tools
The M5208EVBe port is intended to work with GNU tools configured for an m68k-elf target. The original port was done using m68k-elf-gcc version 4.4.5c m68k-elf-gdb version 7.2, and binutils version 2.20.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.
2024-03-18 | eCosPro Non-Commercial Public License |