Building FESA Software for a Yocto Frontend

(Note: this is a preliminary guide, the tools will change)

Introduction

FESA on acc9 can be used natively as previous versions for frontends capable of running rocky9.

SCU frontends cannot run rocky9 and use a Yocto image compiled to suit the CPU. This means all software that runs on Yocto frontends must be built using the compiler in the Yocto SDK. The build procedure is also different: dynamic linking is used as most dependencies are in the base Yocto image (fesa/cmw/timing). This requires the generated code to be different in Native and Yocto builds.

SDK

The Yoto SDK contains a compiler configured for the SCU's CPU, header files and libraries.

Initializing the SDK environment

Run this command in a shell:

unset LD_LIBRARY_PATH; source /common/usr/embedded/yocto/fesa/current/sdk/environment-setup-core2-64-ffos-linux

After this, the environment variables used by make will point to the tools in the SDK. For example

CC=x86_64-ffos-linux-gcc  -m64 -march=core2 -mtune=core2 -msse3 -mfpmath=sse -fstack-protector-strong  -O2 -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security --sysroot=/common/usr/embedded/yocto/fesa/current/sdk/sysroots/core2-64-ffos-linux

(sysroot ensures the compiler takes all headers from the SDK, CC/CXX ensures make uses the SDK compiler.)

Make

Make will now compile and link for yocto.

If a makefile overrides CC or CXX, the host system (asl) compiler will be used. The binary generated will not work on the Yocto frontend and will give a "file not found" error.

If a makefile includes system headers from outside the SDK, the compiler will generate a warning "x is unsafe for cross-compilation"

CMake

CMake is supported. A basic CMake file will build with no changes required. Please ensure the build directory is empty before using the SDK cmake. If the host cmake is used first, running SDK cmake on the same build folder generates interesting errors.

(See also YoctoFesa)

Recipe

Initial Design

* Create a new FESA 7.5.0 class in Eclipse as for a normal build.

* Generate code for Class and DU

* Add a FEC instance file and configuration.

NOTE (until yocto support is integrated into eclipse): Before working on the instance file generate code in eclipse. The schema files generated using the Yocto SDK will cause problems with the instance editor. (promotion may assign elements to anyNs and break the instance file)

Here are recipes using 1) the python tool yocto-fesa3 and 2) sdk + bash scripts

Code Generation and Build

use the command /common/usr/fesa/bin/yocto-fesa3 this is a shell scripts that initializes the default SDK and starts the python build and deployment tool.

Navigate to the workspace directory containing MyClass and MyClass _DU (or specifiy this directory with the -w option)

yocto-fesa3 -c MyClass -d MyClass_DU gen 
yocto-fesa3 -c MyClass -d MyClass_DU build

Deployment

yocto-fesa3 -d MyClass_DU release -f MyFEC

This copies files to the nfs export folder so that they may be either started from the NFS mount or copied into the yocto ramdisk

Using alternate SDK environment (optional)

Only do that when you know what you are doing/when you are sure it is required.

The script yocto-fesa3 sets the SDK environment. To use another, set the environment then start the python tool directly:

unset LD_LIBRARY_PATH; source /common/usr/embedded/yocto/fesa/current/sdk/environment-setup-core2-64-ffos-linux
python /common/usr/fesa/tools/yocto/yocto-fesa3.py -c MyClass gen

Using alternate package configuration for saftlib 2 (optional)

Only do that when you know what you are doing/when you are sure it is required.

The FESA Makefiles find some path information from pkg-config. Building saftlib2 with the current(07-2023) SDK requires a change to the PKG_CONFIG_PATH:

export PKG_CONFIG_PATH=/common/export/timing-rte/tg-saftlib-v2-yocto/x86_64/usr/lib/pkgconfig:$PKG_CONFIG_PATH

then build as for "Using alternate SDK environment"

SCU Configuration

Yocto ramdisk image

Link the scu to the image "yocto":

cd /common/tftp/csco/pxe/pxelinux.cfg
unlink scuxl9999
ln -s yocto scuxl9999

NFSInit

In NFS Init link to the yocto start script.

cd /common/export/nfsinit/scuxl9999
unlink 50_fesa
ln -s ../global/fesa_yocto_dev 50_fesa

The disk image contains the saftlib and timing files, no timing runtime-environment needs to be linked.

FESA Software started automatically with systemd

The nfsinit script starts all FESA DUs that are in a directory of the same name (/common/export/fesa/local/scuxl9999/MyClass_DU/MyClass_DU)

By default it will attempt to restart failed processes

To check the status of a DU

systemctl status fesa@MyClass_DU

To stop a DU

systemctl stop fesa@MyClass_DU

To start a DU again

systemctl start fesa@MyClass_DU

To restart a DU

systemctl restart fesa@MyClass_DU

Start FESA Software manually

On the FEC:

cd /opt/fesa/nfs/local/scuxl9999/MyClass_DU
./startManuallyMyClass_DU

(This is only available if the nfsinit startscript enables the option --nfs)

Monitor log output

System logs and standard output from a FESA class started by systemd are managed by journald, view with:

journalctl

Building and deploying a class with MASP FESA-Emitter

As an example of building with an external library.

For details relating to the code and design see: https://www-acc.gsi.de/wiki/FAIR/Intern/FESAEmitterNew

Changes for yocto deployment

In Class and Deploy Unit Makefile.specific set these paths (The class now also needs linker flags as it is linked separately to the deploy unit and masp):

MASP_DIR=/common/usr/cscofe/opt/MASP/1.5.1/x86_yocto
COMPILER_FLAGS += -I$(MASP_DIR)/include/
LINKER_FLAGS += -L$(MASP_DIR)/lib/

Codegen/Build/Deploy as above

Copy MASP shared libraries to NFS path:

cp /common/usr/cscofe/opt/MASP/1.5.1/x86_yocto/lib/*.so /common/export/fesa/local/scuxl1234/My_DU

The FESA nfsinit boot script will copy the masp libraries to the ramdisk

-- DominicDay - 07 Mar 2023