Friday, March 29, 2013

Running your first RTEMS program on the Raspberry Pi

Running your first RTEMS program on the Raspberry Pi

So now you have RTEMS compiled and installed, what about getting an RTEMS program to actually run on the Pi ?

In case you missed anything:

Introduction to RTEMS on the Raspberry Pi Setting up an RTEMS development environment for the Raspberry Pi Compiling and Installing RTEMS for the Raspberry Pi

Did you notice the enable-tests=samples option in the configure script? It compiled some examples for you. Lets get one ready to run on the Pi:

$ arm-rtems4.11-objcopy -Obinary \
$HOME/development/rtems/bsps/4.11/arm-rtems4.11/raspberrypi/lib/rtems-4.11/tests/ticker.exe kernel.img

Now you can copy the kernel.img file on your SD card and see if it works! Remember to back up kernel.img on your SD card before you copy this.

Currently, the RTEMS port for the Raspberry Pi uses the UART port for it’s console. You will need to get a USB UART cable like the following:

If you are using Ubuntu you can use the “minicom” program to connect to the serial port. If you are using Windows, you can use a program such as: uCon

However you connect to the serial port, set the serial port to 115k baud and 8N1.

When you boot the Pi with the SD card containing your kernel.img file, you should see output like this:

TA1  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:00   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:05   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:10   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:15   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:20   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:25   12/31/1988
TA1  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA3  - rtems_clock_get_tod - 09:00:30   12/31/1988
TA2  - rtems_clock_get_tod - 09:00:30   12/31/1988

The program should take 35 seconds to run.

Next: Building and running an RTEMS Application


  1. I have follow the guide until here... in this moment I haven't a cable for verify if the system working properly.... but I wire the raspi with an LCD and in this moment I can see on my display a rectangle with a sort of "logo" in wich there are four colour, placed in quadrants, one colour for quadrant, and in red, yellow, blue and chan (or similar green) with a black background.

    Can you confirm (or not) this feat. while the test program is running?

  2. I have just finished to try the tutorial with a FTDI232RL and a serial-term pgrm.
    All work properly with both generated kernel.img ( by debianVM and MacOsX).
    We can move on...

    1. Great! I was just going to reply that I think the color pattern comes up with the bootloader. If I remove the kernel.img file, the pattern still appears.

      I'm working on a standalone RTEMS application example now. It will show how the ramdisks , shell, and a few other RTEMS features work.

  3. This comment has been removed by the author.

  4. Great!!!
    had long wanted to learn RTEMS but often I'm stuck at various points in the compilation and / or more ... maybe this time is the right time...

    I have notice also that if I want debug a sample such ticker.exe or hello.exe with
    arm-rtems4.11-gdb $HOME/development/rtems/bsps/4.11/arm-rtems4.11/raspberrypi/lib/rtems-4.11/tests/ticker.exe the it don't work like I've seen substituting the kernel.img. Can you explain this?

    I made:
    arm-rtems4.11-gdb /"pathabove"/ticker.exe
    tar sim

    At this time the shell is blank and remain in this state until I stop with Ctrl^C ...
    At this point the sys making insulting me for badly interrupting the process.

    1. I don't think the raspberry pi RTEMS binary will work on the arm GDB sim.
      I think armulator is the right BSP for that:

      Another good starting point: Follow the getting started GSOC tutorial:
      ( but of course, if you want to stick with Mac OS X, continue to build the tools using RTEMS source builder )

      If you want to get into general RTEMS development, feel free to join the RTEMS mailing list too. You will find help for just about anything there:

  5. This comment has been removed by the author.

  6. Hi, I have some questions:
    I've tryed to compile also the sparc-erc33, I follow the adapted guide:
    Build and install the toolchain (../source-builder/sb-set-builder --log=build-log.txt --prefix=/Users/saro/development/rtems/compiler/4.11/ 4.11/rtems-sparc) -> ok
    I' don't have executed autotools!
    I' don't have executed bootstrap!
    rtems configure (../rtems-git/configure --target=sparc-rtems4.11 --enable-rtemsbsp=erc32 --enable-tests=samples --enable-networking --enable-posix --prefix=/$HOME/development/rtems/bsps/4.11/);
    make install -> failed

    1. To summarize:
      1. You did build the sparc toolchain OK
      2. Did not need to bootstrap RTEMS or install auto tools again, that is right.
      3. The configure ( in a separate build directory for the sparc? ) worked
      4. The actual make failed

      It looks like you did everything correctly. What was the build error?

      I have only worked with ARM on RTEMS 4.11/git
      I use RTEMS 4.10.2 with Sparc and m68k right now.

  7. This is similar for leon2:

    configure: error: in `/$HOME/development/rtems/build-rtems-leon2/sparc-rtems4.11/c/leon2':
    configure: error: C compiler cannot create executables
    See `config.log' for more details
    make[2]: *** [leon2] Error 1
    make[1]: *** [install-recursive] Error 1
    make: *** [install-recursive] Error 1

  8. I checked ... and the error is the same for all platform on which I had troubles.
    i386 on pc386 & on pc486, sparc on erc32 & on leon2..
    It sounds like a systematic error ...

  9. This comment has been removed by the author.

  10. Another thing,
    setting path to your enviroment setup, if you have already installed other toolchains (like me), there is the possibility that many version of several tools (like autoconf) are present in the system..
    This can cause troubleshooting when we compile other toolchains or RTsystems (like ChibiOS).
    I don't know how to fix this problem.
    In my case, I resolved it commenting, temporanealy, the line in which I export the enviroment variable to rtems, then compiling the building and finally I can re-enable the unsetted variable (logically we must logout and login before compiling and re-do this sequence when you finished to set again the variable).

  11. This comment has been removed by the author.

  12. Hello Alan,

    Cheol from KARI.
    I am glad to see the your blog and interested in your RTEMS work with Raspberry Pi ~!

    Hope may see you in July US with Jonathan.


    1. Hi Cheol,
      Looking forward to seeing you in July!

  13. ticker.exe doesn't end up where you indicated, but I was able to builder the kernel.img and saw it work on the rpi using this command:

    arm-rtems4.11-objcopy -Obinary $HOME/development/rtems/build-rtems-rpi/arm-rtems4.11/c/raspberrypi/testsuites/samples/ticker/ticker.exe kernel.img

    1. I second this for the compilation of 4.11 and 4.12 for the pi.

  14. Alan,
    I followed the directions, and everything worked find until I tried to run the ticker example on my R Pi.
    When I boot the ticker kernel.img I get no output.
    To verify the console connection, I booted a 'raspbian' kernel which worked fine.
    Do you have any suggestions I might try to trouble shoot this?

    1. Dave,
      ( my reply seems to have vanished.. so this may be a duplicate )
      I just rebuilt all of the tools and RTEMS and ticker still works for me. This is on my Model B. I'll have to try my A+ a little later today.

      What does your config.txt look like?
      This is mine:
      # kernel=rki.bin

  15. config.txt?
    My SD card only has the file kernel.img, which some quick online reading tells me is not sufficient.
    I started with a 'NOOB' SD card, which doesn;t have either config.txt or kernel.img.
    I am trying these examples on a fresh SD card.
    BTW, I am doing this on a model B+.

    I'll post more once I figure out the minimum files needed to boot.


  16. Got it working, woo hoo.

    According to the README at
    the minimum needed is bootcode.bin, start.elf, and kernel.img.

    I downloaded the first two files from

    Now to read about and experiment with config.txt, and try out your RKI.

    Thanks for posting this blog, it is very helpful.

  17. This comment has been removed by the author.

  18. This comment has been removed by the author.

  19. Hi,

    We are trying to load RTEMS on raspberrypi compute module 3 as per your procedure. We have built the kernel and copied the hello.exe( converted to kernel.img) to the sd card.

    SD card contents :

    1) kernel.img
    2) start.elf
    3) bootcode.bin
    4) config.txt

    When the board is powered on, the debug console shows nothing.

    We have tried on both 4.11 and 5

    1. Hello,
      There are potentially a few problems:
      1. We have not tried RTEMS on a compute module yet. Does the flash memory have the same boot partition as the SD card on the regular Pi?
      2. There is a problem with the newer version of the firmware that prevents RTEMS from working. I have been able to use firmware from June 2016:
      3. We have not tested RTEMS on the Pi 3 (A53). But that is mostly due to the fact that on the Pi3 board, the console UART is used for the Bluetooth. The CM 3 device may still be able to use the same console UART.

      I would try the firmware first, it may work.