Overview

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:

MemoryBaseLengthWrite-protected
External Flash0x000000000x00800000Yes
External SDRAM0x400000000x02000000No
Internal RAM0x800000000x00004000No
On-chip Peripherals0xF00000000x10000000No

For the older M5208EVB platform the eCos and RedBoot memory map is:

MemoryBaseLengthWrite-protected
External Flash0x000000000x00200000Yes
External SDRAM0x400000000x02000000No
Internal RAM0x800000000x00004000No
On-chip Peripherals0xF00000000x10000000No

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 I2C 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 I2C functionality. The I2C 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.

2017-02-09
Documentation license for this page: eCosPro License