Building a TASTE-y RTEMS

From TASTE
Revision as of 21:01, 4 August 2017 by Ttsiodras (talk | contribs) (1 revision imported)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

TASTE primarily addresses safety-critical on-board software - it therefore depends on an RTEMS capable of supporting C and Ada, and equipped (of course) with a working version of GDB for our embedded targets.

The instructions below (as of Jan 14, 2016) are based on the RTEMS Source Builder [1], and the kind advice we have received from Jan Sommer and Jerome Hugues.

Dependencies

The process depends on network access - and to be precise, non-firewalled access to Git repositories that operate over the git:// protocol, as well as FTP access to non-PASV enabled FTP servers. These requirements stem from the current (as of 2016/01/01) state of the RTEMS source builder, which checks out source code over the git:// protocol, and downloads files from some FTP servers that don't support PASV operations. You can in theory transfer the files on your own in the `sources` folder - but at least in our attempts we failed to compensate for access to git:// repos (some of them could be checked out when changed to http:// or https:// prefixes - others however, could not).

Executive summary: if your environment limits either one (or both) of these kinds of network accesses, start the TASTE VM in a less draconian place (e.g. your home, utilizing your DSL connection) and build the latest RTEMS 4.11 there.

Process

The build process for a normal RTEMS cross-compiler has been perfectly streamlined [2]. In TASTE however, we need to support Ada as well as C.

To that end, the build process deviates from the simple invocation of the RTEMS Source Builder - to these steps:

1. Clone the source builder RTEMS repo

   $ git clone git://git.rtems.org/rtems-source-builder.git
   $ cd rtems-source-builder
   $ git checkout 4.11

2. Verify the build environment

For a Debian machine, like the TASTE VM, make sure that you first...

   $ sudo apt-get build-dep binutils gcc g++ gdb unzip git python2.7-dev

Then...

   $ source-builder/sb-check
   RTEMS Source Builder environment is ok

3. Build an interim (temp) cross-compiler

NOTE: As of 2016-01-27, there is a bug in the RTEMS4.11 config files that needs a patch. Apply it from here: https://devel.rtems.org/ticket/2495

   $ cd rtems
   $ ../source-builder/sb-set-builder --log=sparc.log \
        --prefix=/opt/rtems-4.11-latest/ --without-rtems \
        4.11/rtems-sparc 
   

Make sure your account is able to create /opt/rtems-4.11-latest (otherwise create it as root and provide all permissions to the user doing the build). The script will download all the necessary source tarballs and checkout all relevant code from Git repositories, and will then compile a cross compiler, which must be placed in front of the PATH:

   $ export PATH=/opt/rtems-4.11-latest/bin:$PATH

4. Checkout and build the latest RTEMS 4.11

WARNING:

   If you need to support native FPU in your applications, you
   must build the BSPs with FPU support - i.e. remove the "-msoft-float" 
   from leon2.cfg and leon3.cfg

Read this for more information: BSP and FPU

   $ echo I have read the WARNING above and have modified the leon2.cfg and leon3.cfg if necessary
   $ cd ..
   $ git clone https://github.com/RTEMS/rtems.git rtems-git
   $ cd rtems-git
   $ git checkout 4.11
   $ ./bootstrap
   $ cd ..
   $ mkdir buildrr
   $ cd buildrr
   $ ../rtems-git/configure --target=sparc-rtems4.11 --enable-rtemsbsp="leon2 leon3" \
        --enable-posix --enable-ada --prefix=/opt/rtems-4.11-latest/
   $ make all
   $ make install

5. Use latest version of GCC to address issue with 4.9.3

Jan Sommer: "Currently the rsb downloads the 4.9.3 sources to build gcc. In this version Ada programs generated by the compiler for rtems will not work for ARM and most likely are broken for SPARC as well. The fix is already committed upstream in the 4.9-branch and will be part of the upcoming 4.9.4 release. For the time being, I think the easiest approach would be to download a recent snapshot of gcc-4.9.4 (ftp://ftp.mpi-sb.mpg.de/pub/gnu/mirror/gcc.gnu.org/pub/gcc/snapshots/4.9-20160113/gcc-4.9-20160113.tar.bz2) and replace the gcc-4.9.3.tar.bz2 file in the rsb source-directory with it".

One more thing needed besides what Jan says here, is to uncompress the gcc snapshot, and rename the folder inside it to gcc-4.9.3 (because that's what the RSB will look for). After that, repackage the .tar.bz2, name it gcc-4.9.3.tar.bz2 and overwrite the one placed in sources in step 3.

You will also need to update the MD5 checksum of gcc-4.9.3.tar.bz2 to this "hacked" one, inside the relevant config file - see example below:

   assert@tastevm:~/development/rtems/src/rtems-source-builder/rtems/config$ cat \
       tools/rtems-gcc-4.9.3-newlib-2.2.0-20150423-1.cfg 
   ...
   %hash md5 gcc-%{gcc_version}.tar.bz2 8ab125b95d457144b453475ef37a4ef8
   ...

6. Fix due to multilib absence

Jan Sommer: "We built rtems without multilib enabled (since it's broken for sparc) - we therefore need to create a symlink first:

   $ ln –s /opt/rtems-4.11-latest/sparc-rtems4.11/leon3/lib/include \
       /opt/rtems-4.11-latest/sparc-rtems4.11/sys-include

7. Build the final compiler and debugger (with Ada)

   $ cd rtems-source-builder/rtems
   $ ../source-builder/sb-set-builder --log=sparc2.log \
       --prefix=/opt/rtems-4.11-latest --without-rtems --with-ada \
       4.11/rtems-sparc