From: Leif Andersen <leif_at_leifandersen.net>
Date: Mon, 28 Mar 2011 08:00:35 -0600

I have finished the first draft of my gsoc proposal. It is not
including links to the projects I have been asked not to publicly place
online, but it will in the actual proposal. I am looking for any
feedback you are willing to give me so I can submit it. Thank you.

About Me:

Name: Leif Andersen

Email Address: leif -at- leifandersen.net

Alternate Email Address:leif.a.andersen -at- gmail.com

Freenode IRC name: Leif, LeifAndersen

School: University of Utah

Major: Computer Engineering, both software and hardware, but more
software. And probably a minor in mathematics.

Year: Undergraduate - Sophomore, or at least this will be my third
summer outside of high school.

Primary Build Environment: 64-bit Linux, mainly ubuntu.

Digital Audio Players: Sandisk Sansa Fuze (v2), Motorola Droid X
(android port). A Bricked e260v1 is also lying around somewhere. I
also have access to a c250v1, as well as various other digital audio
players that are currently incomparable with Rockbox.


Rockbox Involvement: I have submitted several patches, one of which has
been added to the trunk (although it was a trivial patch): r29644. FS
numbers of open tasks are: FS#12025.


Interest in Rockbox: I enjoy digital audio players. They make long
commutes enjoyable, as well as a plethora of other uses. Even with the
rising popularity of smartphones, I find myself still using it like a
digital audio player (except that I don't need to connect it to my
computer). My first digital audio player was a Cowon g3. I loved that
thing to death (literally, the play button is broken). When I was
looking for a new digital audio player, I couldn't find any decent ones
that had the features I wanted, which at the time was mainly file based
organization as apposed to tag based organization. In the search, I
found rockbox. It looked like it had all of the features I wanted, but
I wanted to try it out before I would buy a player just to put Rockbox
on it (at the time I didn't know enough to just be able to download the
source code and compile a simulated version). However, it turned out my
brother had a Sandisk Sansa c250. After getting his permission, I put
Rockbox on the device, and except for the unreadable font size, which
was quickly replaced (I have very poor vision), I loved the software.
Thus I rushed out and bought an e260, placed Rockbox on the device, and
have never looked back.

Furthermore, as my major is Computer Engineering, I have taken several
classes on Computer Architecture, Organization, and Digital Logic, as
well as software engineering and micro electronics courses. Thus, I
feel qualified to do this project, and am eager to get some more work
outside of classes under my belt.


Location/Working Hours: I live the western United States (MDT). While
my schedule is not completely set this summer, I plan on working mainly
during the day (here), if that is possible. From what I understand,
most contributers are from Europe. I don't know how late you stay up,
but there does seem to be several people on IRC when I'm on, especially
in the morning. So I doubt this will be a problem.

Time Commitment: I will spend enough time to get the job done. I do not
anticipate spending any less than 20 hours a week, nor do I anticipate
to spend any more than 60. I feel like I will be able to get the job
done with about 40 hour of work a week. I do plan on doing some
academic research for my university this summer. From what I understand
from many of my (undergraduate) peers, the average amount of time per
week spent doing research (as an undergrad anyway) is about 10 hours a
week. So, I am confident that it will interfere with this project.
Finally, I may go on a vacation early in July (or very late in June),
but this will not interfere much with the project, just a few hours off
for travel time, etc.


Built Rockbox: Yes, I have built rockbox. I also have build the
cross-compilers I need to build it on devices. I currently have an SDL
version on my desktop and android device. I have built, and tested (for
bugs in the patches I submitted) with my Sandisk Sansa Fuze. Still,
because that is my main digital audio player, I currently have the
bootloader set to load a more stable version of Rockbox.


Languages: I have experience in several languages. These include:
Python, Java, C#, C++, Matlab/Octave, C, and some MIPS assembly. I have
several examples of (open source) source code that I have made (listed
below), which demonstrates my ability. I also have many more sample of
software which my professors have asked that I not publicly place it on
the internet, but are okay with me showing it to other people.


Open Source Contributions: Yes (listed below)

NetCatch: https://github.com/leifandersen/netcatch
A podcatcher for Android that myself, and Kevin Coppock, have been
working on. It is still very much an alpha product.

Blender Tests:
https://svn.blender.org/svnroot/bf-blender/branches/soc-2010-leifandersen
My GSoC 2010 project. These are tests for the 3d modeling and animation
software Blender: http://www.blender.org/. It currently is not in the
trunk as the Blender 2.5 API has only recently stabilized, and thus I
need to update the tests again to match the new API, then is can go into
the trunk. Also, JesterKing has recently shown me a few ways to improve
the image comparison test.

L-Compress: http://sourceforge.net/projects/lcompress/
This was my large(r) project I made in CS. I have improved very much
since then (for example, I had two methods to wrap around the array,
when I could have just use a modular operator), but if you want to see
how I have changed over time, you can look at this.

The Flyspray patches mentioned earlier: FS#12025, just adds an ohm's law
features to the resistor.c plugin.


Finally, some other interesting pieces of code that I have made that I
have been asked not to publish publicly online (mainly by professors):

A modification of KAstroids (ported asteroids from the qt demo package),
to make it a two player game. I also worked with a partner on this
project, Robbert Christensen on this project, his modification to the
game was to let the players map their own controls. The project took
more work than originally anticipated, as the player information was
hard baked into the game, but the MVC paradigm seemed like it was still
trying to be used (albeit it felt like it was placed into a blender).
We had two choices, to duplicate all of the code, except adding the p1
and p2 too all of the variables, or making it more object oriented, we
opted for the second one. Due to a lack of time, the player object was
more like a c struct than an actual class, and thus it felt like a mixed
paradigm, but I still think the project went well.

Sorting Machine Design:
This isn't really programming per say, but a project from one my
professors. The goal was to design a machine that could sort 100 16-bit
integers as fast as possible. (Also the sorting algorithm had to take a
fixed amount of time, thus something like selection sort, rather than
merge sort or quick sort was required). He first gave us a design to
analyze, and then we needed to come up with our own design that was faster.

------------------------------------------
Abstract:
The goal of this project is to create a usable ARM emulator for Rockbox
development. This emulator can be useful for Rockbox development, as
well as speeding up the process of making new ports stable. The
emulator should be capable of running both Rockbox and the original
firmware of various ARM based devices, and will likely be based off of
existing emulator solutions such as either QEMU or Skyeye.

Detailed Description:
There are various ARM emulators already in existence. Two that look
promising are skyeye, and qemu. Qemu's documentation seems to allude
that x86 emulation is where qemu does best. However, it does seem to
say that it does have good ARM 7 support, as well as decent MIPS
support. As the Android Emulator is powered by qemu, it seems like it
is a good choice for this project. On the other hand, skyeye seems
especially well suited for this task, which gives a fairly straight
forward api to implement, in order to simulate a new system on a chip.

As mentioned on the project description of the ideas page, a good
progression of this project would be in a sort of reverse Rockbox port.
 The first step would be to get an emulated system running a version of
Rockbox, and then also move it to the original firmware. Also, it would
be a good idea to start with one player, and then move out to others.
As I currently own a Sandisk Sansa Fuze v2, unless I had a reason not
to, I would start with that, and move on to other players later in the
project. One possible problem is that QEMU supports ARM7, and the
as3525, the system on a chip in the Fuze v2, is an ARM9 chip.

Some notes on the version control for this project. If it is customary
for Rockbox GSoC projects to have a dedicated SVN branch, I can do this.
 Otherwise, I was planning on simply using a git repo. Currently, I
have a clone of Rockbox with git, and use git svn rebase to get the
latest svn changes. This particular workflow won't work once I start
publishing the branch I'm working on, so I will merge the trunk into my
current branch, rather then rebasing it. Then at the end, patches can
be made to apply the changes to the trunk.


Task description and subdivision:
As I gave a detailed description in the previous section, I will place a
possible schedule, and subdivisions here.

The start of the project will be directly aimed at research. The bulk
of the investigation will be aimed at figuring out a good base to start
(QEMU vs. skyeye, vs. another solution). Once decided, the main
architecture of the project should be designed. When this portion of
the project is completed, most of the broad details for the project
should be decided upon, and finer details, and actual coding, can begin.
 This phase should be completed no later than the end of the community
bonding period, May 23.

The first half of the project will be dedicated to getting the emulator
up and running with a single Rockbox port, as well as getting the
original firmware to work on the emulator. A possible split of this
would be May 23-June 6:Get the emulator up and running. Pre-built
packages on most of these emulators are usually trivial to set up, so
this is more along the lines of getting the lower level bits of Rockbox
running on the emulator. As mentioned above, this will likely be for
the Fuze v2, unless there is some reason not to. This section may spill
into the next section, but this should try to be avoided. June 6-June
20: Getting the Fuze v2 port of Rockbox to run on the emulator. June
20-July 11: Work on getting the original firwaer to work on the
emulator. Hopefully this won't involve too much work, but extra time is
allocated in case there are unforeseen problems with how the original
firmware and the emulator work together, do to issues in the previous
sections. By the end of this section, the emulator should be fully
usable by at least one platform, ideally with both Rockbox and the
original firmware.

The second half of the project will be dedicated to expanding the
emulator to work on various other devices, as well as fixing up any
remaining bugs left with getting the original firmware to work properly
on the first port. A possible split of this would be: July 11-July
25:Fix any remaining issues with the original firmware running on the
emulator, work on getting the rest of Sandisk Devices working on the
emulator with at least Rockbox, ideally also the original firmware. July
25-Aug. 15: Fix up any remaining bugs with the remaining ports, ensure
that their firmwares work on the emulator. Also, if possible, get
another similar ARM device from a different manufacturer on the emulator
as well. An interesting challenge would be to see how well a new,
unsupported, digital audio player, could fit into the emulator. Changes
would be made to make this task easier.

Finally, the last part of the project is dedicated to cleaning up any
kludges made in the code, writing documentation, etc. I do not
anticipate much explicit testing needing to be done in this section, as
this seems like a project where testing during the project is paramount
to explicit tests made at the end. I suppose last minute coding (or
more likely, debugging) could happen in this section, but I would like
to avoid it if at all possible. As described on the summer of code
webpage, this section will take place from Aug. 15-Aug. 22.


Benefit to the Rockbox project:
Currently, if you look at the "Buyer's Guide" page on the rockbox wiki,
and then the "In Production" section, the only player that is marked as
Yes is the Sandisk Sansa Fuze v2. And while the page claims to have
outdated information, the trend does seem to apply to the most modern
iteration of Rockbox. By the time Rockbox developers start working on a
player, and it passes from unusable, to unstable, to stable, the player
is no longer being sold. This is a very difficult thing to do, with how
fast companies are dropping old players for newer ones. It would be
nice if interested developers could get a port to at least unstable, but
usable, before the player went off the market.

One of the reasons for the slow(er) development cycle is the amount of
work required to make sure it runs properly on actual hardware. The
simulator works fine for getting high(er) level code working, such as
code in the apps/ folder, but it fails when working with lower level
code, or code that works differently on x86, and arm (or whatever
architecture the build is for). Even as I developed a few patches for
various plugins, I noticed inconsistencies with how lower level
functionality fundamentally changed how I needed to write the code. And
developing on an actual device can be slow. Until the device's Rockbox
port get's USB suppors, or whatever it uses to talk to the computer, the
developer has to jump through a few small, but certainly annoying,
hoops, to test every iteration of the code. The more times this
happens, the more annoying it becomes. Porting, and development in
general, could happen much faster if the developer had an emulator of
the device to find, and fix bugs. And only need to test it on an actual
device at the very end, to ensure that the emulator wasn't giving
invalid output or was configured incorrectly.

Furthermore, having an ARM emulator may also aid in the initial stages
of porting Rockbox to new platforms, as it may be possible to load the
original firmware onto the emulator, and see what parts of the hardware
it accesses before the whole thing crashes and burns. This would reduce
the amount of searching that would otherwise need to be done by hand.


Milestones and Project plan:
The detailed schedule was listed above, but the major milestones of the
project are:
1. Low level hardware components, to get the lowest bit of Rockbox to run.
2. Rockbox for the Fuze running on the emulator.
3. Emulator supporting both Rockbox and the original firmware.
4. Emulator supports all Sandisk devices Rockbox supports.
5. Emulator supports slightly broader range of devices, but with
similar architectures.
6. Emulator usable for testing with future Rockbox ports.

Obviously as players change the emulator will need updating with time,
and if the majority of players stop using ARM based systems altogether,
that would require a very large amount of work to compensate. But
otherwise, I don't see this project taking too much work to maintain, as
ideally new modules should be somewhat easy to plug into the emulator.
Never the less, I likely will stick around and help maintain the
project. I obviously won't be spending as much time on the project as
school starts again, but I will stick around and help where I can. As
said in my profile at the top of the document, I enjoy Rockbox very
much. One other place I will likely help a lot with is the Android
port, which I am looking forward to quite a bit.


You and the Community:
Obviously, the best solution for real time communication is IRC, and
delayed communication with the mailing list. So far both of these
communications have worked well, and unless I'm given a reason to stop,
I will continue to use them.

As for status updates for the project. If possible, I could use a page
on the Rockbox wiki for this. If that is not acceptable, I could also
start a blog for this task, or another other preferred ways of giving
progress updates, I just assumed these would be the preferred means of
communication.

I expect the Rockbox community to be a fairly friendly environment,
although critical, possibly snarky, to bad ideas, which is exactly the
way I perceive the community now. As for my mentor(s), I also expect to
have a fairly friendly relationship, yet critical when needed. Also,
where possible, I am hoping my mentors will be able to point in the
right direction when possible.

From what I've gathered from reading the mailing list archives, the
student-mentor relationship is fairly loose, and the community at large
acts like mentors whenever possible. I am fine, possibly somewhat
enjoy, this type of a relationship. In order to keep the community up
to date with the progress, I plan on having frequent (at least once a
week at first, more (or, unlikely, less) as appropriate) If a stronger
mentor relationship is required, I am perfectly fine with that also.

Misc:

~Leif Andersen


Received on 2011-03-28