— eCos Support for the Nios II Architecture
The Altera Nios II is a configurable processor. Using the Altera design suite a system designer can build a custom hardware design. This will involve a Nios II cpu, possibly fine-tuned as appropriate for the application with e.g. appropriate amounts of cache and custom instructions. Next those peripherals needed by the application are added. The resulting design is compiled and programmed into a suitably-sized FPGA. This FPGA will be the heart of a larger circuit containing other devices such as external flash and RAM memories and support chips such as RS232 transceivers. A number of reference hardware designs are included with the design suite. The eCos Nios II architectural HAL package together with supporting HAL packages and device drivers allow eCos to be configured and built for a hardware design. Complete applications can then be built with eCos.
The configurable nature of the Nios II architecture means that the eCos port is implemented somewhat differently from ports to other architectures, although the same basic functionality is available. A conventional eCos port involves an architectural HAL package, a variant HAL, possibly a processor HAL, and a platform HAL. Typically the architectural HAL provides a framework for the lower HALs, interrupt and exception processing, context switch support, and gdb stub debug support. The variant HAL deals with cpu issues which are not common to all members of the basic architecture, for example caches and optional FPU and MMU support. The processor HAL deals with the specific set of devices on one specific chip that implements the basic architecture, for example timers, a uart for diagnostics, and interrupt controllers. Base address for the various devices and their interrupt vectors are also defined here. The platform HAL deals with devices that are off-chip. This includes external flash and RAM, as well as specialized I/O chips on an I²C or SPI bus. Typically the external memory will determine how the system boots up so issues like different startup types are largely handled by the platform HAL.
Exactly what work is done where depends very much on the specific processor, for example an interrupt controller may be supported by the variant HAL instead of the processor HAL if it is expected that all processors implementing that variant will use the same interrupt controller. Typically lower HALs are able to extend or override the behaviour of higher ones as appropriate, for example a platform HAL could redefine the interrupt controller support if the platform includes an external interrupt controller as well as an on-chip one.
The Nios II port still involves an architectural HAL and a platform
HAL. The architectural HAL tends to do more of the work than other
architectural HALs. For example it provides default implementations of
system clock support using an Avalon timer and diagnostics using an
Avalon uart. The platform HAL still deals with the off-chip devices
such as external flash and RAM. For example the devkit platform HAL
CYGPKG_HAL_NIOS2_DEVKIT provides the appropriate
support for the Stratix II/2s60_RoHS and the Cyclone II/2c35
boards and compatibles.
There is also a new type of HAL, the hardware design HAL. Typically
this does not contain any code, only definitions and eCos
configuration support. It contains the information needed by the other
HALs and by device drivers to adapt themselves to a specific hardware
design, for example the presence of certain cpu instructions, the
existence and size of cache, and the base addresses and interrupt
vectors assigned to the various on-chip and off-chip devices.
Essentially this corresponds to the information manipulated within the
SOPC Builder component of the Altera Design Suite. An example of a
hardware design HAL is
corresponding to the eCosPro TSEplus hardware design for a
Cyclone II/2c35 board.
An eCos target, as defined by an entry in the toplevel ecos.db database, consists of the Nios II architectural HAL, a hardware design HAL, a platform HAL, and a set of device drivers. Typically each target will have its own hardware design HAL, although in some cases multiple targets may use the same hardware design HAL to allow for incompatible device drivers. If a platform HAL is fairly generic then it may be shared between several targets, otherwise a target will need its own platform HAL. Porting eCos to a new Nios II design will typically involve creating a new hardware design HAL, usually by cloning an existing one, and either reusing or cloning an existing platform HAL, followed by creating the appropriate entries in ecos.db.
At the time of writing hardware design HALs are manually written or cloned. It is expected that in a future release these HALs will be generated automatically from the output of SOPC Builder, with little or no need for manual intervention. For simple hardware the need for a separate platform HAL may also be eliminated at that time.
|2018-07-27||eCosPro Non-Commercial Public License|