rtems, gsoc,

RTEMS GSoC 2019 Final Report: Add framebuffer driver for Beaglebone Black

Vijay K. Banerjee (thelunatic) Vijay K. Banerjee (thelunatic) Aug 17, 2019 · 6 mins read
RTEMS GSoC 2019 Final Report: Add framebuffer driver for Beaglebone Black
Share this

A great summer comes to a conclusion now! Here’s the final report of all the coding, debugging and documentation throughout the summer.

Project Overview

The objective of the project was to improve Beaglebone Black (BBB) Board Support Package (BSP) on RTEMS. The BSP is currently well supported by RTEMS but lacks framebuffer drivers. The project is mainly focused on adding the framebuffer driver, this will enable the users to attach a display to their BBB project that uses RTEMS. As the project kept progressing, many things got added to it and the final milestone reached is a graphics library ported to RTEMS and working on BBB target with a connected screen.

Mentors

  • Christian Mauderer
  • Pavel Pisa
  • Udit Kumar Agarwal

Project Objectives

The primary objectives of the project were:

  • Add/Port TDA19988 drivers to RTEMS.
  • Add/Port am335x display drivers to RTEMS.
  • Get a working graphics console or a graphics library using the drivers.

Summary of the work

This section contains the per phase summary of the work done, along with the links to the respective commits.

Phase I

The first phase started with the search for the available drivers with suitable license, that can be ported to RTEMS. The search ended with FreeBSD, which has a good support for framebuffer in our target device, i.e, Beaglebone Black. RTEMS has a framework called RTEMS libbsd which is used to import drivers from FreeBSD which then can be used together with RTEMS. The main challenge was that the drivers use iicbus interface from FreeBSD to communicate with the HDMI framer, but libbsd didn’t have any support for using the i2c bus drivers from RTEMS. In this phase I worked on writing a pseudo driver layer, that works as an adaptation layer to connect the FreeBSD driver API with the RTEMS i2c bus drivers.

The commits are as follows:

  • In this commit I imported the FreeBSD iicbus drivers and ported them here.

  • Then wrote the RTEMS i2c adaptation layer. The idea behind is to write a glue layer in libbsd that will connect the RTEMS driver with the FreeBSD API, this way the libbsd drivers would be able to use the RTEMS I2C drivers and there wouldn’t be a need of a separate driver. The RTEMS one would do the talking with the hardware and the adaptation layer will handle the API calls from libbsd. I wrote a blog post about this layer and it can be referred to for a more detailed discussion.

i2c adaptation layer concept
i2c adaptation layer concept
  • To test the i2c drivers, I have imported and ported the i2c command line tool from FreeBSD. During the time of porting, the i2c lacked a commit which was added to FreeBSD in a commit later than the freebsd-org HEAD, as a result of which the i2c tool doesn’t have the -mtr option, which is needed to read/write anything from the i2c interface. This feature will get added to the i2c tool when the libbsd will be updated to a later version. So after the update, a typical read with i2c tool would look like this…
1
2
SHLL [/] # i2c -a 0x50 -d r -c10 -mtr -w16
aa 55 33 ee 41 33 33 35 42 4e

Phase II

In this phase, I started porting the display and HDMI framer driver from FreeBSD to RTEMS. After working them out in a local branch, I could create a /dev/fb0/ device in RTEMS. The main problem with this was that the driver lacked any read or write function and hence an mmap support was needed to be added in libbsd, which will work as a glue layer and will let the libbsd apps use mmap from RTEMS cpukit. I also wrote some documentations during the process to help the users get a detailed guide for Beaglebone black with RTEMS.

The commits are as follows:

  • The mmap support was added.

  • For the Documentation, I added a Beagle documentation where I described the supported drivers in Beagle BSP and have written instructions on how to get started. I have also written a section in documentation for Device Trees, this will help the users follow a definite guide to use Device Trees with RTEMS.

  • Wrote a test app that writes directly to the fb0 device using memory map.

Phase III

In this phase the drivers were completed, tested and then merged to the master repository. After the merge, RTEMS got the framebuffer support for BBB, tested with sample application that I mentioned below in the list of commits. Then I progressed towards porting a graphics library called littleVGL to RTEMS. For this I wrote bsd fb driver for lvgl, so that it can be pushed upstream and RTEMS can sit on top of it.

The commits are as follows:

  • Added a NOCACHE section in Beagle BSP to allow the libbsd coherent cache heap creation.

  • Imported and ported Pinmux drivers from FreeBSD.

  • Imported and ported TDA19988 drivers from FreeBSD.

  • Imported and ported framebuffer device drivers from FreeBSD.

  • Imported and ported am335x display drivers from FreeBSD.

  • After the successful porting of the drivers I wrote a sample app to print a nice logo on the screen that can be seen in the image below. The app is pushed to my github repo here.

logo on the screen

Future Work

The drivers in their current state are working nicely. Here I jot down a few potential works that can be done in future:

  1. Add a pointer device like mouse and/or touchpad.

  2. Add FDT support in Beagle BSP. This one can become an individual GSoC project itself. There’s a related ticket here.


Weekly progress and status updates


I thank my mentors and all the members of THE RTEMS PROJECT for being such an awesome and supportive community, it was a great summer of challenges, learning and a lot of fun.