How to compile the Core Flight System on The Raspberry Pi

Building the core Flight System (cFS) on the Rasperry Pi

This set of instructions will allow you to download, compile, and run the core Flight System (cFS) on a Raspberry Pi, running the Raspian OS.

Notes:

1. These instructions assume you will be compiling the code on the Raspberry Pi. It also possible to cross compile the cFS for the Raspberry Pi, but that is not covered in these instructions.
2. The changes outlined below involve removing the “-m32” flags from the compiler options. The “-m32” flags are used to build the cFS as a 32 bit executable on 64 bit linux systems. The next release of the cFS should build and run as a 64 bit executable.
3. The instructions take the approach of altering the “pc-linux” platform support for the cFS. This works because x86/x86_64 Linux is mostly compatible with the raspberry Pi Linux (Raspbian). A better way to support both linux on the PC and Raspberry Pi (especially if you want to cross compile) would be to copy the “psp/fsw/pc-linux” directory to “psp/fsw/rpi-linux” and make the changes there. Then you will need to specify the “rpi-linux” PSP in the file: build/cpu1/cfe/cfe-config.mak. By doing this, you can support builds on x86 linux and the Raspberry Pi at the same time. Another approach would be to use the CMake build system, which is described below. 
4. These instructions were tested on a mid 2018 release of Raspian. cFS is version 6.5

The cFS has two build systems:

1. A standard “Makefile” based build system
2. A build system based on the CMake build tool : https://cmake.org/

Eventually the standard "Makefile" system will be removed, and the cFS will only support the Cmake system. 

cFS Raspberry Pi Standard Makefile Build Instructions

First, let's tackle the build using the “classic” makefile based build system. This build system is older, but is compatible with the “cFS-101” tutorial on Github.

Download the cFS:

The current open source version of the cFS, Operating System Abstraction Layer (OSAL), and all open source cFS applications are hosted on a single github repository for convenience. While the cFS community is interesting in getting feedback, the repository is not currently used to accept pull requests.

$ git clone https://github.com/nasa/cfe.git

$ cd cfe

$ git submodule init

$ git submodule update

What needs to be changed for the Raspberry Pi (running Raspbian OS) ?

The PC Linux build has compiler switches to build it as a 32 bit application (-m32). To build on the Raspberry Pi, you need to comment out/edit these switches. 

Edit the file psp/fsw/pc-linux/make/link-rules.mak

In that file, and remove the -m32 switch below:

##

## Linker flags that are needed

##

LDFLAGS = -m32 -Wl,-export-dynamic

In the same file, there is one more -m32 switch in the bottom of the file.

##

## Application Link Rule

##

$(APPTARGET).$(APP_EXT): $(OBJS)

       $(COMPILER) -m32 -shared -o $@ $(OBJS)

Next, edit the file  psp/fsw/pc-linux/make/compiler-opts.mak

In that file, remove the -m32 switch below:

##

## Compiler Architecture Switches

##

ARCH_OPTS = -m32

Also, remove -melf_i386 from the line below

##

## Compiler tools

##

COMPILER=gcc

ASSEMBLER=as

LINKER=ld -melf_i386

Finally, edit the file for the elf2cfetbl utility. Edit the file:

tools/elf2cfetbl/for_build/Makefile

Again, you need to remove the -m32 option from the ARCH_DEFS line

##

## Architecture / debug defines

##

ARCH_DEFS = -m32 -g

Finally, you can run the build:

$ source setvars.sh

$ cd build/cpu1

$ make config

$ make

If everything built OK, then you can run the cFS:

$ cd exe

$ sudo ./core-cpu1.bin

Note that the cFS currently runs as sudo or root on Linux. This is to enable the "real time" pthread scheduler and allow for larger posix message queue message sizes. It is possible to adjust the posix message queue sizes and run with the standard scheduler, but that will not be covered here.

When you are finished running, hit control-c to stop the cFS process.

cFS Raspberry Pi CMake Build Instructions

Next, lets cover how to download, compile, and run the cFS on a Raspberry Pi using the CMake build system. 

Notes:

1. These instructions assume you will be compiling the code on the Raspberry Pi. It also possible to cross compile the cFS for the Raspberry Pi, but that is not covered in these instructions.
2. The changes outlined below involve removing the “-m32” flags from the compiler options. The “-m32” flags are used to build the cFS as a 32 bit executable on 64 bit linux systems. The next release of the cFS should build and run as a 64 bit executable.

Prerequisites:

$ sudo apt-get install cmake

Download cFS:

$ git clone https://github.com/nasa/cfe.git

$ cd cfe

$ git submodule init

$ git submodule update

$ mv build legacy_build

$ cp -a cfe/cmake/sample_defs .

$ cp cfe/cmake/Makefile.sample Makefile

First, you need to edit sample_defs/toolchain-cpu1.cmake

In the file below, change the CMAKE_SYSTEM_PROCESSOR to arm

Also comment out the last line that has the “-m32” switch

--------------------------------------------------------------------------------------------------

# This example toolchain file describes the cross compiler to use for

# the target architecture indicated in the configuration file.

# In this sample application, the "cross" toolchain is configured to

# simply use the system native compiler with the "m32" switch to output

# 32-bit code on a 64-bit system.  This will not be necessary in

# future revisions.

# Basic cross system configuration

SET(CMAKE_SYSTEM_NAME           Linux)

SET(CMAKE_SYSTEM_VERSION        1)

SET(CMAKE_SYSTEM_PROCESSOR      arm)

# Specify the cross compiler executables

# Typically these would be installed in a home directory or somewhere

# in /opt.  However in this example the system compiler is used.

SET(CMAKE_C_COMPILER            "/usr/bin/gcc")

SET(CMAKE_CXX_COMPILER          "/usr/bin/g++")

# Configure the find commands

SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM   NEVER)

SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY   NEVER)

SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE   NEVER)

# These variable settings are specific to cFE/OSAL and determines which

# abstraction layers are built when using this toolchain

SET(CFE_SYSTEM_PSPNAME      "pc-linux")

SET(OSAL_SYSTEM_BSPNAME     "pc-linux")

SET(OSAL_SYSTEM_OSTYPE      "posix")

# This adds the "-m32" flag to all compile commands

# SET(CMAKE_C_FLAGS_INIT "-m32" CACHE STRING "C Flags required by platform")

Next, edit the tools/elf2cfetbl/CMakelists.txt file

You need to comment out the “-m32” switch as below:

------------------------------------------------------------------------------------

# force build as 32-bit

# set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -m32")

add_executable(elf2cfetbl elf2cfetbl.c)

Now you can build the cFS using the cMake build system:

$ make prep

$ make install

If everything built OK, then you can run the cFS:

$ cd build/exe/cpu1

$ sudo ./core-cpu1.bin

When you are finished, hit control-c to stop the cFS

A Low Cost JTAG Debugger for the Raspberry Pi

Setting up the MiniMod FT2232H For JTAG Debugging on a Raspberry Pi

The MiniMod FT2232H is an evaluation module for the FTDI FT2232H USB interface part. This part can be used to bridge a number of embedded interfaces to USB. There are many JTAG debugger interfaces that are implemented using this chip.
For this setup, we will use the low cost MiniMod, some jumper wires, and the OpenOCD software to provide JTAG debug interface to the Raspberry Pi.
The JTAG interface, along with the Open Source OpenOCD software can be used to load and debug the Raspberry Pi from your development machine. In addition to the JTAG, the MiniMod can be used to provide the UART interface for the Raspberry Pi UART, all through the same USB connection to the PC! This is an inexpensive solution too. I bought my FT2232H MiniMod for $20.00 USD.

I was able to get this all working thanks to the amazing work of David Welch. David’s github site http://github.com/dwelch67 has all of the information about JTAG debuggers on the Raspberry Pi. Many of the setup instructions here are similar to David’s although I had to adjust the pinouts slightly for the FT2232H module.

When you work on your Pi hardware, make sure it is not plugged in to power first! Also, be sure to avoid static electricity when working with your Pi and the MiniModule.

Collect the parts you need :

You will need the following

1. FT2232H MiniMod. I found mine on ebay for $20 USD.
   
2. A pack of jumper wires. You could also wire up a Pi GPIO header so you can easily remove the debug setup.
   
3. A USB cable to connect the MiniModule to your development computer.
   

When looking at the MiniMod connector pins facing you, this is how the pins are numbered:

2	1
4	3
6	5
8	7
10	9
12	11
14	13
16	15
18	17
20	19
22	21
24	23
26	25

The Pins on the pi are reversed: Pin 1 is at the bottom since we are looking at the bottom of the connector on the MiniMod and the Top of the connector on the Pi:

26	25
24	23
22	21
20	19
18	17
16	15
14	13
12	11
10	9
8	7
6	5
4	3
2	1

---

A view of the Pins on the MiniMod:

---

The Pins on the Raspberry Pi:

Wire up the MiniMod module to the Pi :

We need to connect 10 of these jumper wires between the Pi GPIO header and the FT2232H MiniMod. The following tables guide you through the connections you need to make. Some of the connections will go from one pin to another pin on the same connector:
Raspberry Pi to Raspberry Pi Connections:

Pin number on Pi	Pin Number on Pi
1	15

---

Minimod Connector 2 (CN2) to Minimod Connector 2 Connections:

Pin number on MiniMod CN2	Pin Number on MiniMod CN2
1	11

---

Minimod Connector 3 (CN3) to Minimod Connector 3 Connections:

Pin number on MiniMod CN3	Pin Number on MiniMod CN3
1	3

---

Minimod Connector 3 (CN3) to The Raspberry Pi Connections:

Pin number on MiniMod CN3	Pin Number on Pi
25	8
26	10

---

Minimod Connector 2 (CN2) to The Raspberry Pi Connections:

Pin number on MiniMod CN2	Pin Number on Pi
2	6
7	22
9	18
10	7
12	13

---

When you are finished, it should look something like this:

Next, we are going to get the MiniMod working as the UART and JTAG interface for your Pi!

Starting up Pi/RTEMS development again, updates on the way!

Coming soon to a Pi near you

I have finally started to get back into my RTEMS Raspberry Pi development. I have a few updates that I will try to get on here soon:

• I have updated my development environment to Ubuntu 14.04 LTS

• I have been experimenting with alternative ways of loading the RTEMS code (u-boot, jtag). I will document how to set up a TFTP based network boot for RTEMS images.

• I purchased and set up a very inexpensive JTAG solution for the Pi. I will document how this all works.

• I am going to mentor a Google Summer of Code student this summer to add peripheral support to the RTEMS Raspberry Pi BSP

So, stay tuned!

An RTEMS Application Framework - RKI

Building and Running an RTEMS Application

---

Introduction

In the previous entries, I described how to set up an RTEMS development environment for the Raspberry Pi on an Ubuntu 12.10 system, build RTEMS, and run a sample program on the Pi. This entry will describe how to build and run a more complicated application.

---

RTEMS Kernel Image

The name of my application is called the RTEMS Kernel Image or RKI. You may have noticed that RTEMS is hard enough to set up a development environment. Unless you are using the examples that can be downloaded, it can be a bit more work to put together your first standalone RTEMS application. Other real time operating systems such as vxWorks have the tools to configure and create a base "kernel image" for your processor card. This RKI project is an attempt to provide a similar environment. If nothing else, it will provide an example of how to put together an RTEMS application that consists of multiple C files.

---

Installation

If you have the arm-rtems4.11 tools installed, and the Raspberry Pi RTEMS BSP compiled and installed on your development machine, then this next step is pretty simple.

---

1. Clone my RKI git repository:

$ git clone http://github.com/alanc98/rki.git

---

2. Switch to the rki/build-arm-rpi directory

$ cd rki/build-arm-rpi

---

3. Edit the Makefile and adust the environment

In this case, I am using the same directories we used in the tool setup.

Set the following variables in the makefile

## ## paths for the RTEMS tools and RTEMS BSP ## RTEMS_TOOL_BASE=$HOME/development/rtems/compiler/4.11 RTEMS_BSP_BASE=$HOME/development/rtems/bsps/4.11

---

4. Now, just build:

$ make

You will end up with a binary file called rki.bin. Copy that to your SD card as kernel.img and you are ready to try it out.

For more details, see the readme file in the project, and spend some time checking out how the application is put together.

github RKI site

---

Whats next?

Eventually, I would like to see full perpheral support for the Raspberry Pi. We still need to add support for things like:

• SD Card support - Ability to mount, read, and write files

• USB and Network support

• HDMI Console Support

• Some sort of Graphics support - Could RTEMS use the GPU?

In addition, RTEMS has a few things on the horizon including a dynamic loader and support for porting BSD drivers.

Setting up an RTEMS Development Environment for Windows

---

Update

I have updated the windows setup with a set of newly built mingw32 toolchains for RTEMS. Now the arm-rtems tools match the ones I build with the RTEMS source builder tool. In fact, these mingw tools are compiled using the RTEMS source builder on FreeBSD. I’m pretty sure this would work on linux as well.

---

Introduction

In a previous entry, I described how to set up an RTEMS development environment for the Raspberry Pi on an Ubuntu 12.10 system. This entry will describe how to setup a similar environment on Windows 7 and/or Windows 8.

To have a working RTEMS development environment on Windows, you need a few development packages:

Windows Tools Needed

• A MinGW native GCC compiler for windows

• A collection of GNU build utilities known as MSYS

• One or more RTEMS MinGW cross compilers

Let’s look at each one of these:

---

1. MinGW

The MinGW project that provides the native x86 gcc compiler seems to be going through a transition. There are a few different MinGW projects:

MinGW Projects

• The original 32 bit MinGW

• The newer unrelated 64 bit Mingw-w64

• Other builds of the MinGW system such as: TDM-Dragon MinGW

I use the TDM-Dragon MinGW installation.

---

2. MSYS

To build RTEMS, you also need some Unix run-time tools to properly configure RTEMS with the automake/autoconf tools. These run-time tools are provided by a set of ports called MSYS. I use a package of these tools that include the automake/autoconf tools, git, make, a nice unix shell, etc.

---

3. RTEMS MinGW cross compiler

The RTEMS project provides MinGW RTEMS cross compilers for all of the architectures, including ARM. MinGW is a port of the GNU compiler to the native Win32 environment. You also need the RTEMS cross compiler for either Mingw or Cygwin. These are provided by the RTEMS project.

---

My Windows 7 RTEMS compiler setup

Here is exactly what I used to setup my Raspberry Pi RTEMS environment for Windows 7 64 bit:

1. The TDM-Dragon MinGW compiler

2. A pre-built Msys collection. This is a nice package because it includes git, which will be needed to check out RTEMS.

3. The RTEMS mingw arm-rtem4.11 compiler from the RTEMS project

Here is where I put everything:

Table 1. Directory Structure

Path	Description
C:\opt	The base directory for all Tools
C:\opt\mingw	Install directory for TDM-GCC Mingw
C:\opt\msys	Install directory for the msys bundle
C:\opt\rtems-4.11	Install directory for the RTEMS compiler tools

---

Installation

Do the following steps:

• Install TDM-MinGW in C:\opt\mingw

• Set the Windows system Path to include C:\opt\mingw\bin

• Unpacked the msys bundle into C:\opt\msys

• Set the Windows system Path to include C:\opt\msys\bin

• Edit the file c:\opt\msys\etc\fstab to include the following lines:

c:/opt/mingw /mingw c:/opt /opt

The fstab setup will make sure when you unpack the RTEMS tools, they will go in the right place.

Download the arm-rtems4.11 tools from the RTEMS project here: http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/4.11/mingw32/

I downloaded:

rtems-4.11-arm-rtems4.11-1.tar.bz2

These compilers are all updated often, and will change! You may need to re-download and unzip the compiler when it is updated.

I recommend putting the files you download in C:\opt so they can be uncompressed in the correct directory.

Unpack all of the files you downloaded To do this, open a command prompt, and run the bash shell:

sh

Your command prompt should change to this:

$

Change to the "opt" directory and unpack:

$ cd /c/opt $ tar -xf rtems-4.11-arm-rtems4.11-1.tar.bz2

When you are done, you should see all of the tools in C:/opt/rtems-4.11/bin

Set the Windows system path to include:

C:\opt\rtems-4.11\bin

So at this point your path should include:

c:\opt\mingw\bin;c:\opt\msys\bin;c:\opt\rtems-4.11\bin

I recommend putting these path entries at the start of the PATH environment variable, because msys "find" command is needed by the configure script. If these paths are at the end of the environment variable string, the windows "find" program will be used instead and the RTEMS configure tools will not work.

If you have everything set up correctly, you should be able to open a command prompt and type:

$ arm-rtems4.11-gcc -v

You should see the compiler version message. The compiler is installed and ready to use! If you are using the unix sh, then the commands will work the same way they do in linux. In fact, there is a nice program called "mintty" that provides a resizeable unix shell window. I have been able to use this mintty, the old DOS style command prompt and the Windows PowerShell to build code.

Next: Download and build RTEMS