Configuration

Configuration
	Chapter 324. Freescale M5272C3 Board Support

Overview

The M5272C3 platform HAL package is loaded automatically when eCos is configured for an M5272C3 target. It should never be necessary to load this package explicitly. Unloading the package should only happen as a side effect of switching target hardware.

Startup

The M5272C3 platform HAL package supports four separate startup types:

RAM: This is the startup type which is normally used during application development. The board has RedBoot programmed into flash at location 0xFFF00000 and boots from that location. m68k-elf-gdb is then used to load a RAM startup application into memory and debug it. It is assumed that the hardware has already been initialized by RedBoot. By default the application will use eCos' virtual vectors mechanism to obtain certain services from RedBoot, including diagnostic output.
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.
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.
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. It exists mainly to support the dBUG version of RedBoot which is needed during hardware setup. 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.

RedBoot and Virtual Vectors

If the application is intended to act as a ROM monitor, providing services for other applications, then the configuration option CYGSEM_HAL_ROM_MONITOR should be set. Typically this option is set only when building RedBoot.

If the application is supposed to make use of services provided by a ROM monitor, via the eCos virtual vector mechanism, then the configuration option CYGSEM_HAL_USE_ROM_MONITOR should be set. By default this option is enabled when building for a RAM startup, disabled otherwise. It can be manually disabled for a RAM startup, making the application self-contained, as a testing step before switching to ROM startup.

If the application does not rely on a ROM monitor for diagnostic services then one of the serial ports will be claimed for HAL diagnostics. By default eCos will use the terminal port, corresponding to uart0. The auxiliary port, uart1, can be selected instead via the configuration option CYGHWR_HAL_M68K_MCFxxxx_DIAGNOSTICS_PORT. The baud rate for the selected port is controlled by CYGNUM_HAL_M68K_MCFxxxx_DIAGNOSTICS_BAUD.

Flash Driver

The platform HAL package contains flash driver support. By default this is inactive, and it can be made active by loading the generic flash package CYGPKG_IO_FLASH.

Special Registers

The MCF5272 processor has a number of special registers controlling the cache, on-chip RAM and ROM, and so on. The platform HAL provides a number of configuration options for setting these, for example CYGNUM_HAL_M68K_M5272C3_RAMBAR controls the initial value of the RAMBAR register. These options are only used during a ROM or ROMFFE startup. For a RAM startup it will be RedBoot that initializes these registers, so if the default values are not appropriate for the target application then it will be necessary to rebuild RedBoot with new settings for these options. Alternatively it should be possible to reprogram some or all of the registers early on during startup, for example by using a high-priority static constructor.

One of the special registers, MBAR, cannot be controlled via a configuration option. Changing the value of this register could have drastic effects on the system, for example moving the on-chip peripherals to a different location in memory, and it would be very easy to end up with inconsistencies between RedBoot and the eCos application. Instead the on-chip peripherals are always mapped to location 0x10000000.

System Clock

By default the system clock interrupts once every 10ms, corresponding to a 100Hz clock. This can be changed by the configuration option CYGNUM_HAL_RTC_PERIOD, the number of microseconds between clock ticks. Other clock-related settings are recalculated automatically if the period is changed.

Compiler Flags

The platform HAL defines the default compiler and linker flags for all packages, although it is possible to override these on a per-package basis. Most of the flags used are the same as for other architectures supported by eCos. There are three flags specific to this port:

-mcpu=5272: The m68k-elf-gcc compiler supports many variants of the M68K architecture, from the original 68000 onwards. For an MCF5272 processor -mcpu=5272 should be used.
-malign-int: This option forces m68k-elf-gcc to align integer and floating point data to a 32-bit boundary rather than a 16-bit boundary. It should improve performance. However the resulting code is incompatible with most published application binary interface specifications for M68K processors, so it is possible that this option causes problems with existing third-party object code.
-fomit-frame-pointer: Traditionally the %A6 register was used as a dedicated frame pointer, and the compiler was expected to generate link and unlink instructions on procedure entry and exit. These days the compiler is perfectly capable of generating working code without a frame pointer, so omitting the frame pointer often saves some work during procedure entry and exit and makes another register available for optimization. However without a frame pointer register the m68k-elf-gdb debugger is not always able to interpret a thread stack, so it cannot reliably give a backtrace. Removing -fomit-frame-pointer from the default flags will make debugging easier, but the generated code may be worse.


Setup		The HAL Port

Name