ALOE Linux User Guide

This section describes first steps on launching and running a waveform in ALOE for Linux. If you plan to develop applications or you just want to learn more about ALOE, you should read the Waveform Developer Guide.

At this point we assume that you have downloaded and installed ALOE on your computer (see Start Guide) and that your are familiar with Linux commands at user level.

Launching ALOE

If you downloaded ALOE from source, take a look at the 'example-repository' directory. This directory is where Manager Daemons will search for configuration files, waveform definitions files and executables (and so on).

You will see that this directory has, among others, the following mandatory subdirectories:

  • logs: Module logs in a directory for each waveform.
  • reports: Module statistic reports in a directory for each waveform.
  • statsman: Module initialization parameters in a directory for each waveform.
  • swman_execs: Module binaries in a directory for each platform.
  • swman_apps: Application descriptions.

NOTE: Make sure that platform directories under swman_execs contains (or links to) your waveform binaries compiled for linux. If compile from the host machine, objects are installed in /usr/local/bin, therefore, platform's executables directories should point there, i.e.:

  • swman_execs/linux --> /usr/local/bin
  • swman_execs/linux_64 --> /usr/local/bin
  • swman_execs/linux_arm --> /usr/local/bin

Otherwise, if you do cross-compiling, each directory should link to the binaries for the target architecture, see ALOELinuxGuide#CrossCompilation?

ALOE Linux needs to access this repository. Path can be selected permanently in a configuration file or as an argument in the launcher. By default, it is defined in a configuration file and points to 'example-repository/', relative to the current directory. Therefore, ALOE can be launched from the downloaded source directory by simply typing:


NOTE: To run ALOE with real-time priorities, run it with root permissions.:

sudo runph

This will launch a default single-processor configuration.

runph is configured with a platform configuration file. However, shell arguments can be used to override some options. The command accepts the following arguments:

runph -r [repository_path] -c [platform_cfg_file] -i [xitf_cfg_file] [--daemon]|[--no-daemon] [--debug] [-o output_file]


  • -r [repository_path]: Path to the repository directory.
  • -c [platform_cfg_file]: Platform parameters configuration file. See #CustomizingyourPlatform. Default: /usr/local/etc/daemons.conf
  • -i [xitf_cfg_file]: External interfaces configuration file. See #CustomizingyourPlatform. Default: /usr/local/etc/xitf.conf
  • --daemon: Run PHAL in background. Default: Foreground.
  • --no-daemon: Run PHAL in foreground.
  • --debug: Run in debug mode. Do not kill objects at real time failures.
  • -o [output_file]: File to redirect standard output when running as background. Default: output.log

Customizing your Platform

ALOE Linux launcher admits two configuration files as arguments which modify certain Platform parameters. In this section we describe how to configure such parameters and what implications do they have:

Platform Configuration File: This file configures processor options and selects which daemons will be launched by runph. You can add or remove them according to which daemons you need in your platform. By default, any platform should run the following daemons:

  • frontend
  • swload
  • exec
  • bridge
  • sync
  • stats

Optionally, the following daemons can be set:

  • swman
  • hwman
  • statsman
  • sync_master

A single-processor configuration should launch all the daemons except sync and sync_master (synchronization is not needed). See MultiProcessorGuide to learn how to work with multi-processors. In the Platform Configuration File, you will find typical configuration sets.

Some of the parameters can be overriden by arguments in the runph command. The following parameters are available in the Platform Configuration File, also documented in the file:

  • name: The name of the processor.
  • mips: Capacity in MIPS of your computer.
  • nof_cores: Number of SMP cores.
  • tslot: Duration of the time slot, in microseconds.
  • run_as_daemon: Run in background.
  • output_file: File to redirect standard output.
  • work_path: Path to the repository directory
  • printbt_atexit: Print backtrace at object's real time fault
  • printbt_atexit: Print backtrace at object's exit (overrides atrtfault)
  • itfs_delay: Object Interfaces default delay. Typical values are: [0,1,2]
  • debug_mode: Disable real time monitoring (Debug mode)

External Interfaces Configuration File: This files has one section for each external TCP interface of your platform. Before creating a network of ALOE platforms, you should be very familiar with the ALOE Environment concepts as it compromises selecting which daemons will run every platform, which depends on your network architecture. The format of the file is a set of sections ([xitf]) with the following mandatory fields:

  • id: Identification of the interface (hexadecimal 16-bit integer). Not any value is accepted as it is used by daemons to discover the purpose of the interface. It must be one of the following:
    • 0x1: Master Control Interface.
    • 0x1n: n=[0..F], Slave Control Interface.
    • 0xpq: p=[2..F],q=[0..F], Data Interfaces
  • address: IP address of the interface. For input interfaces it will be the one to bind to, for output ones, it will be the remote one.
  • bw: Bandwidth (in bps) of the interface. Only for output interfaces.
  • port: IP port for the connection.
  • mode: Direction of the interface, can be one of the following:
    • in: Input interface (data only)
    • out: Output interface (data only)
    • inout: Input/Output interface, listening socket, typically for slave control interfaces
    • outin: Input/Output interface, output socket, typically for master control interface.

Launching ALOE as a Daemon

Running ALOE in background is often interesting when long time executions are going to be performed. In foreground executions, disconnecting user terminal (or ssh session) will kill ALOE processes. This can be avoided if the user launches ALOE with the daemon option (as an argument or in the platform configuration file, see above).

Running ALOE in background:

  1. Modify Platform configuration file, adding the field run_as_daemon=yes to the CPU section or launch ALOE with the --daemon argument.
  2. Modify Platform configuration file, adding the field output_file=hwapi_log_file to the CPU section or launch ALOE with the -o hwapi_log_file argument.
  3. Launch ALOE:
      sudo runph
    from any directory and ALOE will be started at background.
  4. Now to issue commands you must connect to cmdman daemon (from a local or remote machine) launch cmdman in remote mode specifying the IP address where ALOE is running:
      cmdman -c
    where should obviously be replaced by the IP address of the host where you launched the daemon. In this screen, you can type commands as usual and exit typing Ctrl+C. You will notice as you can re-connect with the same command and perform more commands. At this point, you can exit your ssh session normally. ALOE will keep running at background. When you login again, connect again with the previous cmdman command. Also, keep track of the output files (specified in the configuration file) for errors or unusual behaviour.
  5. Finally, you can kill ALOE by sending a INT signal. ALOE installs a simple shell command to do such:

Running a waveform: Basic ALOE commands

ALOE can be controlled from a text console by typing commands. Basically, running a waveform compromises 3 steps: loading, initializing and running. You will do such by typing the appropriate commands in the input console. In the next example, we will load, initialise and run the example waveform.

Once ALOE has been started we load the waveform typing in the prompt:

runph$: phload example

then initialize:

runph$: phinit example

and finally run:

runph$: phrun example

Now the waveform is running. We can see current processes information typing:

runph$: execinfo example

Or the available statistics

runph$: statls example

You also can pause the execution or run a finite number of steps, type:

runph$: phpause example
runph$: phrun example 1000

List of ALOE commands

This is the list of all ALOE commands:

  • help: Display list of commands.
  • phload: Load application. Args: phload app_name.
  • phrun: Run application. Args: phrun app_name.
  • phinit: Init application. Args: phinit app_name.
  • phpause: Pause application. Args: phpause app_name.
  • phstep: Step application. Args: phstep app_name.
  • phstop: Stop application. Args: phstop app_name.
  • statlist: List statistics. Args: statlist app_name [obj_name].
  • statset: Modify statistic. Args: statset app_name obj_name stat_name new_value.
  • statget: Get a statistic value. Args: statget app_name obj_name stat_name.
  • statreport: Start/stop report. Args: statreport start/stop app_name obj_name stat_name window_len period.
  • applist: List applications.
  • pelist: List PE in platform.
  • execinfo: Exec information. Args: execinfo app_name [obj_name].
  • exit: Exit this program.

Performance Notes

To get the best performance of your waveform, the following hints may be useful:

  • Compile your modules with highest optimization and specify your processor architecture. You can pass CFLAGS to the default configure script. At source type:
     ./configure CFLAGS='-O3 -march=native -mfpmath=sse'
     make clean && make && sudo make install
    if you have a pentium/athlon processor with sse extensions. Or:
     ./configure CFLAGS='-O3 -march=armv5te'
     make clean && make && sudo make install
    to optimize for the SheevaPlug?.
  • Increase Kernel time resolution. Another measure you can adopt to achieve a higher performance is increasing the kernel timer frequency. To do so, you must recompile your kernel. How to do that is out of the scope of this document, however, if you use menuconfig, the option you have to change is at Processor type and features->Timer frecuency (CONFIG_HZ). Setting that to 1000 Hz implies a resolution of 1ms which, with at 10ms slot duration should be enough.

Cross Compilation

In a multi-processor environment where node processors have different architecture than manager, you should either perform cross-compilation from the manager host or copy the binaries from the target machine. To perform cross-compilation you should first obtain a tool-chain for the desired target. For example, to compile for the Marvell's ARM processor with the gnueabi tool-chain, run ./configure with the following arguments:

ac_cv_func_malloc_0_nonnull=yes ./configure --host=arm-none-linux-gnueabi CFLAGS='-march=armv5te' --prefix=/usr/local/arm/

NOTE: Pay attention to the prefix argument. Here you should specify a different directory for every target architecture. Object binaries will be installed there, and that should be the directory where the swman_execs/linux_arm links to, in this case, make sure:

  • swman_execs/linux_arm --> /usr/local/arm/bin

Then you can just recompile your sources and install, do:

make clean
sudo make install

Currently only one architecture of target processor is supported for every family. For example, you can either have arm5 node processors and cross-compile for this target or have arm9 processors and compile for that. However, you can not have a mix of arm5 and arm9 node processors. Future ALOE versions will have a customizable set of executables directories for each architecture allowing to have an arbitrary set of different architectures.

[Back to ALOE]