Description

The Nios II architectural HAL is included in all ecos.db entries for Nios II targets, so the package will be loaded automatically when creating a configuration. It should never be necessary to load the package explicitly or to unload it.

The architectural HAL contains a number of configuration options, although relatively few compared with many other architectures. This is because many aspects of the system that would normally be handled at compile-time by eCos configuration options can instead be controlled during the hardware design process. For example, the uart used for the diagnostics and debug channel can be hardwired to a particular baud rate, eliminating the need to control this via an eCos configuration option.

The most important configuration options in the architectural HAL are CYGBLD_GLOBAL_CFLAGS and CYGBLD_GLOBAL_LDFLAGS, the default compiler flags for building eCos and for linking testcases. The flags are exported in the file install/include/pkgconf/ecos.mak in the eCos build tree and are usually used for building application code as well, either as is or after any appropriate changes. Users may wish to change these flags, for example to build eCos with different compiler optimization settings. The default values of these options adapt to information provided by the hardware design HAL about the cpu's capabilities, for example the availability of the various multiply and divide instructions.

CYGSEM_HAL_COMMON_INTERRUPTS_FIXED_GP affects the way eCos interacts with the global pointer register or gp. The Nios II ABI uses gp to access certain variables, allowing up to 64K worth of data to be accessed via a single instruction rather than two separate instructions. The gp register is initialized during application startup. The use of a global pointer can cause problems. For example when the system involves a ROM RedBoot and a RAM application, both are built independently and have their own area for small variables and hence their own gp values. Whenever the system switches between code running in the application and code running in RedBoot the gp register must be switched as well. That means when an interrupt or exception occurs the gp register may have the wrong value for the interrupt or exception handler, and hence the gp register must be saved, updated, and restored alongside other parts of the cpu state. This adds to the interrupt latency. If it is known that there will only be one application running in the system, e.g. when using ROM or RAMJTAG startup, then the system can assume a fixed global pointer register and there is no need for the interrupt and exception handlers to do anything with it. This configuration option controls the gp behaviour, and usually its default value determined from other configuration options will be appropriate.

A build of ROM RedBoot normally includes gdb stubs support, including breakpoints. Usually ordinary breakpoints involve inserting a special breakpoint into the image in memory, and hence debugging is generally limited to applications executing from RAM. On most architectures the host-side gdb will implement this via a memory write using the gdb remote protocol and no special stub support is needed for that. The Nios II architecture has two breakpoint instructions, one for use when debugging over jtag and one for use when debugging via a target-side gdb stub like the one in RedBoot. nios2-elf-gdb defaults to using the jtag version of the breakpoint instruction, which would break debugging via RedBoot. Hence the Nios II implementation of the gdb stubs code uses a different mechanism, involving a target-side list of the breakpoints that have been set and inserting the appropriate breakpoint instruction on the target-side rather than via memory writes initiated from the host. The gdb stubs code works without dynamic memory allocation so this list is a fixed size, and hence only a fixed number of breakpoints are supported. By default this limit is set to 25 breakpoints, which should suffice for all but the most complicated debug scenarios. If it should ever be necessary to have more breakpoints then the limit can be increased by changing the configuration option CYGNUM_HAL_BREAKPOINT_LIST_SIZE in a ROM Redboot configuration and rebuilding and installing the updated RedBoot.