The main page is at SummerOfCode2014.

Template

All the the project descriptions should follow the following template.


Title of the project

  • Description of the project: At least 8-10 lines describing the project. It is essential to have a good description of your project idea if you want to attract good student applications. You should have enough information here to guide a prospective student when they're deciding whether to work on your project or not. Don't go too technical here, necessarily; you don't need to spell out your complete design for a project, nor should you. Give potential applicants the core idea of what you're thinking/expecting, and be prepared to work with them on their interpretation of the project as/when they apply.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors: It is not compulsory to have co-mentors, but it is definitely a good idea. Secondary mentors do not need to be as knowledgeable as the primary mentor, but they should be available to help the student as/when necessary (e.g. the primary mentor is on vacation)

  • Deliverables of the project: A clear and simple description of what you expect from a successful project

  • Desirable skills: Skills that the student has or is willing to develop. Remember, the students are not likely to have as much experience as the mentor!

  • What the student will learn: Tell the students what they should expect to pick up from the project, and how they will make a difference to Linaro. Help to motivate them here!


Projects with confirmed mentors

Please keep this section clear of project ideas without confirmed mentors, to avoid any confusion for prospective students. Such projects should be published in the next section.

AArch64 porting

  • Description of the project: ARMv8 is the newest version of the ARM CPU architecture, and with it comes a new 64-bit execution state called AArch64. The new 64-bit world includes a new instruction set with features such as more advanced SIMD capability, instructions to speed up software cryptography, increased register files, flexible addressing modes, support for tagged pointers, 64k data pages, a new exception model, enhanced cache management and enhanced floating point operations (IEEE754-2008). Making the most of these new features will necessitate porting of existing software: multimedia making use of SIMD for performance, multi-threaded applications and libraries using atomics for thread safety, etc. We have already identified a large example set of Free and Open Source Software packages where assembly is used and looks like it will need porting (more details). There is much more work here than Linaro engineers are going to be able to cover themselves, so we're looking for bright students to help!

  • Confirmed Mentor: Steve McIntyre

  • How to contact the mentor: steve.mcintyre@linaro.org , SteveMcIntyre on irc.freenode.net

  • Confirmed co-mentors: TBA, we may have several iterations of this project targeting different packages

  • Deliverables of the project: A successful student will pick one or more existing Free Software package(s) that will benefit from ARMv8 porting, targeting threading, performance and other issues. Working with a mentor, he/she will generate patches to add useful improvements, document the benefits and submit them upstream.

  • Desirable skills: An appreciation of the challenges of porting software to new architectures, analysing existing software and identifying necessary changes. Low level skills such as assembly programming will be a major plus, depending on the package in question. Experience in build systems (autotools and others) is important to be able start quickly.

  • What the student will learn: How to work on a small team improving existing software; picking up knowledge about the latest CPU architecture which will be coming to mobile and other platforms very soon.


SIMD support for fftw3 (FFT library)

  • Description of the project: fftw3 is a Fast Fourier Transform library used by various projects. Speed matters in such libraries so it uses SIMD instructions where they are available. It has SIMD (NEON) support for 32-bit ARM cores, but not 64-bit ones. So the project is adding ARMv8 NEON support. testing that it works, and showing that it is faster than the plain C implementation. There is room for optimisation work if there is time. This project is a specific example of the above general 'AArch64 porting'.

  • Confirmed Mentor: Steve Capper

  • How to contact the mentor: steve.capper@linaro.org

  • Confirmed co-mentors: steve.mcintyre@linaro.org , SteveMcIntyre on irc.freenode.net

  • Deliverables of the project: armv8 NEON support patches for fftw3 submitted upstream

  • Desirable skills: An understanding of SIMD instruction coding. Some knowledge of performance analysis/correctness testing would be useful, as well as build skills to get going quickly. Hardware will be needed for testing, probably supplied via the linaro lava lab.

  • What the student will learn: A detailed understanding of ARMv8 NEON instruction set along with more general knowledge about this new CPU architecture, which will be coming to mobile and server platforms very soon.


Run lightweight IP stack on top of OpenDataPlane

  • Description of the project: OpenDataPlane (www.opendataplane.org) is open-source, cross-platform set of application programming interfaces (APIs) for the networking data plane. This project is to develop running lightweight IP stack on top of it (http://savannah.nongnu.org/projects/lwip/ ). Implementing this will allow to run high performance network applications with zero operation system overhead.

  • Confirmed Mentor: Maxim Uvarov

  • How to contact the mentor: maxim.uvarov@linaro.org , MaximUvarov on irc.freenode.net

  • Confirmed co-mentors: TBD

  • Deliverables of the project: lwip samples (ping, http server, smtp and etc) working on top of OpenDataPlane stack using hardware I/O optimization (netmap, raw socket, SoC-specific queues). Because of inux kernel network stack is excluded from the I/O chain and all TCP/IP, UDP/IP work is done in userland with zero context switches - minimal packet copy/modification overhead exist. So that performance for http server based on lwip + odp should be match more better then standard linux stack.

  • Desirable skills: C program language, Linux networking knowledge.

  • What the student will learn: Writing performance network applications without standard kernel network stack.


Port DPDK examples to OpenDataPlane

  • Description of the project: OpenDataPlane (www.opendataplane.org) is open-source, cross-platform set of application programming interfaces (APIs) for the networking data plane. This project is to port dkdp examples to ODP and measure performance difference between dpdk and odp.

  • Confirmed Mentor: Maxim Uvarov

  • How to contact the mentor: maxim.uvarov@linaro.org , MaximUvarov on irc.freenode.net

  • Confirmed co-mentors: TBD

  • Deliverables of the project: Working DPDK samples ported to ODP. Performance measurements results on x86 for both DPDK and ODP.

  • Desirable skills: C program language, Linux networking knowledge.

  • What the student will learn: Writing performance network applications without standard kernel network stack.


email submission interface for Debian package testing in LAVA

  • Description of the project LAVA is a validation framework which can host a variety of automated tests on a wide variety of ARMv7 and ARMv8 platforms. This project will allow LAVA test jobs to be submitted directly from RFC822 formatted email on existing Debian mailing lists using GnuPG for verification. Administration of the tests to be run for which packages and feedback on the results of tests to the Debian maintainers will also be required. Tests will need to be designed to run inside the deployed test image to validate all parts of the package. Mailing list content will need to be parsed against a list of known packages and an interface developed to allow Debian maintainers to add packages to the profile, select from the range of tests and receive results. Customisation of tests may also be supported via the Debian maintainer interface. Extension to other automated message formats used by other community projects should also be considered. Tests will include support for ci.debian.net as well as package unit tests and other commands desirable by LAVA, Debian or the developer.

  • Confirmed Mentor: NeilWilliams

  • Confirmed co-mentors: Antonio Terceiro

  • How to contact the mentor: neil.williams@linaro.org, codehelp on irc.freenode.net

  • Deliverables of the project: automated validation testing of selected packages in Debian using LAVA, initiated directly from maintainer uploads

  • Desirable skills: An understanding of python. Django knowledge would also be useful. Some familiarity with Debian packaging and Debian tools will be useful as the validation will take place inside a Debian rootfs.

  • What the student will learn: How to create an interface between large, established, projects. Knowledge of automated testing and how to write tests to validate all parts of a particular device / package combination using JSON and YAML. Interfacing with mailing lists and using GnuPG for verification.

  • extra notes: This is a joint project with Debian - mentors will be Debian Developers.


Publishing large files from a LAVA device

  • Description of the project: LAVA is a validation framework for automated tests on ARMv7 and ARMv8 devices using temporary test images. This project will involve developing a method of publishing large files or collections of files from one LAVA test job to multiple other LAVA test jobs. Files could include patched kernel builds, Debian packages, test harnesses or any other natively compiled executables and data. These files would then be made available to subsequent LAVA test jobs, initiated from within the original job. This API can then be used across LAVA to support porting of packages to new architectures, continuous integration loops for the kernel or other packages and for preparing large data sets.

  • Confirmed Mentor: NeilWilliams

  • Confirmed co-mentors: Antonio Terceiro

  • How to contact the mentor: neil.williams@linaro.org, codehelp on irc.freenode.net

  • Deliverables of the project: Patches accepted upstream to LAVA to support a publication & submission API for arbitrary collections of files

  • Desirable skills: Some python experience will be important, django experience will be useful. An understanding of shell scripting will be useful. Although the implemented project will be running on ARM devices, there is no requirement for ARM devices during development - LAVA supports KVM test jobs.

  • What the student will learn: Writing new functionality for automated validation on an existing codebase. Knowledge and experience of automated testing..


DTS schema and linter

  • Description of the project: Device Tree is a technology used to provide kernel with information on available devices and their properties during the boot time. Device tree is the new way of providing this information to kernels on ARM SOCs instead of hard-coding the same data in the kernel itself. In this project we would like to implement a schema against which device tree sources (DTS) can be validated and also a linter kind-of utility to run against DTS and check its proper formatting and style.

  • Confirmed Mentor: Grant Likely

  • How to contact the mentor: grant.likely@linaro.org, gcl on freenode IRC

  • Confirmed co-mentors: none

  • Deliverables of the project: DTS schema and linter utility, implemented in a way that will make it easy to use in kernel developer's typical working setup

  • Desirable skills:

    • Basic Linux kernel developer basics
    • Shell scripting
    • Data parsing and validation
  • What the student will learn: You will get deep insight into device tree technology that is the cornerstone of booting embedded Linux kernel; particularly on ARM SOCs. You will also get hands on experience with tool development and improve your understanding of kernel development process.


Linux Flattened Device Tree Self-checking

  • Description of the project: Device Tree is a technology used to provide kernel with information on available devices and their properties during the boot time. Device tree is the new way of providing this information to kernels instead of hard-coding the same data in the kernel itself. The Linux kernel has a small amount of self-test infrastructure available, but it is difficult to use and only enabled by default on one platform. This project is to rework the FDT self tests to be usable on any platform just by enabling the self-test driver.

  • Confirmed Mentor: Grant Likely

  • How to contact the mentor: grant.likely@linaro.org, gcl on freenode IRC

  • Confirmed co-mentors: none

  • Deliverables of the project: Linux kernel patches enabling FDT self tests on any platform by dynamically loading self test data.

  • Desirable skills:

    • Basic Linux kernel developer basics
    • Shell scripting
    • Data parsing and validation
  • What the student will learn: You will get deep insight into both upstream Linux kernel development and device tree technology that is the cornerstone of booting embedded Linux.


UEFI Runtime Configuration from Flattened Device Tree

  • Description of the project: Device Tree is a technology used to provide kernel with information on available devices and their properties during the boot time. It is particularly useful to virtual machines because it can be dynamically generated to reflect the virtual machine layout. There are some use cases where it is useful to use UEFI firmware inside the virtual machine, but the current UEFI implementations hard code the machine layout. This project is to add FDT configuration support to the UEFI TianoCore project so that a generic UEFI image can boot in a dynamically configured virtual machine.

  • Confirmed Mentor: Grant Likely

  • How to contact the mentor: grant.likely@linaro.org, gcl on freenode IRC

  • Confirmed co-mentors: none

  • Deliverables of the project: UEFI Tianocore patches enabling runtime configuration using an FDT platform description.

  • Desirable skills:

    • Basic Linux kernel developer basics
    • Shell scripting
    • Data parsing and validation
  • What the student will learn: You will get deep insight into UEFI firmware and how it interacts both with hypervisors and the Linux kernel.


Port UEFI to Low-Cost Embedded Platform

  • Description of the project: UEFI is a standardized interface for firmware and Tianocore is an open source project providing a UEFI implementation that conforms to the UEFI spec. UEFI was designed primarily with general purpose computers in mind, but many of the benefits of UEFI are also valid for embedded system design. This project is to work through the process of porting UEFI to a new ARM platform (most likely the BeagleBoneBlack) and document the findings to make it easier for other developers to port UEFI to their own hardware.

As a secondary goal, this project will also explore how well UEFI matches with embedded designs and will provide recommendations for UEFI specification changes that would be required to make embedded UEFI fully compliant with the specification.

  • Confirmed Mentor: Leif Lindholm

  • How to contact the mentor: leif.lindholm@linaro.org, leiflindholm on freenode IRC

  • Confirmed co-mentors: Grant Likely

  • Deliverables of the project: Patches to Tianocore providing board support for a readily available UEFI platform (Likely the BeagleBone Black). A porting guide document or wiki page providing guidance for porting UEFI to new hardware.

  • Desirable skills:

    • C programming skills
    • Familiarity with Linux as application build envirment
  • What the student will learn: Understanding of firmware design issues and how firmware interacts with hardware and the Linux kernel. Become familiar with UEFI in particular and will explore the issues related to using UEFI firmware in an embedded context.


NEON2/VFPv4d32 emulation for Linux

  • Description of the project: The ARMv7-A architecture contains several optional components - the NEON SIMD engine, the VFPv4 hardware floating-point unit and even half of the possible available floating-point registers. Unfortunately, this means user software usually gets built for the lowest common denominator. The idea is to have the kernel trap the undefined instruction exception that is generated when these instructions are executed on a processor that does not implement the feature, and emulate their operation in software. This will permit applications and libraries to be built for the most efficient version of the instruction set, while still running on older processors.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors: Leif Lindholm, leif.lindholm@linaro.org, leiflindholm on freenode IRC

  • Deliverables of the project: Kernel patches providing software emulation for userspace of one or more of NEON, NEON2, VFPv3D32, VFPv4D32.

  • Desirable skills:

    • C programming skills
    • Familiarity with Linux as application build environment
  • What the student will learn:

    • interacting with Open Source projects.
    • Understanding of instruction set encoding and kernel exception handling.


Renderscript Port

  • Description of the project: Renderscript is an Android C and Java framework for computationally intensive tasks. It is best at data parallel tasks. A developer writes what is called a kernel to run on an abstract computational device. Often this is a GPU but the Renderscript runtime will dispatch the work across available CPUs, GPUs or even DSPs. Because Renderscript is limited to Android it has hindered its adoption. This project would help to bring Renderscript to traditional Linux.

  • Confirmed Mentor: Tom Gall

  • How to contact the mentor: tom.gall@linaro.org , !tgall_foo on irc.freenode.net

  • Deliverables of the project: The Renderscript runtime ported to Linux with access via the C based API.

  • Desirable skills: C, C++, OOP, GPGPU computing through Renderscript, OpenCL or Cuda.

  • What the student will learn: How to approach an existing open source project and port it by building up from unit tests to a functional whole. How to convert an environment from running on Android to running on Linux yet preserving runtime correctness. How to interact with existing developers to take their code in interesting new directions.


Projects without confirmed mentors

This page contains project ideas that have been suggested but do not (yet!) include confirmed mentors. These projects won't happen if nobody steps up to the task of mentoring them.

If you are willing and able to mentor one of those projects, please add your name to the Mentors section and move the paragraph back up the the first section.

If you want to add an idea, please follow the template below. But before doing so, please consider mentoring the project, and/or looking for co-mentors to help you doing so. Not having mentors means the project won't happen.

Auxv based runtime cpu detection for OSS software

  • Description of the project: Many software try to detect runtime which CPU features are available (such as SSE on x86 or NEON on ARM). Methods used currently for runtime detection are often based cpuid instruction, parsing /proc/cpuinfo or trapping SIGILL to detect unsupported instructions. Worse, some projects don't have any runtime detection and only have compile-time detection. In this project, student would add auxv based runtime detection to a couple of open-source projects and write blog-posts detailing how auxv can be used for detecting cpu as documentation. Some of the methods for accessing auxv include libauxv (https://github.com/libauxv/libauxv) and glibc's getauxval() function.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors:

  • Deliverables of the project:

  • Desirable skills:

    • C programming skills
    • Familiarity with Linux as application build envirment
  • What the student will learn:

    • interacting with Open Source projects
    • Details of CPU runtime detection


Coreboot on AArch64

  • Description of the project: Coreboot is a minimal firmware implementation, initially created as "LinuxBIOS" to be a replacement for the default PC firmware. This project is about porting this software to the 64-bit ARM architecture, AArch64. Mainline Coreboot contains some support for the 32-bit ARMv7-A architecture (AArch32), but AArch64 has a new exception handling model and a new instruction set, so a complete new port is required. Hardware platforms are still in short supply, so the intended target platform is the free (as in your favourite beverage) ARM Foundation Model for ARMv8. This also reduces the scope of this otherwise quite complex task, since certain steps such as memory controller configuration will be required.

  • Confirmed Mentor: Name of the mentor

  • How to contact the mentor: (mail, IRC, etc)

  • Confirmed co-mentors: Leif Lindholm

  • Deliverables of the project: Patches implementing coreboot support for the ARM Foundation Model in 64-bit mode, with a hardware feature support set less than what would be expected from an actual hardware platform.

  • Desirable skills:

    • C programming skills
    • Familiarity with Linux as application build environment
    • A basic grasp of processor architecture concepts
  • What the student will learn:

    • interacting with Open Source projects.
    • The 64-bit ARM instruction set (A64).
    • The AArch64 exception model.
    • Firmware concepts and design.


SummerOfCode2014/ProjectIdeas (last modified 2014-04-05 20:05:50)