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.

    2. Hi Alan,

      I have been trying to make RTEMS work over Raspberry pi 3 by building the bsp for raspberrypi2 whose support was added some time before. However, i see no console output.

      At the same time, I tried a freeRTOS port on Raspberry pi 3 and the console driver was working there. Before that i had tried a baremetal uart03 code as well which you can find here:

      Only if i can know the place of console initialization then i may be able to replace the initialization of console in RTEMS with freeRTOS to know if it works.

      Any clues on where i can find it.? I have seen few data structures which register initialization functions; however, i am not able to understand from where a console init function is called.

      Any help will be appreciated.

      Best Regards:

    3. Hi Junaid,
      The Raspberry Pi 3 and Raspberry Pi Zero W have the wireless and bluetooth module, which is connected to the UART that is used for the RTEMS console on the Pi and Pi 2.
      For these models (3 and Zero W) the Console uart is the "other" UART on the raspberry pi. I dont think there is support for this UART in the RTEMS BSP.

      I think we would need to have support for both UARTs and potentially a different BSP, or at least a different BSP configuration.

      Regardless, you can find the UART init code for the serial console in RTEMS here:

      It would be great to have full A53 with SMP support for the Pi one day. It should even be capable of 64 bit execution.
      There is already A53 Aarch32 support with an RTEMS BSP for the Ultra96 board with the Xilinx MPSoC chip.

  20. Hi Alan,

    I was also looking at the same location for the usart initialization and confirmed with your reply. However, for some reason, even after changing that initialization code and trying to print a hello world example from the same spot i am not able to see anything. I have the same initialization code running in baremetal as well as freeRTOS and both of them work perfectly on raspberry pi 3. I am not sure about the policy of your blog about posting code, but any help will be much appreciated.

    secondly, your blog has mentioned most of the things with 4.11 and 4.12. However, i have arm-rtems6 for this purpose. Does it make any difference.? I was earlier building using arm-rtems5 for simple raspberrypi but that gave issue with raspberrypi2 bsp and switched to using arm-rtems6. And then i observed arm-rtems6 was giving the assembler error for raspberrypi bsp with the error message:

    ../../../../../rtems-git/c/src/../../cpukit/score/cpu/arm/cpu_asm.S:75: Error: selected processor does not support `dmb' in ARM mode

    I now have installed both, arm-rtems5 (for raspberrypi) and arm-rtems6 (for raspberrypi2). They both build fine for each other.

    You mentioned that "It would be great to have full A53 with SMP support for pi one day". Does that mean the BSP for the raspberry pi 2 only supports single core and not the full quad core support since raspberry pi 2 have the quad core CPU on top of it.

    Do you have a code posting policy etc.? Or I should use some other medium to show you where i am stuck. :-)

    Looking forward to your reply.

    Best Regards:

  21. Hi Alan, i have been successful in porting RTEMS to the Raspberry pi 2 v1.2. Both "hello" and "ticker" samples worked. The problem is that when i use QEMU to test these two samples, i have a problem with the "ticker". The three tasks print the first message and when they do the sleep, seems like they sleep forever. I don´t know if this has something to do with the clock driver that QEMU uses.

    1. Hi Mario,
      What version of RTEMS are you using?
      The current RTEMS Git head (upcoming RTEMS 5.1) should run on all models except for the 4.
      The raspberrypi2 BSP should work on the Pi 2 and 3. I actually have not tried a raspberry pi 2 v1.2 with the Quad A53, but it is closer to the Raspberry Pi 3 without the wireless.

      I was able to run the raspberrypi2 BSP on QEMU following these instructions:

      I had to use the "set scheduler-locking" command in GDB as noted in the doc above.

  22. Hi Alan, thank you for your helpful tutorial. As many, I got stuck with a blank UART output console, and I'm trying to troubleshoot it. I'm using a Raspberry Pi 2 Model B and RTEMS v.4.11. I went over the comments and the rtems users list, where I found useful tips like:

    - switching the rsb and rtems git repositories on the origin/4.11 branches
    - using the old rpi firmware at, only substituting kernel.img with the output of arm-rtems4.11-objcopy over ticker.exe

    but they don't seem to solve my issues. I tried with RTEMS v5.1 following the user guide, but with no luck either. I don't think it is a problem with my serial connection as I get the expected output with the original Raspbian kernel.img.
    Is there anything else I can try out or double check in order to get it working? Any help would be appreciated, thank you!


    1. Hi Giorgio, It's probably time for an update based on the latest RTEMS work. I have a recent RTEMS head (git master) that runs on my Raspberry Pi 2. I just tested ticker.

      The latest firmware seems to be working with RTEMS now.

      Here are a few things to try:
      1. For the Raspberry Pi 2, make sure you are using the raspberrypi2 BSP. I would recommend using the latest git head for both RTEMS and the RSB. (at
      2. For setting up the SD card, try these directions:
      3. When running on the RPi 2, the firmware will try to boot kernel7.img unless you specify the kernel in config.txt. I usually make a single Micro-sd card and put kernel.img with a RTEMS "raspberrypi" BSP image, and kernel7.img with a RTEMS "raspberrypi2" BSP image.

      Note that in the latest git head, the RPI3 works now thanks to work by another community member! I was able to boot the raspberrypi2 bsp on the 3 model.

      If you are still having trouble, I will try to update my instructions soon, and I may also put a binary on my github account for you to try.
      Good luck!

    2. Hi Alan, thanks for your suggestions, I wasn’t using the raspberrypi2 BSP indeed, I can now confirm I got the ticker sample working for v5 on both RPi2 and RPi3, and for 4.11 on the RPi2 only (using the 1.20160620 firmware).

      Thanks again for your help,