A Real-Time Operating System on the Raspberry Pi

The Raspberry Pi has received a lot of attention since its release in early 2012. It was designed to be a simple, low-cost device for use in schools to encourage interest in computers and computing. Whether that goal has been achieved is perhaps still open to debate, but what is clear is that the device has gained a significant following in the hobbyist and DIY world.

There is a strong, active community and support from the Raspberry Pi foundation focused on their Raspian Linux distribution, which is a Debian derivative with support and optimisation for the Raspberry Pi hardware.

At first glance the features that make the device attractive for hobbyists could also make it useful for professional developers looking for a low-cost development platform for real-time and/or embedded applications.

A platform for professional developers?

The board is centred on a Broadcom BCM2835 media applications system-on-chip device and provides the following:

– VideoCore GPU (graphics processor)
– ARM1176JZF-S CPU (general purpose processor)
– IEEE 754 compliant VFP (ARM hardware floating point)
– 512 MB SDRAM
– General purpose i/O pins
– I2C, I2S, SPI and PWM controllers
– USB host interface
– On-board Ethernet interface
– Bootstrap via external SD card

But there is much more to consider before using this, or any other, platform for something like a real-time embedded control application. For example:

– Hardware availability
– Mechanical stability
– EMC and environmental performance
– Access to documentation and reference material
– Technical support for the hardware and software
– Development tool support
– RTOS and middleware support

The Raspberry Pi was not designed with commercial/industrial applications in mind, which might be reason enough to disregard it as a serious contender as a platform for development. The recent announcement of the Raspberry Pi Compute Module might change that though.

My expertise is in embedded software development so I want to explore the software aspects in more detail, in particular, how to get a real-time operating system (RTOS) or kernel running on the board.

The right tools for job

The ARM1176 core has been around for 10 years and has been used in many commercial products including the Apple iPhone 3G and the Amazon Kindle. It is still being licensed for new designs due to its maturity and low implementation risk.

The documentation for the ARM1176 processor core is freely available from the ARM website. The ARM core is part of the Broadcom BCM2835 processor. There is some documentation for the on-chip peripherals but it is limited and contains various errors and omissions.

A cross-compiler is needed to build software for the Raspberry Pi on a desktop computer. This may be provided by the RTOS vendor but, if not, both free and commercial products are available for use on Windows and Linux hosts. YAGARTO (www.yagarto.de) is a free cross-compiler based on the GNU ARM toolchain.

CrossWorks for ARM from Rowley Associates is a commercially-supported cross compiler that even provides example board support files for the Raspberry Pi required to run a bare metal application or bootstrap a real-time operating system.

An important tool in traditional board bring-up is a JTAG debugger. Most embedded processor boards, whether off-the-shelf or custom designed, will have a JTAG header on the PCB. The Raspberry Pi does not have a dedicated JTAG header but the JTAG signals are available as alternate functions on six of the GPIO pins that are routed to the 26-pin expansion header on the board. So a JTAG interface can be provided by reconfiguring these pins by bootstrap code or later in the software initialisation sequence, if required.

This will require an adaptor to connect a standard JTAG debugger to the header on the Pi, and while these pins are used for JTAG, they are not be available as general purpose I/O.

Boot strap and beyond

One of the nice features of the Raspberry Pi for educational and hobbyists is that it is impossible to ‘brick’- there is no on-board user-programmable flash memory for storage of programs or data. (The Compute Module does have flash memory but it can be programmed via USB interface.)

Following power-on reset, the ARM core is held in reset and the GPU core runs a ROM-based bootloader that looks for configuration data and an operating system or application image to load from an external SD card. If an image is found it is loaded into memory from the SD card and the ARM core is taken out of reset and begins executing the image.

The GPU plays no further role unless the application or operating system wants to make use of its video processing services. This means the development cycle for bringing up a new operating system involves copying the kernel image from the development host to the SD card, inserting the SD card and power-cycling the board.

Running an operating system on a new hardware platform typically involves developing a board support package (BSP). The BSP is a collection of hardware-dependent routines and device drivers that provide support for the fundamental hardware blocks in the processor, enabling the kernel to provide its services to application software. These hardware blocks include the following:

– An external memory controller (for access to the SDRAM)
– An MMU (for virtual memory and cache control)
– A general purpose timer (to provide a system clock tick)
– An interrupt controller
– A UART (for console output)

Device drivers will also be required for other devices and interfaces the application wants to use, for example, USB, networking, SDHC, I2C, SPI, general purpose i/o, etc.

The effort required to get a kernel running on a new board depends partly on how much code can be re-used or adapted from BSPs for similar target boards, and how much has to be written from scratch. It also depends on the quality of the development environment (compiler toolchain, debugger, profiler, etc)and even more importantly on the experience of the team doing the BSP development.

Foundations for supporting an RTOS kernel

My colleagues and I have been developing BSPs for various real-time operating systems and embedded Linux for over twenty years. We have particular experience and expertise with Wind River’s VxWorks real-time operating system going back to the early 1990s. So what would be the steps to get an RTOS like VxWorks running on the Raspberry Pi?

Before starting the development we should consider what off-the-shelf components are available and what would have to be developed specifically for the Pi.

The first thing to check is the support for the ARM1176 core. This is supported by the ARMv6 architecture libraries, which provide support for the MMU and caches in the processor. (The BCM2835 actually has a second MMU that is configured by the GPU at start-up to map the SDRAM and peripherals onto an internal system bus but this can be ignored as far as an RTOS on the ARM core is concerned.)

Setting up the SDRAM controller is an important process and has to be done correctly to avoid random and difficult to track down problems later on. Doing this on a modern processor with fast DDR3 memory is more like magic than engineering. Fortunately, the SDRAM is set up by the GPU so this step does not need to be done by the operating system.

However, the default behaviour is for the available RAM to be split equally between the GPU and the ARM core. A model B Pi has 512 MB of SDRAM, so 256 MB will be available for the RTOS by default. This is controlled by one of the configuration files (config.txt) read by the bootloader from the SD card. This file can be changed if more memory is required for the kernel.

The BCM2835 interrupt controller is responsible for handling interrupts from the ARM core and the VideoCore GPU. The controller is specific to the BCM2835 so a new driver is required for the operating system to enable and disable device interrupts, and dispatch interrupts to handlers registered by individual device drivers. This is another tricky task and one where good debugging or instrumentation tools and techniques are required to ensure a stable foundation.

The VxWorks kernel, like many others, requires a timer to provide a periodic system clock tick to schedule tasks, maintain software timers, and determine when certain operations have timed out. The BCM2835 includes a System Timer peripheral that provides four 32-bit timers and a 64-bit free running counter.

One of the 32-bit timers would be suitable to provide the system clock tick but of course a new device driver would be required.

Console I/O and networking

A serial console is the default for most operating systems. The processor has two UARTs but due to pin multiplexing limitations on the standard boards only one can be used. The Compute Module has much more GPIO so both UARTs could be used.

One of the UARTs is an (almost) 16550-compatible device (known as the mini UART), the other is an ARM Primecell PL011-compatible UART. Drivers for both these types of device are commonly available so it should be fairly straight-forward to get the console running. The default pin multiplexing brings out PL011 UART.

With these components and tools it should be possible to get to the point where the RTOS or kernel is running on the board and console i/o is available. There is still a lot of work to do before the board can be used in an application, however.

Operating system-specific device drivers are required for the
peripherals that will be used by the application software. (And we haven’t even considered using the GPU services to provide output and graphics on the HDMI interface.)

For a VxWorks development project we could start using the standard development tools running over a serial connection to board. This would avoid having to re-program the SD card to download and test new drivers and application software. Using the serial interface for the debug connection means it is not available for application-specific use. It would be preferable to use the network interface to load the kernel and application software onto the target.

The network interface is provided by a SMSC LAN9512 Ethernet controller (it is a LAN9514 on the Model B+), which is connected to the USB host interface. To use the network interface a lot of additional software (and effort) is required:

– A USB host controller driver for the Synopsys DesignWare USB 2.0 OTG
controller embedded in the processor
– A USB host stack with USB networking infrastructure
– A device driver for LAN9512/4 Ethernet controller

These components are not specific to the Raspberry Pi so, if not already available of-the-shelf, development of this software could be done on a suitable reference board which is already supported by the RTOS plus an evaluation board for the LAN9512 such as the EVB9512.

The work could be done in parallel with the RTOS bring-up on the Pi and integrated with the Pi BSP software once it is working on the reference board. VxWorks, for example, supports the Synopsys USB controller and provides a USB networking infrastructure so just the LAN9512 support would have to be developed.

Conclusion

Getting an RTOS to run on the Raspberry Pi provides some interesting technical challenges, albeit challenges we have seen on different real-world projects over the years.

Even though the hardware is low-cost and widely available, the modest GPIO, single UART and USB networking, the potential software development costs could outweigh these benefits if one were considering the standard boards. It will be interesting to see if the new Raspberry Pi Compute Module drives the need for RTOS support on this platform.

2018-07-02T10:48:57+00:00September 24, 2014|Blog|

15 Comments

  1. edward hiskes 15th November 2014 at 3:21 am - Reply

    So if the Raspberry Pi does not have an RT available off the shelf, does BeagleBoard or some other board have one ready?

    Thanks.

    EVH

    • John Efstathiades 17th November 2014 at 2:50 pm - Reply

      Hi. There are some RTOS ports off-the-shelf for RPi, for example FreeRTOS and ChibiOS/RT. I believe there is an OS-9 port on the way. There are many evaluation boards that come with RTOS board support package support. I suggest you start with an RTOS you are interested in and look for supported boards.

  2. Donald Murray 15th November 2014 at 4:16 am - Reply

    I saw an article on this subject in Embedded Computing, and the same question came up recently in the Firmware group on Linkedin.com.
    The problem with the Raspberry Pi is it is not a fully open system. It uses the broadcom chip, which is where the designer works. Broadcom have a lot of their system closed, such as security, video subsystem, etc, so you can’t just write a driver that uses this system. You could perhaps write a framebuffer driver, but then you are losing the advantages of this chip. You could, of course, not use the video side of things, and then you’d probably be OK.
    As for the other drivers you could probably find drivers already for these parts already existing for another RTOS or Linux and convert them over easily. Note that Broadcom provided a linux video driver binary for the project. You might be able to use that driver and link to it’s interfacce. That might work with an RTOS. That is messy though. Most people who use the RPI use linux. Olimex provides some cheap boards based on the Allwinner series of ARM SOC’s and these chips are much more open, and the linux drivers are all available. That might be a better board for an RTOS.
    Good luck and keep us posted. Note that you’d be better off porting freertos to the pi. Vxworks isnt’ the best choice…you might as well go with Linux or QNX than use VxWorks….
    Choosing VxWorks is like the choice of the broadcom chip… 🙂

    • John Efstathiades 17th November 2014 at 2:55 pm - Reply

      Donald, thanks for the suggestions.

      I’m not really interested in the video interface so the closed nature of the hardware is not a big issue. You are right in saying that there are many other more suitable boards but I looked at the RPi because of the wide interest and the new Compute Module aimed at people who want to design the RPi into their product.

    • kam 16th January 2015 at 4:07 pm - Reply

      Ok, im confused , is Rpi a real embedded dev board or just a Embedded pc for hobby!? i bought one and still can’t find out well!

      What im looking to learn is Cortex-A OS-Linux embedded programming, that companies like nest include in their systems, like nest uses A8 with linux kernel and so does ar.drone ! i want something like that, a real product not hobby toy!

      • John Efstathiades 19th January 2015 at 5:24 pm - Reply

        Hi Kam. Thanks for taking the time to read the article.

        The Raspberry Pi was designed to be a low-cost computer to teach school children about programming and electronics. It has also been taken up by hobbyists and others. The RPi Compute Module is aimed at commercial product designers and is being incorporated in to real products. See here http://www.raspberrypi.org/tag/compute-module/

        If you want to learn about the Cortex A8 processor you can get hold of something like the BeagleBone Black.

  3. Joel Sherrill 22nd January 2015 at 8:45 pm - Reply

    RTEMS (http://www.rtems.org) has had a BSP for the Raspberry Pi since September 2013 and a BSP for the entire family of BeagleBoards since early this year. There are blogs by the persons about their porting experience. Adding drivers for more peripherals for the Raspberry Pi was a Google Summer of Code 2014 project.

    Technically, RTEMS is single process, multi-threaded with support for nearly all of POSIX that can be expected to work without fork(). We have a number of SMP, filesystems, IPV4/IPV6, USB, rate monotonic application support, alternative thread schedulers, ports to over 15 processor architectures, and over 180 BSPs now. The high level of POSIX support means that porting to RTEMS is easy.

    RTEMS is very conscious of providing a truly open source solution that is not dual licensed-licensed, limited to non-commercial use, or places obligations on the end user.

  4. John Efstathiades 24th January 2015 at 4:12 pm - Reply

    Hi Joel,

    Thanks for the RTEMS link and info. The GSoC 2014 project looked at I2C and SPI, if I understood correctly. Will you be adding USB and Ethernet support in the future?

    John

  5. Martyn Eggleton 27th November 2015 at 7:06 am - Reply

    Now the Pi Zero $5/£4 board is out I’d expect interest in this to pick up.

  6. William H Bell 29th December 2015 at 10:32 am - Reply

    Hi John,

    Have you made any further advances with your project?

    Thanks and best regards,

    Will

    • John Efstathiades 5th January 2016 at 3:03 pm - Reply

      Hi Will,

      The short answer is no. I’ve been kept extremely busy with paid customer work so not much time to devote to playing with RPis.

      The slightly longer answer is that we have done a lot of VxWorks driver development work for the Synopsis USB controller (host and device) and some project work that involved VxWorks networking over USB. So plenty of grist for the mill.

      Regards,

      John

  7. David Johnson 25th March 2017 at 5:51 pm - Reply

    Good article, enjoyed the write-up. Considering the size and traditional customer base for VxWorks, it seems like the port to RPI would be a ‘port of personal interest’ rather than a time investment that would be commercially recoverable.

    Has Vxworks been “open-sourced”?

    • John Efstathiades 28th March 2017 at 7:22 am - Reply

      Thanks for taking the time. I agree, it is a port of personal interest.

      VxWorks is not open source, in the sense that the code is freely available. Of course commercial customers do have access to the source.

  8. Attila 23rd April 2017 at 9:11 pm - Reply

    hello John. Great article.I have a Raspiberry pi A+ and Raspi Camera.

    Can we record the video RTOS installed Raspberry pi?is it possible ?

    Best Regards.

Leave A Comment