Changes between Version 2 and Version 3 of GSoC/2015/Final_Report

Timestamp:

10/07/15 16:03:38 (9 years ago)

Author:

Joel Sherrill

Comment:

Second attempt to convert HTML markup to Wiki markup

GSoC/2015/Final_Report

@@ -6 +6 @@
 
 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. <strong> Grouping related, independent projects together with team mentorship and group collaboration was successful beyond our expectations.</strong> 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 <a href="https://devel.rtems.org/wiki/GSoC/2015">a Wiki page in our Trac dedicated to GSoC 2015</a>. 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 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.
@@ -63 +63 @@
 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 <a href="https://devel.rtems.org/wiki/GSoC/2015/RaspberryPi_peripherals_and_SD_card">project wiki page</a>.
+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 ==
@@ -97 +97 @@
 
 == Saurabh Gadia: Nested Mutexes ==
-This project highlights the priority inversion problem caused in RTEMS kernel (<a href="https://devel.rtems.org/ticket/2124">issue ticket</a>). 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 (<a href="http://babelfish.arc.nasa.gov/trac/jpf/wiki">JPF</a>) , 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.
+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 ==