Loading and Unloading the Package
The TILE-Gx architectural HAL
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
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
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.
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
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.
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.
The configuration options CYGNUM_HAL_RTC_NUMERATOR
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
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.
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
The package has two sets of configuration options related to compiler
and linker flags. The first set consists
CYGBLD_GLOBAL_LDFLAGS, plus supporting options
CYGHWR_MEMORY_LAYOUT needed by other parts of
the eCos source base.
CFLAGS defines the default
compiler flags that will be used for all
LDFLAGS the default linker flags. The
most important flag is -m32 to force a
The second consists of
CYGPKG_HAL_TILEGX_CFLAGS_REMOVE, plus supporting
is used to specify additional compiler flags that should be used when
compiling the TILE-Gx architectural HAL package,
CFLAGS_REMOVE can be used to remove some of the