Minnowboard:GSoC2015

--== Google Summer of Code 2015 - Ideas Page ==--

= About: =

The MinnowBoard project is an open hardware platform that uses Intel Architecture. While the project, overall, is focused on hardware there are a lot of things surrounding this effort that can, and are, useful both to the project and to the greater open source community. As such the MinnowBoard project (from a GSoC perspective) is more of an umbrella giving a home to a number of other projects to collectively work on and around the enablement of the MinnowBoard.

= Why is this important? =

These projects not only help the MinnowBoard project, but also enable other open source projects and software. These tend to be smaller projects or projects that are more tightly focused and would not otherwise be apart of GSoC, but that could benefit from additional contributors.

= What we are looking forward to in GSoC 2015 =

There are a number of projects that are being looked at, they are grouped by their overall focus. Areas of expertise are wide ranging from proficiency in perl and file synchronization, network booting (with specific emphasis on booting over the internet), uefi firmware programming,

= So what about the hardware, who's providing that? =

For development purposes the following will be shipped to students:
 * a MinnowBoard MAX
 * a serial cable
 * power adapter

= How to find us =

The best way to find us is on IRC (Internet Relay Chat), and start with #minnowboard@irc.freenode.net

A web based IRC client can be found at http://webchat.freenode.net/?nick=MinnowBoardGSoC.&channels=minnowboard&uio=d4

We've also got a mailing list at http://lists.elinux.org/mailman/listinfo/elinux-minnowboard

= Ideas =

About:
MinnowBoard is an open hardware platform that uses Intel Architecture. It's a versatile board and touches on a multitude of uses and sectors from high end makers, low end industrial and a multitude of other things from UAVs to the data center. There are a lot of aspects that the MinnowBoard is pushing the envelope, we are using a fully open source firmware (Tianocore EDK2), and there's a lot of software and capabilities that are not optimized or even easy to use. Our intention is to help enable more of these things on the MinnowBoard MAX and to help make the entire ecosystem better. Projects here are specifically targeting either the firmware or software specifically relating to the MAX.

Clean up / Fix EDK2 (Tianocore) GCC firmware build system
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Easy

The current build system has a number of issues and need a full review and re-work. Mostly this is a shell re-writing exercise as well as a dive into what compiler options we may or may not be setting that could improve code density and/or performance.

Goals:
 * Re-work the build system to either a cleaner more manageable (and expected) shell script OR convert the GCC build system over to generic Makefiles.
 * Include better help documentation specifically for Linux/GCC builds but could be made portable to the Windows .bat system as well
 * Investigate compiler flags to verify and show code density and/or performance

Requirements:
 * Shell (bash) and/or GNU Makefile knowledge
 * General understanding of expected practices for build systems under Linux
 * Familiarity with Linux command line
 * Experience with Tianocore/EDK2 a plus, but not required.

Replace Realtek Binary PXE stack w/ iPXE & custom boot script
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Medium to Hard

The MinnowBoard MAX currently uses the binary PXE stack provided by Realtek. We've like to move away from that and towards using iPXE directly, if for no other reason it gives us more flexibility in how we can network boot on the MinnowBoard MAX. In particular we'd like to integrate with the resurrected projected called Boot Boot (formerly boot.kernel.org / BKO) to provide easy access to tooling, and access to installers for the MinnowBoard MAX.

Goals:
 * Confirm working iPXE drivers for the Realtek chipset on the MinnowBoard MAX, and proof of concept stack confirming this all works
 * Create build process to replace Realtek binary drivers with iPXE in the EDK2 build tool chain. This will include needing to pull and integrate iPXE into EDK2
 * Create a custom iPXE script allowing for internet booting to Boot Boot and/or local PXE (IPv4 and IPv6) booting

Requirements:
 * Familiarity with iPXE
 * Familiarity with EDK2 / Tianocore
 * Familiarity with Network booting
 * Willingness to dig into complex areas of firmware and build systems.

Improve U-Boot EFI Support
Mentors: Simon Glass 

Difficulty: Medium

So far U-Boot has support for Minnowboard MAX, as described here: https://www.mail-archive.com/u-boot@lists.denx.de/msg161260.html

However U-Boot cannot read an EFI kernel image. It would be useful to add this support to U-Boot. Initially this could be a fairly straightforward port of some existing open source code, but the project could expand to adding commands to query the image, boot menu, tools integrations, etc.

Requirements:
 * C
 * Basic understanding of EFI and/or U-Boot

About:
SMBus is an extension of I2C used for system management. PMBus is an extension of SMBus used to manage power systems. SMBus is used for battery management and other system functions, and PMBus is used to manage power in equipment used in data centers, such as servers and routers. It is common for a system to have a Board Management Controller (BMC) based on an application processor running Linux. The Intel Atom is an ideal platform for BMCs because of broad support for compiler technology targeted at I32/I64 instruction set. For example, Haskell, a functional language, compiles and performs well on a MinnowBoardMax running Ubuntu 14 TLS.

SMBus Kernel Support
Mentors: Michael Jones, John 'Warthog9' Hawley

Difficulty: Medium

The SMBus 3.0 specification was recently released, and Linux does not fully support the changes to the specification, and the MinnoeBoardMax drivers do not fully support the specification. The SMBus driver architecture and API needs to be updated as well as adding full support for MinnowBoardMax including:

Goals:
 * Fully support PMBus Protocols (Can implement them using /dev/i2c* ioctl and Linux smbus API)
 * Support 256 byte block commands
 * Support on the fly clock rate changes via /dev/i2c* (ioctl and Linux smbus API)
 * Support asynchronous callbacks to a user space application for SMBALERTB using MinnowBoardMAX GPIO
 * Support configuration and choice of GPIOs for SMBALERT from /dev/i2c (ioctl)
 * Other SMBus functions as discovered to be missing all available to user space applications
 * Code accepted into the mainline kernel git server

Requirements:
 * C
 * Understanding of Linux driver architecture and compiling and debugging the Linux kernel
 * Knowledge of /dev and ioctl based user applications
 * Basic understanding of Ubuntu, gcc, apt-get, and standard development tools

This may require extension or modification to the current Linux smbus API, and students should be willing to make suggestions and recommendations and lobby the community, if that is required to meet the end goal.

Haskell SMBus/PMBus Module
Mentors: Michael Jones, John 'Warthog9' Hawley

Difficulty: Hard

There are Haskell modules available for USB and UART, but not for I2C/SMBus/PMBus. Tool builders and robotics enthusiasts in the functional programming community could use supporting modules.

Goals:
 * I2C/SMBus/PMBus modules with reusable abstractions
 * Support multiple implementations of a single abstraction (classes) with a late binding (building blocks connected at runtime)
 * An implementation for MinnowBoardMax running on Ubuntu with the latest Kernel including SMBALERT and ARA
 * Use new features from the SMBus Kernel Support as available
 * Publish on GitHub and Hackage

Requirements:
 * Basic C skills
 * Haskell (way more than hello world)
 * Haskell Foreign Function Interface (FFI) and H2C experience
 * Basic knowledge of /dev, ioctl, signals, on Linux
 * Basic understanding of Ubuntu, gcc, apt-get, and standard development tools

This project requires pre-existing Haskell skills. It is best if the student has familiar with Lamba Calculus and Category Theory, but more important is practical applied skills writing real code.

About:
SyncDiff(erent) is a state-full file synchronizer, with ideas shamelessly stolen from rsync, git, csync2, unison and probably a variety of other places. Two of the major design goals were to lower the time it takes to determine what has changed on disk (particularly in comparison to rsync), and to allow allow for multi-way synchronization using a star topology, and accepting eventual consistency. This is interesting to the MinnowBoard project as it's used, in minor ways, around our own infrastructure and we want to increase it's usability and approach-ability.

HTTP Accessor
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Medium

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would add an intermediate CGI that would allow a client to communicate with the server running via a web server. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Good understanding of CGI interfaces
 * Understanding of Apache and Nginx (targeted web servers, knowledge of others beneficial)

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

SSH Transport
Mentors: John 'Warthog9' Hawley, Greg Lund-Chaix

Difficulty: Medium

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would allow for that stream to happen over an authenticated SSH connection, as opposed to the straight TCP connection, similar to scp, sftp, rsync, etc. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Good understanding of ssh

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

TLS implementation
Mentors: John 'Warthog9' Hawley, TBD

Difficulty: Hard

Right now SyncDiff(erent) currently transfers files using a slightly custom protocol over TCP. This project would add TLS to the communications channel to encrypt all traffic being transferred. The communication protocol involves JSON.

Requirements:
 * Perl
 * Understanding of IPCs and Multi-processed programs
 * Basic understanding of TCP/IP
 * Knowledge of Wireshark, and ability to run it
 * Understanding of TLS communications, including how revocation certificates work

This may require extension or modification to the current protocol, and students should be willing to make suggestions and recommendations, if that is required to meet the end goal.

= How things work / What do I do now / How do I proceed: =

For a lot of students this may be your first year participating, or you may never have worked with us, so lets break this down:

February 20th - March 16th: Students are encouraged to start looking at the project, join the IRC channel, talk on the mailing list and generally interact with us. This will help you get a feel for who we are, and if you want to work with us. This is a great time to ask about the ideas we have up too, and to start thinking about what you might want to work on.

March 16th - March 27st: Students should be working on their applications. This is a collaborative process, we want you to ask questions, get feedback, make revisions and make as good a proposal as possible. Holing up and not talking to us will make your proposal suffer.

March 27th - April 27th: This is where our organization is going to differ from some others. Students will be asked to sit down with us for a 1hour long IRC based interview during this time. We will discuss your proposal, ask you questions and there will be a coding exercise or two. Students shouldn't feel the need to cram, or worry much about this, this is mostly a time to chat with the student and for questions to be traded. This interview is, however, required by our organization.

March 27st - April 27th: This time period in general is for more discussion to be happening with the students and organization. Submit bugs and patches, talk with the mentors. A general hint, lobbing the application at us and disappearing will generally count against you. Stick around, and keep the conversation going that you've already started.

April 27st: Notifications go out to students about acceptance. At which point the summer really starts!