Changes between Version 8 and Version 9 of GSoC/2009/Wrapup


Ignore:
Timestamp:
11/30/14 07:17:09 (9 years ago)
Author:
Chris Johns
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GSoC/2009/Wrapup

    v8 v9  
    2020[[Image(RTEMS_Skyeye.jpg)]]
    2121
    22 Aanjhan's project was to provide a generic interface for RTEMS applications to use the Memory Management Hardware Unit available in most recent embedded processors for memory protection. Initial prototype with a basic proof-of-concept for the PowerPC architecture and PSIM board support package is now available. Major tasks of the project included studying the PowerPC MMU hardware architecture implementation and behavior, propose a multi-level API design within the scope of RTEMS infrastructure. prototype and test on a board support package. Most of the above tasks have been accomplished successfully and tested, but a lot of scope for further work exists. Some planned enhancements are to enable cache control by the MMU, task based MMU context behavior feasibility and implementation, optimizing the code for real time performance to mention a few. Also the implementation needs to be tested on real hardware to verify and validate the work. Currently, the above work is not integrated into the RTEMS main source tree and getting this done is the next primary goal with the work needed to get this done in progress. His detailed project report can be found at http://code.google.com/p/rtems-mmu-support/wiki/GSoCFinalReport.  Aanjhan also helped setup a IRC Logger for the #rtems channel on FreeNode. He blogs at http://blog.tuxmaniac.com
     22Aanjhan's project was to provide a generic interface for RTEMS applications to use the Memory Management Hardware Unit available in most recent embedded processors for memory protection. Initial prototype with a basic proof-of-concept for the PowerPC architecture and PSIM board support package is now available. Major tasks of the project included studying the PowerPC MMU hardware architecture implementation and behavior, propose a multi-level API design within the scope of RTEMS infrastructure. prototype and test on a board support package. Most of the above tasks have been accomplished successfully and tested, but a lot of scope for further work exists. Some planned enhancements are to enable cache control by the MMU, task based MMU context behavior feasibility and implementation, optimizing the code for real time performance to mention a few. Also the implementation needs to be tested on real hardware to verify and validate the work. Currently, the above work is not integrated into the RTEMS main source tree and getting this done is the next primary goal with the work needed to get this done in progress. His detailed project report can be found at http://code.google.com/p/rtems-mmu-support/wiki/GSoCFinalReport.  Aanjhan also helped setup a IRC Logger for the #rtems channel on !FreeNode. He blogs at http://blog.tuxmaniac.com
    2323
    2424Josh Switnick had a project which suffered from those unexpected "challenges" that make software development interesting. His project was to port RTEMS to the 8-bit AVR. RTEMS had previously only been ported to 16 and 32 bit architectures. We worked with Josh to produce a cross-toolset built with AVR specific libc support ported from AVR-LIBC (http://www.nongnu.org/avr-libc/) to newlib (http://sourceware.org/newlib/) and to build the free AVR simulator simulavrxx (http://savannah.nongnu.org/projects/simulavr/). Due to the interesting manner in which the AVR uses 16-bits to access 128K of memory, the context switch code proved to be very difficult to get right.  Also, even though the smallest statically linked executables were less than 20K, many of the existing RTEMS tests cannot fit into the 128K address space of the largest AVR CPU model. Josh produced a working port and is continuing to work to tidy up the loose ends.
     
    2626[[Image(RTEMS_Trace.png)]]
    2727
    28 Lucian Cocan's project was to continue the 2008 GSoC project of Real-Time trace. The 2008 GSoC project had resolved a number of the low level technical issues needed to make a successful real-time trace component for RTEMS. Lucian's initial work was to package the work into something that is suitable for a user. This required a number of factors to be brought together in a way that provided flexibility for the user yet hid the complexity of what was happening. Lucian also had to learn Python, the language used to implement the host tool. The tool was modelled on the command line tool, libtool, as it provided a simple yet consistent interface for the user. Libtool also had to deal with a number of similar issues, that is managing and interfacing to user code in libraries or at the object file level. The other aspect of the development of the tool was to create a configuration data format that allowed the RTEMS APIs to be traced, yet could be extended to allow tracing of third party libraries and user code. The final phase of the project took the tool and various sample programs and traced them. This required modification of the RTEMS capture engine code and the addition of commands. Lucian successfully produced traces for a number of the sample programs plus the example priority inheritance capture engine example. Lucian is still working to get the code in RTEMS and to provide documentation (the current documentation can be found at http://wiki.rtems.org/wiki/index.php/RTEMS_Trace_Tool).
     28Lucian Cocan's project was to continue the 2008 GSoC project of Real-Time trace. The 2008 GSoC project had resolved a number of the low level technical issues needed to make a successful real-time trace component for RTEMS. Lucian's initial work was to package the work into something that is suitable for a user. This required a number of factors to be brought together in a way that provided flexibility for the user yet hid the complexity of what was happening. Lucian also had to learn Python, the language used to implement the host tool. The tool was modelled on the command line tool, libtool, as it provided a simple yet consistent interface for the user. Libtool also had to deal with a number of similar issues, that is managing and interfacing to user code in libraries or at the object file level. The other aspect of the development of the tool was to create a configuration data format that allowed the RTEMS APIs to be traced, yet could be extended to allow tracing of third party libraries and user code. The final phase of the project took the tool and various sample programs and traced them. This required modification of the RTEMS capture engine code and the addition of commands. Lucian successfully produced traces for a number of the sample programs plus the example priority inheritance capture engine example. Lucian is still working to get the code in RTEMS and to provide documentation (the current documentation can be found [wiki:Projects/TraceTool here]).
    2929
    3030