The DNP/5280 platform HAL package is loaded automatically when eCos is
configured for a dnp5280, dnp5280_v12 or dnp5282 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 DNP/5280 platform HAL package supports three separate startup
types: RAM, 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.
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.
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. That is useful as a
testing step before switching to ROM startup. It also allows
applications to be run and debugged via BDM.
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 uart0. If the actual hardware
has connectors for uart1 or uart2, one of these 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.
Optional Hardware
The platform HAL assumes that a DNP/5280 module is plugged into a
standard DNP/EVA2_SV6 carrier board, and that a DNP/5282 module is
plugged into a DNP/EVA6. This can be changed via the configuration
option
CYGHWR_HAL_M68K_MCF528x_HARDWARE_DNP528x_BOARD. The
choice of carrier board determines the default settings of the various
GPIO pins, in other words which pins are connected to on-chip
peripherals. For example an EVA2_SV6 board only has a single uart
transceiver and connector so only uart0's signals are connected to the
appropriate pins. An EVA6 has two transceivers and connectors so both
uart0 and uart1 are connected. When using a non-standard carrier board
it is possible to define the pin connectivity via configuration
options in the CDL component
CYGHWR_HAL_M68K_MCF528x_GPIO. The configuration
should adjust accordingly, enabling or disabling devices as
appropriate. Mostly this happens in the MCF5282 processor HAL and the
MCFxxxx variant HAL.
Special Registers
The MCF5282 processor has a number of special registers controlling
the cache, on-chip RAM, and so on. The platform HAL provides a
number of configuration options for setting these, for example
CYGNUM_HAL_M68K_DNP5280_RAMBAR controls the initial
value of the RAMBAR register.
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:
-m5200
The m68k-elf-gcc compiler supports many
variants of the M68K architecture, from the original 68000 onwards.
A -m option should be used to select the specific
variant in use, and with current tools -m5200 is the
closest match for an MCF5282 processor.
-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.