Beagleboard BSP projects

Mentors: Ben Gras, ...

Status: Initial ideas page.


RTEMS has a BSP that supports beagleboard, beagleboard xm, beaglebone (original, white) and beaglebone black targets. The BSP is in RTEMS mainline.

Getting started as a GSOC student

If you are interested in working on this BSP as a GSOC project, there are a few basics you should do immediately, if possible before even asking about the project, to show that you are up to speed with the basics of running RTEMS and this BSP in particular.

You'll need the hardware

To test your changes, you will need the relevant hardware. You will also need a way to see the RTEMS serial console i/o. So, you will need one of the following, in descending order of advisability if you have the freedom to choose a model:

  • Beaglebone ("white") - this board has everything self-contained (power, jtag and serial over a single usb cable) so is the ideal board to buy if you have to choose
  • Beaglebone black - this will need a TTL-serial to USB converter cable, e.g. USB-TTL FTDI Cable 3.3V, and jtag is harder to access so quite limiting compared to the white. RTEMS does not implement a USB device, so you can't use a generic usb cable for console i/o.
  • Beagleboard XM + serial cable (serial to usb is most convenient - the ones with the FTDI chip work well)
  • Beagleboard + serial cable

Also build the emulator

There is a Beagleboard XM emulator. Run the BSP in that for

  • fast iteration, convenient debugging
  • testing whether your changes might break the xm and/or the emulator

Build & run the BSP

Build & run the BSP (e.g. using the test set) on whatever you hardware you have and on the bbxm emulator.

See this blog post for full instructions in building & running the bsp on hardware and in the emulator.

Make a change in RTEMS

To show that you're up to speed with rebuilding RTEMS, make a change. Showing the result must be part of your proposal.

Hello World project

The official requirement is a Hello World project.

Raising the bar

Run the test set and debug any of the failing tests, either on the emulator or on real hardware. One thing to keep in mind is that a failing test on the emulator could be an imperfection of the emulator.

Ideas to Improve the BSP

The hardware support is rudimentary. This section lists ideas for improvement of that BSP.

They are listed in no particular order. The biggest factor is motivation - are you excited to take on the task?

Booting without uboot

The BSP needs some sort of bootloader to get the app loaded. Currently the system to do all the work for the user uses uboot. GPL3 is a problem and so a BSD-licensed alternative to do the same thing would be better.

Upstreaming RSB & rtems-tools changes

The BSP itself is neatly upstreamed to mainline. There are some changes in rtems-tools and the RSB that are not neatly in mainline and that is needed. Coordination with Chris Johns is needed here.

Peripheral support

There are quite a few missing peripherals. In no particular order

  • PRU - programmable realtime units, interesting realtime applications
  • I2C
  • ADC
  • Framebuffer
  • USB
  • Ethernet
  • GPIO
  • CAN
  • MMC (internal flash & sdcard)

Fix failing tests & automatically run tests on future commits

On Qemu, most tests pass but not all. On the hardware (running using JTAG), most tests pass but not all. The reason for them to fail should be figured out (might be a qemu limitation in the 1st case). Once the tests are nailed down, coordination with Amar would be good to run these tests automatically in the qemu linaro so future commits won't break the BSP (or at least, it will be flagged immediately).

Even better would be to run these tests on hardware automatically of course, using JTAG. Coordination with Amar/OAR might enable this.

Last modified on Mar 12, 2015 at 7:08:33 PM Last modified on Mar 12, 2015, 7:08:33 PM