= Google Summer of Code 2015 Final Report = [[TOC(GSoC/2015/Final_Report , depth=2)]] This summer the RTEMS Project had 10 excellent students participate in the Google Summer of Code Program (GSoC). All of the students were new to RTEMS. We also had three outstanding new mentors: Ben Gras and Cyrille Artho, who are veteran mentors from other projects, and Ed Sutter, who is new to GSoC but a long-time contributor to open-source. Student projects once again spanned the range of RTEMS: low-level embedded systems work with pins, ports, and protocols; kernel hacking backed-up by formal methods; networking support; video and graphics; application porting; and GUI development for improving the configuration and compilation of RTEMS. ref Due to widespread student interest, 7 of our 10 projects were in two categories targeting the Raspberry !Pi/Pi2 and !BeagleBoard Black (BBB) embedded systems platforms, respectively. We carefully divided the labor in these projects to avoid inter-dependency, overlapped the mentors in each category, and strongly encouraged the students to interact and collaborate. Additionally, some of the projects in both boards work with the same subsystem in RTEMS and thus were inter-related. '''Grouping related, independent projects together with team mentorship and group collaboration was successful beyond our expectations.''' The students were able to help each other overcome similar problems, and the mentoring time was less than if all projects were only loosely related, as in the past. Of special note, Ragu Nath, working with the BBB, was able to help out Yurii Shevtsov when he was stuck for a long time on a problem that his mentors were unable to resolve. In preparing for this year’s GSoС, we decided to continue our past tradition of weekly “all-hands” meetings. Student progress, next steps, goals, and problems were discussed in an IRC meeting moderated by Gedare Bloom and Joel Sherrill, two of the RTEMS Organization Administrators. These meetings have continued to be vital for engaging students and defusing problems before they explode. This year students had to post summaries of their status updates on [https://devel.rtems.org/wiki/GSoC/2015 a Wiki page in our Trac dedicated to GSoC 2015]. The same page includes a table with project-related links for each student. The consolidated status updates and project links has made monitoring students easier, and should prove useful for posterity and the next generation of RTEMS developers. In the following sections, each student has summarized their individual projects. == Jarielle Catbagan: Beagle BSP improvements: Porting MicroMonitor to boot without U-boot == The main goal of this project was to port MicroMonitor, otherwise known as uMon, to the Beaglebone Black as a first step towards providing an alternative bootloader to U-Boot. The motivation behind this effort was to alleviate the limitations and restrictions that were imposed by U-Boot on the user and developer that are otherwise non-existent in uMon. Among the plethora of benefits of such a bootloader is the flexibility provided to users in using an embedded system for any purpose and application, It is this aspect that makes uMon an optimal choice as a bootloader to be deployed among embedded systems. The major accomplishments that were achieved in the Beaglebone Black uMon port as a result of GSoC are initializing and configuring the external DDR3 RAM for normal operation, initializing and configuring the UART exposed on the pin header on top of the board, implementing the interface to an arbitrary uSD card, and implementing the interface to the onboard eMMC. The inherent benefit of having the DDR3 at uMon’s disposal is removing the dependence on the limited internal SRAM found on the AM335x SoC which provides the ability to transfer large application images into RAM. As for the interface to a uSD card and the onboard eMMC, the uMon image as well as application images can be stored and booted from these non-volatile memories which removes the dependence of transferring either uMon or an application image serially via UART. Furthermore, providing uMon on the Beaglebone Black the ability to interface with either a uSD card or the onboard eMMC results in the convenience of retrieving images. Despite the completion of GSoC, there are numerous improvements and additions that need to be made in order to have a usable and robust uMon bootloader on the Beaglebone Black. As a result, I look forward to continue my involvement with uMon and RTEMS. The major tasks that I am planning to work on the Beaglebone Black uMon port well beyond GSoC are implementing the Ethernet functionality and implementing the mechanisms to perform either a TFS or TFS-less boot of an application image. == Ketul Shah: Beagleboard BSP Improvement == The main goal of this project was to design and implement the different device drivers for !BeagleBone Black running RTEMS. The project mainly proposed for major three drivers that are General Purpose !Input/Output (GPIO) , Analog to Digital Converter (ADC) and Inter-Integrated Circuit (I2C). These drivers could make RTEMS a great platform for interfacing different sensors and actuators on Beaglebone Black, a popular and cheap single chip computer. As a GSoC results the major accomplishments we are able to achieve are GPIO and ADC driver, working on hardware. And we are happy to announce that GPIO driver implementation has been merged with mainline that supports !BeagleBone Black and White. With that we could be able to improve Generic GPIO layer. For I2C code it requires more debugging and testing on the hardware. In this project the student learned carefully reading the TRM for the AM335x SOC (BBB & BBW SOC), learning to program the hardware, implementing this in the bsp, and writing a test app for it. The GPIO implementation was done in parallel with the Raspberry Pi BSP. A nontrivial part of this GSOC was coordinating with the Raspberry Pi effort toward not only a single GPIO API for 2 different BSP’s, but also shared C code for the BSP-generic GPIO layer. Some remaining work is ADC driver improvements, I2C working on hardware and able to interface numerous sensors and testing of them, and some GPIO features. Next would be to develop one of the important drivers Pulse Width Modulation (PWM). Finally, I am actively looking forward to work with RTEMS beyond GSoC with planning to complete ADC and I2C driver improvement and getting started with PWM. == Ragunath D: Beagleboard BSP Improvements == The aim was to improve peripheral support for Beagle BSP in RTEMS. 1. Even before GSOC started, a driver for the BBB RTC (realtime clock) was added and merged with RTEMS mainline. With this, there is no need to set the time everytime we reboot the machine. 2. The main thing I wanted to add is networking support for RTEMS. For this rtems-libbsd stack was chosen. I ported the ethernet driver for BBB from FreeBSD. There were a few issues for which some work-arounds were identified. Now networking is present for Beagle BSP in RTEMS. All the tests for libbsd passed successfully. With this networking support, the BSP is greatly enhanced, opening it for a new range of applications. 3. Next big thing I planned is to integrate lwIP TCP/IP stack port with RTEMS. The approach was to compile the stack as a separate library so that the users have the choice to choose the TCP/IP stack of their choice. Another design choice we identified was, lwIP TCP/IP stack is to be separated from the bsp so that the stack is independent of the BSP. The bsp related drivers will be compiled as a separate library. The lwIP stack is separated and now can be built using RTEMS Source Builder. The stack is common for all BSP's. So now we can build the stack for any BSP. Currently the Beagle BSP has a driver ported to RTEMS. With the Beagle BSP, I compiled the stack, the driver and then built the application. Now the lwIP app successfully runs on the BBB. With this BBB has networking support added and users have the option to choose the TCP/IP stack. Although there is one open issue, where the cache has to be disabled for networking to work for both the stacks. 4. I also documented the work done in my blog providing explanatory details to the users. I also mentioned adding GPIO & i2c support in my proposal. Since Ketul was also working on the same, I spent some time on debugging the cache issue. I understand ketul has done GPIO related stuff. I also remember him saying something about i2c. I intend to do the i2c part if it is not yet done yet. == Andre Marques: Raspberry Pi Low Level Peripherals and SD Card == My project has provided RTEMS with a generic GPIO API and gave support for Raspberry Pi GPIO, I2C and SPI peripherals, while giving some good head start on the SD card support. Probably all hardware platforms supported by RTEMS have GPIO hardware, which is one of the first peripherals to get supported by a new BSP. Although it is a very basic one, GPIO hardware can be programmed to do much more than simple digital I/O, and while most existing GPIO drivers are similar in their implementations they are unique to their platform. This leads to a lot of code doing the same in different ways for different platforms, and this is where the GPIO API shines. Instead of writing a complete GPIO driver for their platform, a BSP developer can just provide the API with the code to perform the platform specific operations on a pin (i.e.: selecting a pin, disabling a pull-up resistor, ...) and the API takes care of the orchestration such as operation validation (i.e.: noticing that an application is writing to an input pin), locking/synchronization as well as providing some high level functions such as pin groupings and group operations (treating a group of pins as a single entity) and switch debouncing, while still being able to perform some register access optimizations. The GPIO API is already in the RTEMS tree in use by both the raspberry and beagle BSPs. During this summer I have also added support for the I2C bus on the Pi using the new I2C API (the second hardware platform to support it in RTEMS at this point) and also to the SPI bus. As for the SD card, RTEMS provides a port from freebsd of the SDHCI and MMC/SD bus drivers, which are useful to the PI as the host controller used conforms to the same standard (with a few quirks). Currently both the host and the card are recognized, but the SDHCI controller is not catching the cards response to commands. This implies installing the SDHCI interrupt handler to maybe one of the GPIO interrupt vectors (the host controller is connected to GPIO pins internally on the Pi), so SD card support should not be far away. More details about the project can be found in the [https://devel.rtems.org/wiki/GSoC/2015/RaspberryPi_peripherals_and_SD_card project wiki page]. == Rohini Kulkarni: Raspberry Pi 2 Support == The project I took up was aimed at improving BSP level support to the Raspberry Pi 2. The main goal was to start RTEMS symmetric multiprocessing (SMP) with the four cores. Another important issue of fixing the cache performance on Pi 2 was also taken up. Improving cache performance dealt mostly with understanding the ARM v6/v7 architectures and RTEMS MMU setup. In due course, I found that the cache performance on Pi 1 was also lower than expected. The solution greatly improved cache performances on both the variants. The dhrystone benchmark was used for assessing performance. It was interesting when the solution ended up bringing another issue to light! This issue is regarding the text section in Raspberry Pi memory map requiring write permission. I took up figuring out the cause of this issue too, during the project. The cause has been found and solution is being discussed. On the SMP front, multiprocessing has not started yet. But progress has certainly been made. The aspect of applying RTEMS SMP bring up process to Pi 2 has been understood and implemented. The standard RTEMS SMP functions have been added. SMP could not start because Interprocessor interrupts were absent. In this respect, code for registering the mailbox interrupt remains to be added. Once this is added all four cores should be active. RTEMS support for Pi 2 is quite recent. The BSP for Pi 2 has to be further improved to include support for peripherals. There are similarities in hardware with Pi 1. As such, the changes required to extend existing Raspberry Pi support to Pi 2 have to be considered. A blog made as part of GSoC captures the details of all that I did under this project. I look towards continuing the undertaken work and contributing to RTEMS post GSoC. == Yurii Shevtsov: Raspberry Pi USB support == The main goal of my project was to bring USB support to RPi BSP. I had to work with libbsd, which provides USB stack, ported from FreeBSD. Which means, I can port ready drivers from FreeBSD. Since I'm the first, who working on this project, I had to start from scratch. At first I needed RPi's USB controller to work, which is DWC OTG. Controller's driver also requires mailbox support, which is implemented by YANG QIAO. We cooperated to test and debug it. Unfortunately, because of error, this is all I had time to finish. So, I'm going to continue my work on this project. The error was in the absence of one #include line of code. And it took a month to find it. All my work, achievements and fails, useful tips and advices I documented in my own GSoC 2015 blog. == Yang Qiao: Raspberry Pi Framebuffer and HDMI Video Support == The main goal of this project is to implement framebuffer driver for HDMI video output, basic graphic text console and port the graphic libraries which was managed by rtems-graphic-tool-kits into rtems-source-builder which would simplify the process of building add-on graphic libraries. The implementation of framebuffer driver and the graphic text console can be divided into several steps. 1.mailbox. Mailbox is an interface for the communication between cpu(arm) and gpu(videocore). With the mailbox's read/write functions, we can send formated data structures to a given mailbox channel in order to get hardware informations or configuer hardware. 2.videocore property tags. The channel 8 of mailbox 0 is reserved for property tags of videocore. A tag data structure is used for every different property such as board model, power status, allocate memory etc. 3.kernel command line support. For the moment, the kernel command line support implementation uses a videocore property tag to query the command line passed by the first-stage boot to the kernel. For a long term and more generic support, we would prefer to implement the ATAG parser and devicetree parser in the future. 4.framebuffer driver. The framebuffer driver uses videocore property tags to detect the display size, configuer the hardware and allocate a framebuffer for graphic output. Since the cpu and gpu share the same memory, the limitation of working area will also be well tuned. We can also pass the resolution by kernel command line to choose a different resolution than the display size. 5.character output and framebuffer text console. The character drawing algorithm is the same as in bsp pc386 except for the implementation of drawing a character. A 16*8 bitmap ASCII font file is used and esc sequences are handled by a trival state machine. We can choose between serial console and framebuffer graphic console by kernel command line and all output will be redirected to display if a HDMI device is present and fbcons is choosed. Previously, graphic libraries are built by a set of script in project rtems-graphic-tool-kits. Now I've moved all of them into rtems-source-builder so that we can build these graphic add-on packages as simply as building a bset. == Saurabh Gadia: Nested Mutexes == This project highlights the priority inversion problem caused in RTEMS kernel ([https://devel.rtems.org/ticket/2124">issue ticket]). Priority inversion issue exists for strict order mutex class with priority inheritance discipline in RTEMS. We modelled the legacy rtems thread-lock implementation (restricted to project) under Java Pathfinder ([http://babelfish.arc.nasa.gov/trac/jpf/wiki JPF]) , a Java platform for bytecode verification, to validate our proposal. In JPF, we were able to reproduce the priority inversion problem. We propose and implement an efficient solution with worst case linear time complexity(acquired mutex) and with no modification in existing RTEMS data structure. We have developed variety of solution based on target architecture of RTEMS eg. Uniprocessor and SMP. Each solution is self sufficient to run on all architecture, but to have clean and efficient solution we came up with different solution based on architecture. We developed a validate routine which traverses all the mutex acquired by a thread which with the help of assertion checks confirms whether there exists any priority inversion problem in system. To further strengthen our JPF model, we generated test cases having different combination of thread-priority-mutex configuration and showcase the sanity of system by successfully passing all the test cases. Finally, we correlate and transform the java solution model to legacy RTEMS code. This way we demonstrate a new methodology for developing and verifying old/new rtems code under JPF and implementing back the solution to RTEMS code. == Sujay Raj: Porting Monkey HTTP server to RTEMS == The main goal of this project was to port the Monkey HTTP server and development stack to RTEMS. RTEMS initially used mongoose web server as its default but because of conflicting licensing issues were forced to search for a different browser. Monkey not only offers a binary web server but also a development stack by which users can integrate a web server in their application using RTEMS. == Anand Krishnan Prakash: Configuration GUI == The main goal of the project is to create a GUI for configuring the waf build of RTEMS. Choose the required BSP(s), modify the general and BSP specific options and then create the config.cfg file. Amar, Thomas and Chris were my mentors and I used wxPython in this project. The implementation happened through multiple steps: * Started off with creating a draft of the gui and asking my mentors for suggestions and recommendations. Based on the feedback, I had modified the initial draft and sent a new one which was satisfactory and I was advised to start working on it. * Created the basic layout of the gui initially - added menus and menu items with event handlers. Created multilayered tab set - to display the options in an organized manner. Also added each option to a group - for displaying in tabs - general, build, network and storage. * Using functions written by Amar, I was able to get the options and used general Panels to display it. Later I created option-type (!Boolean/Integer/String/StringList) specific panels (!True/False radio button for Boolean, Text box for String) with a reset button, enabling users to edit the values. * Created a starting Panel to choose the BSP(s). Passed the chosen bsps to the next panel and only required options are displayed. The options are displayed on tabs - general, host, bsp, [main architecture] and [specific bsp] and each further having multiple tabs based on the groups those options belong to. eg: The bsp arm/beagleboneblack would give the following top tabs: general, host, bsp, arm, arm/beagleboneblack. * Obtained values from the gui for the displayed options and using some existing functions in !BuildConfig() I was able to update these values and create a config.cfg file in the parent and main waf folder (containing wscript file). Now the users can configure rtems via the gui and run waf configure and waf build from command line for building with the new options. * Then I started work on additional features - running waf configure, waf build and other waf targets from the gui itself. I added a output console (a new frame) to the gui in order to display the outputs of these commands. There is some remaining work in the gui: simultaneously display the stdout and stderr logs onto the console, save/load feature and translation of the gui to some other language. I will continue to work on these and complete the project. [https://aroadtocode.wordpress.com/ This] is the link to my gsoc blog and this is the [https://github.com/anandkp92/waf link] to my github repository.