The Cobra5329 platform HAL package is loaded automatically when eCos is
configured for a Cobra5329 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. The platform HAL is
complemented by the M68K architectural HAL
the MCFxxxx variant HAL
and the MCF532x processor HAL
The Cobra5329 platform HAL package supports three separate startup
types: RAM, RAMBDM, DBUG and ROM. The configuration option
CYG_HAL_STARTUP: controls which startup type is
being used. For typical application development RAM startup should be
used, and the application will be run via
m68k-elf-gdb interacting with RedBoot using
either serial or ethernet. It is assumed that the low-level hardware
initialization, including setting up the memory map, has already been
performed by RedBoot. By default the application will use certain
services provided by RedBoot via the virtual vector mechanism,
including diagnostic output, but that can be disabled via
CYGSEM_HAL_USE_ROM_MONITOR. RAMBDM startup is a
variant of RAM startup which has
CYGSEM_HAL_USE_ROM_MONITOR disabled by default, and
may be useful when debugging over BDM.
ROM startup can be used for applications which boot directly from flash. All the hardware will be initialized, and the application is self-contained. This startup type is used by the flash-resident version of RedBoot, and can also be used for finished applications.
DBUG startup can be used for applications which will be loaded via the dBUG ROM monitor rather than RedBoot. As with RAM startup it is assumed that the memory map has already been set up, but the application will not use any services provided by the ROM monitor. Typically this startup type is only used when setting up a board, as part of the process of replacing dBUG with RedBoot.
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
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. That is useful as a
testing step before switching to ROM startup. It also allows
applications to be run and debugged via BDM.
Diagnostics support is provided by the MCFxxxx variant HAL. For RAM startup the application will inherit its diagnostics channel from RedBoot: when debugging over ethernet diagnostics will travel over the TCP connection between m68k-elf-gdb and RedBoot; if RedBoot is set to discard its diagnostics then application diagnostics will be discarded as well; otherwise diagnostics will be sent over one of the uarts, typically uart0.
For other startup types the default diagnostics channel can be set to
either of the uarts, or eCos can be configured to discard all
diagnostics. The relevant configuration option is
The MCF532x processor HAL provides configuration options for the GPIO pin assignment registers, effectively controlling which of the on-chip peripherals are connected to the outside board. These settings are used in term to set the defaults for various devices, for example which uarts are available and whether or not the hardware handshake lines are connected. The platform HAL provides default setttings for all these registers appropriate for a Cobra5329 cpu module plugged into a standard carrier board, with no additional hardware. If the cpu module is plugged into a different carrier board or if extra hardware is hooked up to the various expansion sockets, the pin assignments can be changed as appropriate. Alternatively application can manipulate the processor's GPIO unit directly.
Cache and On-Chip RAM
The platform HAL contains configuration options for the values of the RAMBAR, CACR, ACR0 and ACR1 control registers. The first of these determines the location of on-chip RAM and does not usually need to be changed by application developers. The other three registers determine the caching behaviour. The default settings have the external flash cached in write-through mode, the external SDRAM cached in copyback mode, and everything else uncached. Normally it should be necessary to change these settings, and for a processor that can run at 240MHz it is important to make the best possible use of the cache. However, when debugging over BDM using hardware other than a Ronetix PEEDI it has been found that debug reliability could be improved somewhat when the cache was disabled, i.e. when the top bit of the CACR register was cleared. Obviously this is at the cost of greatly reduced performance.
By default the platform HAL assumes a system clock running at
240/80MHz, 240MHz for the CPU and 80MHz for the peripherals.
CYGHWR_HAL_SYSTEM_CLOCK_HZ corresponds to the
peripheral clock speed. It is possible to run the board at a slower
180/60MHz by changing one of the switches in the configuration dip
switch. If so then the configuration option must be changed for both
RedBoot and the application, since it affects various I/O settings
such as uart baud rates.
The port uses programmable interrupt timer PIT3 to implement the eCos
system clock. By default this is set to tick once every 10ms,
corresponding to a 100Hz clock. The frequency can be changed via the
is used to program the timer's PIT Modulus Register (PMR3). Other
clock-related settings are recalculated automatically if the period is
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:
The m68k-elf-gcc compiler supports many variants of the M68K architecture, from the original 68000 onwards. A
-moption should be used to select the specific variant in use, and with current tools
-m528xis the closest match for an MCF532x processor.
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.
%A6register 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-pointerfrom the default flags will make debugging easier, but the generated code may be worse.