Loading and Unloading the Package

The TILE-Gx architectural HAL package CYGPKG_HAL_TILEGX will be loaded automatically when eCos is configured for a tilegx target, as will other hardware-specific packages such as the TMC support library. 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 configuration option CYG_HAL_STARTUP can take one of two values: RAM and ROM. RAM startup is the default except when rebuilding a gdbstubs image. RAM startup should be used in a debug system when the application runs on top of gdbstubs, allowing the use of tile-gdb. Applications linked against a RAM-startup build of eCos cannot be incorporated into a hypervisor boot image. ROM startup should be used in a production system, and when rebuilding a gdbstubs image. Applications linked against a ROM-startup build of eCos should be incorporated into a hypervisor boot image and run on the target, not on top of gdbstubs.

There are two related options: CYGSEM_HAL_ROM_MONITOR and CYGSEM_HAL_USE_ROM_MONITOR. These options need to exist only to satisfy expectations elsewhere in the eCos source base. There should be no need to change the default values.

RAM Sizing

On a typical eCos target all available memory will be used by eCos. Often the amount of memory will be fixed at compile-time, but some targets support run-time memory sizing. This approach will not work on a TILE-Gx system: typically most of the memory will be needed by the Linux partition, and each BME tile running eCos will need its own allocation.

Instead the memory size of each BME tile is determined at the point that the hypervisor loads the ROM-startup executable held in the boot image. That executable will be gdbstubs in a debug system, or the eCos application in a production system. The memory consists of a ROM region holding the code and a RAM region for data. In a debug system gdbstubs will use only a small amount of the RAM region and the rest will be used for the code and data of the RAM-startup application that will be loaded and run via tile-gdb. The hypervisor will also allocate a small amount of additional memory at location 0x6c000000 for the startup stack and some data structures, and some memory at the top of the address space for interrupt vectors.

It is possible but non-trivial to increase the amount of memory available at run-time, using the shared memory techniques described in the TMC support package. Essentially a process running in the Linux partition would allocate a large block of memory and pass the details on to the eCos application, which can then map the block into its own address space. However this additional memory has to be managed entirely by the application. There is no easy way to add it to the eCos system heap.

For a ROM startup application or for gdbstubs the RAM size is controlled by the configuration option CYGNUM_HAL_TILEGX_RAM_SIZE, and has a default value of 4096K or 4 megabytes. The size can be increased or decreased to match the application's actual needs. However the hypervisor will perform rounding of the requested size. For RAM sizes up to 16MB the hypervisor will round the requested size up to 64K, 256K, 1MB, 4MB or 16MB. For RAM sizes larger than 16MB the hypervisor will allocate multiple blocks of 16MB each. eCos will use the amount of memory actually allocated by the hypervisor so there is no point in specifying an intermediate value size of say 8MB: the hypervisor will round this up to 16MB and eCos will use all 16MB.

For a RAM startup application changing CYGNUM_HAL_TILEGX_RAM_SIZE usually has little or no effect. eCos will use the actual amount of memory allocated by the hypervisor to gdbstubs, irrespective of the value of this option. However the option is used in the linker script to specify the size of the RAM region. If the total application code and static data requirements exceed the option's 4MB default value then the application will fail to link because the linker believes that only 4MB are available. In these circumstances it is possible to increase the option's value and thus allow the link to succeed. Obviously it will still be necessary to run a suitably-sized gdbstubs executable so that the hypervisor really will allocate the desired amount of memory.

For a production system, changing this configuration option in the ROM startup eCos application is straightforward. For a debug system things are a little more complicated: the option would have to affect the gdbstubs executable, not the application being debugged, since it is the former that is loaded by the hypervisor. Rebuilding a custom gdbstubs executable with a different RAM size is not hard, but it is annoying. As an alternative the RAM size can also be set when using tile-ecos-32to64 to convert a 32-bit executable to a 64-bit pseudo-executable:

$ tile-ecos-32to64 -m 16384 gdb_module.img gdb_module_16MB.64

This creates a variant of the usual gdb_module.64 with an 16384K or 16MB RAM size instead of the default 4MB, using the prebuilt gdb_module.img file shipped with the release.

Diagnostics

The option CYGHWR_HAL_TILEGX_DIAGNOSTICS_DESTINATION controls what happens to eCos console output. For a ROM startup application eCos output will be sent to the hypervisor over the IDN bus and will be displayed on the system console. For a RAM startup application eCos output will by default be sent to LittleBoPeep and then on to tile-gdb. However it is possible to redirect the console output to the hypervisor and hence the system console if desired.

System Clock

The configuration options CYGNUM_HAL_RTC_NUMERATOR and CYGNUM_HAL_RTC_DENOMINATOR control the frequency of the eCos system clock, or more precisely they are used to calculate the value programmed into the TILE_TIMER_CONTROL special purpose register. The number of nanoseconds between clock ticks is given by NUMERATOR/DENOMINATOR. The default value of the NUMERATOR is 1000000000, the number of nanoseconds in a second. Therefore simple clock frequencies can be achieved simply setting the DENOMINATOR to that frequency. For example the default 100Hz system clock is achieved by a DENOMINATOR value of 100. For more complicated clock frequencies the calculation could involve unacceptable rounding errors, and it may be necessary to change both the NUMERATOR and DENOMINATOR to avoid these.

When running on the simulator the default 100Hz clock requires a simulation of 10 milliseconds between clock ticks, and that may take a few tens of second of real time. If the application spends much of its time waiting for the next clock tick then performance may be greatly improved by running with a faster clock.

Simulator Support

Any ROM startup application including gdbstubs can be run on the Tilera simulator if desired, without changing any configuration options. However it is possible to build the system specifically for running on the simulator by enabling the configuration option CYGHWR_HAL_TILEGX_SIMULATOR. This enables some extra code in the eCos startup code which causes the system to pause until tile-gdb is connected and resumes execution. The simulator will output details of exactly how tile-gdb should connect, but note that the file being debugged should be the original 32-bit executable and not the 64-bit pseudo-executable generated by tile-ecos-32to64. Enabling the option also causes the system to halt if and when a non-recoverable double fault exception occurs, which may make debugging such faults slightly less difficult. Finally it changes the behaviour of some eCos testcases, causing them to run far fewer iterations than a testcase running on real hardware.

Compiler Flags

The package has two sets of configuration options related to compiler and linker flags. The first set consists of CYGBLD_GLOBAL_CFLAGS and CYGBLD_GLOBAL_LDFLAGS, plus supporting options CYGBLD_GLOBAL_COMMAND_PREFIX, CYGBLD_LINKER_SCRIPT, and CYGHWR_MEMORY_LAYOUT needed by other parts of the eCos source base. CFLAGS defines the default compiler flags that will be used for all packages, LDFLAGS the default linker flags. The most important flag is -m32 to force a 32-bit build.

The second consists of CYGPKG_HAL_TILEGX_CFLAGS_ADD and CYGPKG_HAL_TILEGX_CFLAGS_REMOVE, plus supporting options CYGPKG_HAL_TILEGX_TESTS and CYGBLD_HAL_TILEGX_BUILD_STUBS64. CFLAGS_ADD is used to specify additional compiler flags that should be used when compiling the TILE-Gx architectural HAL package, and CFLAGS_REMOVE can be used to remove some of the global flags.