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
signature.asc
Description: OpenPGP digital signature
