Google Summer of Code 2015

This page captures the students who make proposals as well as those who work on projects for RTEMS as part of GSoC 2015.

Students' Proposals

Start filling in this table for yourself as soon as possible and update as needed.

Student	Completed Hello	IRC Handle	Proposal Title	Google Docs URL
NAME	Yes or No	nick on #rtems	Project Title	Link to Google Docs for proposal (shared with mentors)
Sujay Raj	Yes	sujayraaj	Port Monkey HTTP Server	​proposal
Richa Sehgal	Yes	richashi	Run Time Tracing	TBD
Ragunath D	Yes	ragunath	Beagle BSP improvements	​proposal
Andrei Popescu	Yes	andrei_	Condition Variables	​proposal
Hesham ALMatary	Yes	Hesham	Support Rump Kernels on RTEMS	​proposal
Ketul Shah	Yes	ketul	Beagle BSP improvements	​proposal
Yang Qiao	Yes	yangqiao	Raspberry Pi BSP improvements	​Proposal
Yurii Shevtsov	Yes	gtament	Raspberry Pi USB Support	​Proposal
Andre Marques	Yes	asuol	Raspberry Pi Low Level Peripherals and SD Card	​Proposal
Jarielle Catbagan	Yes	jrcatbagan	Beagle BSP improvements: Porting micromonitor to boot w/out U-boot	​Proposal
Anand Krishnan Prakash	Yes	anandkp92	Configuration GUI	​Proposal
Saurabh Gadia	Yes	sgworks	Nested Mutexes	​Proposal
Rohini Kulkarni	Yes	krohini	Raspberry Pi 2 Support	​Proposal
Charith Eranga	Yes	charith	RTEMS Clang Support	TBD
Waleed Ziad	Yes	waleedziad	Raspberry Pi 2 Support	​Proposal
Abdelhamid Amer	Yes	abd_elhamid_	Stack Analysis for RTEMS	​Proposal
Hermann Felbinger	Yes	hermann_19829	Improve Code Coverage Analysis Meeting Aviation and Automotive Standards	​Proposal
Carlos Falgueras	No	fark	Raspberry Pi BSP Peripherals	​Proposal
Gowtham Ashok	Yes	gwty	Merge LEON into RTEMS	​Proposal
VARA PUNIT ASHOKBHAI	Yes	punitvara	Port RTEMS to Intel® Galileo	​proposal
VARA PUNIT ASHOKBHAI	Yes	punitvara	Development of RTEMS Board Support Package for x86_64 Architecture	​proposal

The columns are to be filled in as follows:

• The Student column is for your name.
• The Completed Hello column lets us all know whether or not you completed the require Hello World project. Based upon our experience, students who have successfully compiled and run an RTEMS application have a MUCH MUCH higher chance of success on the proposed project.
• The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on freenode.net.
• The Proposal Title should be self-explanatory.
• The Google Docs URL is your proposal in Google Docs that can be reviewed and commented on by mentors. The ​proposal template should be copied and used as a baseline. This can be shared with mentors for review. Mentors can insert comments for you.

WARNING: The Google Docs version of the proposal is a WORKING copy. You MUST submit the official and final proposal using the Google Melange site. If you do not submit the final proposal via the Google Melange site, you cannot be considered

Students' Summer of Code Tracking Table

Students whose GSoC project is accepted by RTEMS shall fill in a slot with their information in the following table, which helps to centralize SoC Project Management.

Student Name	IRC Handle	Project Link	Repository Link	Blog	Calendar
NAME	nick on #rtems	Link to Project Wiki page	Link to project's public Github repository	Link to your development blog	Link to Calendar with Schedule
Yurii Shevtsov	gtament	​Wiki	​Github	​Blog	​Calendar
Rohini Kulkarni	krohini	​Wiki	​Github	​Blog	​Calendar
Sujay Raj	sujayraaj	​Wiki	​Github	​Blog	TBD
Anand Krishnan Prakash	anandkp92	​wiki	​Github	​Blog	​Calendar
Saurabh Gadia	sgworks	​Wiki	​Rtems_Github ​JPF	​Blog	​Calendar
Andre Marques	asuol	TBD	​Github	​Blog	​Calendar
Jarielle Catbagan	jrcatbagan	​Wiki	​Github	​Blog	​Calendar
Ragunath	ragunath	​wiki	​Github	​Blog	​calendar
Ketul Shah	ketul	​Wiki	​GitHub	​Blog	​Calender
YANG Qiao	yangqiao	​Wiki	​GitHub	​Blog	TBD

The columns are to be filled in as follows:

• The Student column is for your name.
• The IRC Handle column is your handle on IRC. RTEMS folks hang out in #rtems on freenode.net.
• The Project Link is a link to the Wiki page for your project.
• The Repository Link is a link to the github repository for your project.
• The Blog is a link to your blog with entries about your project. It should be updated regularly during the summer.
• The Calendar is a link to your Google Calender with milestones and deliverables identified.

Student Status Updates

Each student has a section below for putting in notes from the weekly IRC meetings.

Gedare

• May 19: Added the Status Updates page, and created this subsection as an example. For next week, I will talk to any students who missed the meeting and follow-up on any problems that were identified.

Andre Marques

• May 19: I have been trying to load code on the PI with openocd through JTAG, and checking the GPIO API, which will be my first task. The first step will be adding locking mechanisms, as that is one of the main features currently missing.

• May 26: Missed the meeting due to a university project presentation. Continued to work with JTAG and openocd. The problem seems to lie in the GPIO pin setup for JTAG, as up until now the pins were only configured for a certain alternate function, but the corresponding pull resistors also need to be adjusted (disabled). At this point I seem to be able to send code to the PI, but cannot execute/debug it.

• June 2: I have been going through the RPI GPIO API, and have added some locks on the interrupt create/disable functions and am currently evaluating the locations where locking may be needed. I have came to the conclusion that is best to define locks on API functions than on a per pin basis.At the same time I am separating the RPI specific code into separate functions, which could in the future be implemented by each BSP using the API to provide the BSP specific implementation as to provide the required GPIO functions. I intend to post this more clearly on my blog this week, and also check ketul's GPIO work on the BB so we can start to coordinate some ideas.

• June 9: This week I have gathered my views on the rtems GPIO API on a blog post and continued to separate the RPI specifics from the generic code. The blog post was announced on the devel-ml yesterday, but I expect it to take a while to have some feedback. At this point the RPI code is almost completely contained on a separate file, and after that I will be adjusting the generic API to reflect the changes mentioned in the blog post regarding API and BSP initilization, and the changes in the interface with an user application.

• June 16: I have completely separated the rpi code from the rtems gpio API, and the features mentioned in the last week's blog post are almost all implemented (just need to take care of some details, such as locking the data structure that keeps the GPIO status. Currently only the interrupt management is being protected by a mutex and vector enable/disable). At this time the core of the GPIO API can leave the rpi bsp to somewhere accessible by all BSPs, and may be used by others, so today and in the next very few days I will be finishing/cleaning up/adding documentation to the code, as well as updating the blog/wiki with a developers/user manual so it can be reviewed. While it is being reviewed I can then start to work on the I2C porting to the new framework.

• June 23: This week I have posted patches for review regarding the RTEMS GPIO API and its rpi implementation. I have also been gathering more references/documentation to help in the I2C porting (by what I have seen only the xilinx bsp currently uses the new I2C framework). At this time I am correcting the issues/suggestions pointed on the GPIO API, and intend to send a new version of the patches tomorrow/thursday. I should have documentation (developer/user manual and/or blog/wiki page) posted this week. The I2C work can start right after, and at this point I am not expecting much trouble, but if it does I will post any problem on the ml regarding the new framework.

• June 30: I have been addressing the issues/suggestions noted on the GPIO API, and am at this point writing my midterm report, which details the current state of the GPIO API. One of the reasons for this delay is a problem with the generic_isr that arised when I changed the pin state data structure, which for some reason causes a crash for no aparent reason when the application uses interrupts (e.g.: just adding a new field to the struct causes a crash when the rtems interrupt handler is called). For now I have put a dummy rtems_chain_control which is not needed, but by having it there I can continue the work, so until now I have ignored it but in the next days I will have to address it.

• July 7: Updated the GPIO API to include pin groupings, allowing to write and read byte data to a series of pins which behave as a single entity. Added support for 'parallel' GPIO pin function assignment, allowing the function assignment to be set for multiple pins in a single GPIO hardware call. If a BSP does not support this feature it becomes a sequence of individual calls per pin.

• July 14: I have added to the GPIO API support for pin groupings and multi-pin operations. These are useful to operate on a GPIO pin group as a if it was a single entity (i.e.: can be useful to emulate/bit-bang interfaces using GPIO pins), and also allow for fewer hardware calls. I also updated the existing data structures to optimize the memory requirements. The current state and description of the API is currently in my blog (which I have updated just a few hours ago). I have tested all the features with the Pi, and am now updating the existing API test cases. At this point the API is almost ready for another round of code review.

• July 21: Corrected some bugs with GPIO multi select and group functions. Added GPIO multi read function, and changed pin state structure to an uni-dimensional array instead of a dynamic matrix. Updated pin release functions.

• July 28: Yesterday I have posted in the devel ml the v2 of the GPIO patch set for RTEMS and the Pi. In the meantime I have an initial port of my I2C Pi code to the linux I2C framework, which I am testing and ironing out some issues. I say initial port because the new API allows for a number of small features that libi2c did not have such as the mangling functionality (i.e.: ignoring acknowledgement for certain messages), sending multiple messages (each may include several data packets) without start conditions in between and such. The device driver I have for my I2C testing device has also been ported to use the new framework's device API so the work can be tested. SPI is mainly waiting for the GPIO to get in, and I hope to have a go at the SD card during the weekend.

• August 4: The Pi I2C bus driver is working with the linux framework, and the SPI code cleaning is almost done. Regarding the SD card the plan is to use the rtems-libbsd SD/MMC driver for the SD/MMC stack, and interface it with the Pi EMMC module to have access to the SD card. The interfacing with the EMMC module will be based on the work I did previously at the university.

Anand Krishnan Prakash

• May 19: I've looked at wxpython which I will be using to make the GUI and I'm still looking into how waf works (need to figure out how much I need to know about waf for this project). I've made a draft version of how the gui would look and now I plan to incorporate changes suggested by my mentors and also think of how the user will start/stop the GUI.

• May 26: New version of gui made based on suggestions from mentors. For this week, I will look up how to go about grouping the configuration options. ​This would help in that. Also plan to start coding for the same.

• June 2: A basic set of groups has been made and each group is associated with a tag. I'll populate the options with the most appropriate tag/group (currently left blank) and will verify it with my mentors.

• June 9: The options have been populated completely. Right now with this tentative list, we will enable each option to belong to one or more than one group. MVC Concept would be used to build the GUI. The GUI would produce the "config.cfg" file which is produced after we run the "waf config" command.

• June 16: This week, I compiled the waf version and got to see what the output of the gui is supposed to be - creating the config.cfg file which is later used for waf configure. Started work on the gui. The outlay of menus are done and can be found ​here. This week I plan to include tabs and other panels and complete the 'looks' of the gui. Currently Amar is creating functions that gets/sets the options. Once we both are done with our individual parts, I will incorporate the gui with these functions (in the event handlers) to get the expected version of the gui.

• June 23: The 'looks' of the GUI is ready. Using functions Amar has coded, I am able to fetch all the options. Now working on creating Panels for displaying just the Boolean options. Will incorporate this into the GUI once it is done.

• June 30: GUI supports Boolean and Integer options with event handlers for Reset Button and the specific radio buttons/spin controls. Next will be to include String and StringList? options. Also will change the tabs to be based on groups and not types.

• July 14: I have implemented GUI panels for String type options and am working on creating a smoother flow of the code and reducing the number of classes. Also working on suggestions that Thomas has provided regarding better documentation and my code.

• July 28: So currently when the user opens the GUI, he will be able to choose which BSPs he wants to configure for. After that I've coded, using existing functions to get only the required parameters for those bsps - they are currently being displayed. Now I'm able to get the value from the gui. Working on updating the configuration with it.

• August 4: This week, I've taken the options from the gui and am able to update on to the config.cfg file. However, I'm stuck with updating the BSP specific options and my mentors are going to look into it today and help me out. Now what essentially remains is run waf configure and waf build using the created config.cfg file. Then the task of translating the GUI and creating such a gui for user options also remain.

• August 11: I have included event handlers for remaining menu items. Currently working on suggestions Thomas had given to run waf build from the gui itself. Currently the config.cfg file is created and works fine when you run waf config and waf build from the command line. Still working on translating the gui.

Saurabh Gadia

• May 19: 1. verify and freeze the proposed solution 2. Set up the essential environment. 3. Set up the blog having design docs. 4. Start working on suggested formal method of validation

• May 26: Tasks accomplished last week: 1. Finalizing the design for "nested mutex" problem. 2. Creating formal documentation for the proposed solution. 3. modelling the test cases 4. Setting up the configuration environment. - Task for this week: 1. evaluate which test case is failing in testsuite(sptest) 2. Code the solution for sparc platform. 3. Validate whether the algorithm solves the problem. 4 Then move on to formal validation process as time permits. 5. Documentation on rtems wiki.

• June 2: [Accomplishments]: Proposed solution with ppt which can be found in wiki section. working on the revised changes made to thread priority related code by sebastian. [Next Task]: Fix the master branch for compiling strict_order mutex configuration. Discuss the scope of JPF relating to this project. Setting up the JPF environment as means for validating the design and proposed solution.

• June 9: 1. Complete the setup of JPF. 2. Re-write the test case spsem02 3. Understanding the working of JPF. 4. Work on how to emulate the behavior of nested mutex in JPF. 5. Have detailed discussion with Cyrille about further process in JPF and set the milestones accordingly.

• June 16: 1. Complete the JPF coding for discussed lock-model which emulates RTEMS behavior. 2. Complete the unfinished task of confusion regarding the spsem02 test case. Get code reviewed by Cyrille for JPF and then discuss further required improvements or test scenarios.

• June 23: 1.Test the code for corrected model. 2. Implement the review changes suggested by guides. 3. Try adding properties to JPF. 4. Prepare the mid-term evaluation materials.

• June 30: 1. Creation and Testing of spsem03 test case suggested by Sebastian. 2. Modify the JPF to remove big lock 3. With big locks try to test under different combination of threads and locks using Verify() 4. Annotating JPF-Code

• July 7: 1. Debugging a test case which is failing the model. 2. Commenting the code in comparison with RTEMS code and Annotating. 3. Model Trace Summary. 4. JPF Verify method checking which will be the final sanity test that assures 100% completeness of model and algorithm inclusive of external locking.

• July 14: 1. Global lock free solution proposed and implemented. 2. Generating important testing combinations for thread-id, mutex-id, priority, etc.

• July 21: 1. Working on further optimization on global lock free solution to avoid unnecessary locking. 2. Justification of each locks used in solution. 3. Lock Graph.

• July 28: 1. Global-lock free was not passing all the good test cases. So modelling and implementing new solution for SMP architecture.

• Aug 03: 1. Implemented global lock free solution for SMP. 2. All test cases are passing for SMP arch. 3. Need next steps for implementation in legacy RTEMS code.

Rohini Kulkarni

• May 19: Functional Pi 2. Have run benchmarks. I have been referring to TRMs for details. For next week, its completely identifying cache configurations and testing. Resolve issue faced with respect to scu implementation.

• May 26: Looks like cache/mmu setup has been identified, except enabling maintenance operations. Start implementation and subsequent testing. Resolved SCU related issue. Started work with bsp hooks, first with hook 0. Identify common code with existing cortex-A9.

• June 2: Tested identified cache configurations. Performance is not as expected. For next week complete cache/mmu configuration.

• June 9: Follow up to improve cache/mmu configurations. Started work on SMP. Understand mailboxes and smp implementation with mailboxes. I aim to start implementation for the same this week.

• June 16: Understood use of mailbox for SMP and started implementation. Achieve significant progress in terms of SMP implementation in the coming week.

• June 23: Went back to cache/mmu issue. Obtained significant improvement in cache performance towards the end of the week. However the mmu_config_table for raspberry does not use the default sections for arm v7. The text section has a write permission also. The reason behind this needs to be understood. Did not go much ahead with SMP in the week.

• July 28: Identified bug in cache configuration which was causing the .text section in raspberry pi map to require write permissions. One task is to submit a patch for this bug. The kernel image starts up with SMP changes. The other task is to add interprocessor interrupt for the Pi 2 SMP.

• Aug 4: There was some build problem and changes were not being incorporated. I wanted to confirm that missing IPI is the problem. But the build problem was misleading so took almost the week before I was able to get sure of the problem. Next I have to see how IPI can be implemented because RPi2 does not have a GIC. Also I have moved ahead with the text section permissions issue. I could get hold of where the start up hangs though the root of the problem is yet to be identified.

Yurii Shevtsov

• May 19: I managed all compilatoin problems. So build environment is ready. Right now I'm studying libbsd, also there are few moments, concerning libbsd usage left unclear. Oh, I also have to do "paper work", like establishing blog, wikipage.

• May 26: I pulled FreeBSD driver for the bcm's USB port (DWC OTG) to my libbsd fork. I'm going to port it during this week. I hope it will be able at least to enumerate devices (hub and phy).

• May 33: I started porting DWC OTG driver. Now it compiles. Also I discovered I need some mailbox methods, which, as I understood, are YANG's task. He said he will finish it till this weekend. (The actual discussion is on devel). But I'm planning to try driver without those procs. So I'm working on testing app.

Ragunath

• May 19: First task is adding networking support. For this I will be porting ethernet driver from FreeBSD to rtems-libbsd. I have been studying some already ported drivers from FreeBSD to rtems-libbsd. Current progress,I pulled the driver from Freebsd and compiled it with the latest rtems-libbsd. Next target is to code all the rtems specific changes needed and check with the mentors whether that is sufficient.Then try to solve any issues that arises.

• May 26: Added the driver to nexus files to get linked with the application as a child of nexus device.Then I defined the resource structure that defines bus handles and interrupt initialization. BBB uses SMC LAN8710A PHY. That phy driver is also ported from FreeBSD. Fixed some fdt, sysctl related changes. Now we are able to read mac address from the device. Facing a hang issue when link goes up. Currently debugging it.

• June 2: Found the root cause for the hang issue. The issue is due to rx interrupt getting enabled before it is serviced. I put a temp hack fix and proceeded. I am able to go to the shell and execute commands. ifconfig of the interface works. irq's are established. Next week I will be working on the packet processing side.

• June 9: I worked on packet processing this week. We are able to receive the packets and it is moved up the network stack successfully. Transmission of packets have an issue. The network stack generates packets and it reaches the driver. But the packet is not received on the external side. The stats registers shows that the packets are transferred properly. There are no crc, overrun errors. I also checked for connectivity errors using ethtool and that too was inline with wor