Tuesday, July 26, 2011

Qdev fix

In the last post, I mentioned that I had been unable to get all the devices properly registered with the kernel. As it turns out, the problem was not with how it was being instantiated, but rather it was how the devices were named. As my mentor, Peter Maydell, discovered, the Android Kernel polls for devices by matching the device names against a string. Because I had renamed the devices to use dashes between words (goldfish-tty) as is the QEMU convention, the kernel was not able to find the device name it was looking for (goldfish_tty) and was unable to issue the correct signals. Simply renaming the devices fixes the issue.

In addition to this issue, Paolo Bonzini pointed out a problem in my qdev conversion in how I dealt with default IRQ's, so I'm fixing that as well before submitting.

* I'm in the process of moving back to my school campus (500 miles away) and into a new apartment this week. The worst part is over (packing, driving, and apartment lease signing), so I can hopefully get everything up and running soon. Though with my luck this summer, my new car will break down and my hdd will crash before I can get internet access to my desktop.

Sunday, July 24, 2011

Qdev status

I have converted the serial branch to utilize qdev, but it's still not quite working, so I missed by deadline. The current code is on the serial_qdev branch. This code currently is only able to print the "Uncompressing kernel" message, but clearly doesn't register all of its services correctly and misses the messages from the kernel.

More than likely the problem is that I made a mistake somewhere copying over the initialization routines/settings, but I haven't yet been able to isolate the problem.

Tuesday, July 19, 2011

Schedules and Pixels

After passing through the midterm evaluations, I revised my projected schedule with weekly milestones and it hopefully contains a more accurate projection of my work for the last 5 weeks of this summer project. In the calendar below, the Friday events are the weekly milestones.

I finished up the pixel conversion patch (modifying goldfish_fb to convert pixels to the correct format if necessary since the Android kernel is only supporting the RGB_565 format), and it's currently available in my git repo. I'll convert the basic serial patches to qdev over the next few days. My milestone for the week is a basic patch set to obtain serial output from the Android kernel that correctly utilizes qdev.

This week I will be focused on getting correct input handling (mouse/keyboard input), with a goal for the end of the week of having inputs functioning in my git repo.

After getting everything functioning in my git repo, I'll focus on making changes that are necessary for getting it accepted into QEMU. As such, this week I will focus on goldfish_nand, and getting it to conform correctly to the QEMU guidelines, as it doesn't handle filenames like it should. The milestone for the end of the week is to have my git repo fully functional without having to specify the kernel filename in the source code.

Continuing with my integration, I will spend the next week building upon my previous qdev conversion and moving all the devices to qdev. I'll also be removing the android/ directory as much as possible. The milestone for the week is to have a fully functional git repo that utilizes qdev.

The last week of the summer, I will be working on any remaining tasks to clean up the full patch set for Goldfish, finishing up any missing work and putting together the full patch set. The goal for the week, and for the project, is to submit a working, fully functional patch set for the Goldfish hardware.

Wednesday, July 13, 2011

Framebuffer Update

When running Android using SDL and the correct pixel format, the timeout message "goldfish_fb_pan_display: timeout wating for base update" doesn't appear, yet it still does when using VNC. I narrowed down the problem to missed calls to goldfish_fb_update_display().

I believe that because of how the VNC display is handled, this update is only called when necessary, and the Android kernel is not expecting the display to be handled in that manner (it expects a display update with every base update). If that's the case, then it is not pointing to some deeper bug in the way I've merged the interrupt code.

Tuesday, July 12, 2011


While I was putting together a proper patch for the pixel format issue, I discovered that being able to change the default pixel format by modifying console.c fixed the issue when using VNC, but did not work for SDL. This suggests there is a deeper problem, possibly related to the "goldfish_fb_pan_display: timeout wating for base update" messages.

While there may be a problem with the communication between the goldfish_fb device and the kernel that causes the timeout message (more on that later), that isn't the problem with the SDL display.

When creating the SDL display, the pixel format is set by sdl_create_displaysurface() in ui/sdl.c:169. At ui/sdl.c:194 it only sets the pixel format for the guest display to 16 bits if that is also the pixel format for the host system, otherwise it defaults to 32. This is just a case of SDL having it's own copy of the default pixel format value, so it can easily be fixed by including it as a modifiable default value.

I'll send it to the dev list once I whip up a patch to actually change the value. This can be used right now to get Android running correctly with SDL by changing the default_pixelbpp value to 16 in the source.

Wednesday, July 6, 2011

Framebuffer Patch

I've narrowed down the issue with the distorted image seen in my previous post here. The issue was that the pixel format used by Android is a 16 bit format rather than the 32 bit default in QEMU, and it was never getting set correctly. After changing the pixel format, booting the Android image results in the below display. It is still unresponsive to any inputs, so that should be my next focus.

The patch used for this is commit 2b91f9d7 against my "android" branch. It forces QEMU to always use the 16-bit format, so it can't be used as a final solution, but it does demonstrate where the issue lies. In addition, this does not solve other issues with the framebuffer (the constant error message from the kernel about "goldfish_fb_pan_display: timeout wating for base update" and the lack of goldfish_fb_read/write calls when compared to the Android Emulator) but those issues appear to be a problem with the mechanisms that call the framebuffer functions rather than with the goldfish_fb code itself.

I'm still looking for the best way to incorporate this fix in QEMU without breaking compatibility with other QEMU guests.

Monday, July 4, 2011

Serial output patch set

Today I put together a patch set that will provide mainline QEMU with a minimal "android_arm" machine and the necessary drivers to view kernel debug messages. The patches have been integrated into the new "serial" branch in my Github repository, and are the 5 commits sent on 2011-07-04.

Commit: 8bbd489b69cd9e3fa10bb5a483773b99ed55e114
Goldfish device integration

Goldfish interrupt integration

Goldfish timer integration

Goldfish tty integration

Android_arm machine integration

The options needed to view the kernel debug messages are:
-append "console=ttyS0" -serial stdio -M android_arm

Monday, June 13, 2011

Weekly Update

It's been a bit of a slow week since I was away for several days, but I did manage to make some noticeable progress. Below is a screenshot of android running on my modified mainline QEMU. It complains a lot, but it does boot. It is completely unusable and obviously still has issues, but it does boot.

To get it running yourself requires some modification of the code as I've not yet added a command line option for specifying the nand device. In hw/android_arm.c, lines 144 and 145 need to be modified to point to the system.img and userdata.img that you want to use.

Going forward
My priority for this week is to fix the remaining issues holding back a usable booted image and hopefully have an interactive set-up (with fixed graphics) available by the end of the week.

**Note: To get it booting you need the following command line options enabled as well:

-kernel kernel-qemu -initrd ramdisk.img -append "console=ttyS0" -serial stdio -M android_arm

Wednesday, June 8, 2011

Updated Schedule

For simplicity I created a Google calendar that will hold my schedule for the summer. I'll summarize the events as they stand at the bottom of this post, but the embedded calendar is probably easier to view, and I will update it if the plans need to be changed.

As a note, there are obviously places in the schedule that will continue to change as time goes on. The goal for the summer is to get to a point where it is usable for simple applications, and then add features in order of importance. As such, I've budgeted extra time than I think necessary for the main goal and I've taken an educated guess at how long the later features will take as I am less familiar with those systems. If it looks like my efforts will be better spent working on some other feature then I will shift my focus to that.

Goldfish Integration 6/6 - 6/19
Working on integrating the Goldfish hardware into mainline QEMU. Testing each module will be done as I go.

Goldfish Completion 6/27 - 7/3
Finishing Goldfish integration and more extensive testing if necessary. Putting together and submitting a patch set for all of the Goldfish components. This should bring the project to a bootable state, but will lack other features.

Networking Integration 7/11 - 7/17
Make changes if necessary to use the existing networking capabilities.

Telephony Integration 7/18 - 7/31
Integrating the telephony portions (gsm, sms, sim card).

GPS Integration 8/1 - 8/7
Merging the GPS capabilities.

Finishing Touches 8/8 - 8/21
Finishing up any remaining work. Putting together and submitting a final patch set if applicable.

Sunday, June 5, 2011

Weekly Update

Another week has finished and I finally have some verifiable results. I have ported various portions of the Goldfish hardware as well as the "android_arm" machine, and have managed to get output from the kernel routed to stdio. This will be incredibly useful for debugging purposes going forward. The changes are available on github with commit 1416f1a41bdfc813edd88bcd2b62b85ceae3d6ec (Link), which makes some necessary bugfixes to get the android_arm machine running.

The command line options necessary to view the kernel output are "-append "console=ttyS0" -serial stdio -M android_arm". Selecting the android_arm machine is necessary as it is not set as the default.

Compiler Warnings
As of this moment, the code I've merged generates several compiler warnings. As such, compilation needs to be done with -Werror disabled. They don't affect anything so I haven't been concerned about them yet, but I'll push some bugfixes soon to get rid of them soon, before it becomes a problem. EDIT: All fixed.

Moving Forward
Now that I have a better understanding of what's necessary for this project, my initial proposed schedule needs to be revised. I'm currently planning to focus on merging the rest of the Goldfish hardware next, but I will be posting a new schedule soon.

Saturday, June 4, 2011


I've started using Github to host my repo on this project. I'm tracking the master branch of QEMU and my own "android" branch to hold all of my merges. More information can be found at the link below.


Thursday, June 2, 2011

Debugging Output

The main goal for this week has been to get debugging output coming from the kernel. I first focused on the android-kmsg system, which involved merging over 'android/hw-kmsg.*' and 'charpipe.*', but that approach was incorrect. With further testing, I found that kernel output from the Android Emulator could be obtained even with bypassing that message passing system and instead utilizing the existing system in QEMU with the command line arguments "-append "console=ttyS0" -serial stdio", so those elements weren't needed at this time.

The needed elements for setting up correct outputs are contained in 'hw/goldfish_tty.c' and 'hw/goldfish_device.c'. After moving those files and including necessary dependencies, I added the needed initializing function calls into the init function for the arm machine and managed to get some output. As of now, however, I am only able to get the "Uncompressing Linux....done, booting the kernel." message and nothing else. This message does not show up without these changes, and uses the ported system to produce output, so I am on the right track, I'm just busy tracing through that system to see what I missed.

The patch can be found here, applied to mainline QEMU it will produce output when run with the below command. The files 'kernel-qemu' and 'ramdisk.img' can be found under platforms/android-[version]/images/ in the SDK after installing a version of the SDK Platform.

qemu-system-arm -kernel /path/to/kernel-qemu -initrd /path/to/ramdisk.img -append "console=ttyS0" -serial stdio

**Note: The option "-append "console=ttyS0"" does not affect the output at this time because it dictates to the kernel where to send it's messages and I'm not seeing those yet.

Monday, May 30, 2011

Weekly Update

Hindered once again by being sick (e.g. I slept 18 of the last 24 hours) I didn't get quite as much work done this week as I hoped for. Below I have outlined many of the elements of the Android Emulator that will need to be merged into mainline QEMU.

Essential Elements
All the goldfish hardware. Additionally this needs to be supported by new command line arguments to properly configure the new devices. The command line arguments will ideally be done by parsing the hardware configuration file for an Android Virtual Device (AVD) with a new command line argument (-android-hw ?) as opposed to manually configuring an AVD via the command line.

As far as I can tell, this is the only thing essential to booting an Android Image, as other elements, such as Networking and additional hardware sensors can be disabled. The CPU emulation in target-arm/ shouldn't need to be modified, as it runs off the standard ARM CPU.

Important Elements
Networking. The Android Emulator contains it's own heavily modified version of net.c and the slirp/ directory, as well as the addition directories telephony/ and proxy/ that don't exist in mainline QEMU. Without merging this, the booted Android Image would be pretty useless for most purposes. Because this code must be shared with the other target architectures (unless we set up a specific target-android build), and it contains a large number of changes to get it to work, merging the Networking portion may take up a significant amount of time.

Elements to Disable
There are several elements that need to be disabled for Android as they are not supported, i.e. migration and usb support. Additionally, there are several areas where code is disabled during an Android build that will have to be dealt with some other way since the current plan is to integrate it into the target-arm build.

The file 'aio.c' was modified with the addition of iolooper (a wrapper for select()) but I'm still not quite sure why. Iolooper is utilized in several other android files so it can be merged when necessary, though since it is only used in android specific areas it is a trivial merge.

There are several other areas where there were heavy changes made, such as in 'qemu-char' that I do not yet understand.

I still believe that the main high-level elements to be merged are only the goldfish hardware and the networking elements. In addition to these, there were a number of changes made to the helper subsystems that will be difficult to determine, and I'm sure that I'll end up viewing a lot of years old commits to separate upstream merges from necessary changes.

What worries me is the number of changes made for Android that are almost certainly incompatible with the other QEMU targets. This may necessitate a new 'target-android' build in mainline QEMU or there would be some possible performance degradation with a global 'android_guest' variable.

Friday, May 27, 2011

Current Focus

I've been looking through the source of the Android Emulator (AE) and comparing it to mainline QEMU. I'm currently stepping through the AE's wrapper main function to figure out how much I can strip out and how to manually emulate an Android Virtual Device (The Android SDK specially sets up AVD's for use with the AE, hiding the image files from the user). Some things of note:

The hardware used in the Android Emulator is essentially self-contained. While this is probably the most essential piece to port over for basic operations, I don't think it will be as difficult as I originally conceived due to the modular design of the hardware component of QEMU.

The AE heavily modified/added on to the networking components of QEMU. They created their own copy of slirp/ under slirp-android/ and modified it for their own use, though I don't understand what changes they've made as of yet. They've also added support for the phone components under telephony/, including support for SMS and GSM.

I don't believe that the specialized networking components will be necessary to get Android to boot on QEMU, so I will plan to port these components after those necessary to boot.

Wednesday, May 25, 2011

QEMU Dev Documentation

The one thing I've found lacking in the QEMU project is source code documentation. There are several papers on the technology behind the emulation features in QEMU, but not a lot of information is out there about how each piece is implemented except for the source code (which for the most part lacks useful comments). This creates a bit of a barrier to entry for new developers on the project, and is actually one of the reasons I did not start contributing to QEMU during the school year, as I didn't have the time to devote to get up to speed.

As I've begun to explore this myself, I decided that I'd make a list of links that I've found helpful in getting up to speed. Since I've found that there really are now good sources for organizational details of the source code other than the source code itself, I decided that I will do my part and contribute to some of that documentation later on in the summer.

http://wiki.qemu.org/Manual :
This is the official documentation for QEMU that mostly focuses on users, but also has a little bit of information for new developers and some useful links.

http://old.lugatgt.org/articles/qemu_internals/downloads/slides.pdf :
These are some slides from a presentation given by Chad Kersey on QEMU Internals that focuses mainly on dynamic translation and basic block chaining. It also notes where some of those internal features are located in the source code, so it's easy to start browsing the code.

http://qemu.weilnetz.de/qemu-tech.html :
This link is generated from the qemu-tech.texi file located in the source tree. While this copy may be up to date, it would be safer to generate this document yourself from the source code tree. The qemu-tech document describes the internals of QEMU, while the other .texi files in the source tree provide user documentation.

The QEMU source code. All the documentation is there in the form of source code.

A technical paper by Fabrice Bellard discussing the original internals of QEMU. This paper is from 2005, so the details may have changed significantly.**Edit: As noted in the comments below, this is extremely out of date, so don't read it unless you're interested in the project's history.

Monday, May 23, 2011

Setting up Android Environment

Most of the information I am about to relay can be found here at the official walk through for setting up a Build Environment for the full Android system. I wrote up a short shell script to do all the set up work and start a full compilation of the system for the efficient that I have made available here, though I will point out it is necessary to read through it and make some small changes to customize it for your own folder naming conventions.

I found that I hit the least snags using the latest Ubuntu x86_64 version, so the script installs dependencies for that distro. Something else could be substituted in but all the Android testing is done on Ubuntu systems, and the build process will stop and complain if you try x86.

After the compilation finishes, all of the output binaries will exist under the "out/" subdirectory. Usage for the emulator is described on this website, although more options are available by querying the binary. The emulator can be built individually by running 'make emulator' in the main Development Environment folder or with more control by following the instructions in 'external/qemu/INSTALL'.

I chose to build the full Android environment so I could have more control over building an Android Kernel as well as having full access to all the necessary emulator bits.

Sunday, May 22, 2011


Here we are, the official beginning of coding time for GSOC 2011, and I'm already behind where I hoped to be. I absolutely hate it, but at this point it can't be helped. Some of the blame lies with me for not buckling down and working just after my graduation, and some of it lies with a viral infection that my doctor says is probably mono. Due to my sudden obsession with sleeping half the day and being tired and achy the other half, my usual schedule was disrupted and my productivity dropped to almost nothing. I had hoped that what I proposed for the "Initial Ramp-Up" stage would be completed before the official start, so I am already a week behind what I had hoped to be my schedule. I seem to be getting over my illness so I estimate that I will be roughly 75-80% productive this first week, and I'll work a bit more than planned over the following weeks if necessary.

As of now I do not have any vacations planned that would disrupt my work, though that will probably change at some point and I may lose up to a week. As soon as plans are made I will update the schedule to reflect any necessary changes.

Proposed Rough Schedule

The coding period for GSOC runs from May 23 to August 22, a period of 13 full weeks. Additionally, a mid-term evaluation is scheduled for July 11, which is the beginning of the 10th week. I've divided the 13 week summer into 4 separate stages, each of which has their own completion criteria.

Initial Ramp-Up - 1 Week (May 23 - May 29)
For the first week of the sumer, I will be doing a couple of things. First off, I will be comparing the Android Emulator with Mainline QEMU to determine, and make a list of, the broad areas I need to merge into the Mainline to get it running an Android image. While most of the changes appear to be in the addition of the "goldfish" hardware emulation, there are several other areas that need to be checked to determine what needs to be merged. The current Android Emulator can't be compared only to QEMU release 0.8.2 because some later patches to QEMU have been selectively added back into the Android Emulator, which complicates this process. After this process I will have a better understanding of how the timeline for the summer will go and will update the schedule.

During this stage I will also complete some of the due diligence that I've fallen behind on, including setting up a public git repository for my branch of Mainline QEMU and posting setup instructions for building the Android Emulator (I've got this in a script for Ubuntu 64-bit which is running right now, so this shouldn't take long).

Merging Changes - 9 Weeks (May 30 - July 31)
As already mentioned I will probably be changing the plans for this section of the schedule after I finish determining the necessary changes to be made during the Initial Ramp-Up period. This period is budgeted at 9 weeks of work, and will be entirely devoted to merging the portions of the Android Emulator into my branch of Mainline QEMU in order to enable the running of an Android image. My current schedule of changes to be made divides the necessary modifications into two segments, "goldfish" hardware and everything else. As it seems most of the changes are in the "goldfish" hardware, I'm hoping to get that done in the first 5 weeks and use the remaining 4 to work on the rest.

The end of this stage occurs when all of the necessary merges listed during the Initial Ramp-Up period are completely merged into my branch. The mid-term for GSOC occurs one week after I plan to be finished merging "goldfish", so even if I fall behind my current project schedule I should be finished with that portion by the mid-term. Finishing that will be my main goal to be on track at mid-term evaluations.

Testing and Debugging - 2 Weeks (August 1 - August 14)
The two weeks devoted to testing and debugging may seem excessive, but I'm trying to allow some leeway for any unforeseen issues. If everything works fine then I can focus on fixing everything up and cleaning up the documentation. Since everything is not going to work fine and/or the previous stage will take more time than anticipated, these two weeks are being set aside for

At the end of this period, no more code merging should be taking place. The only anticipated code modifications would be resolving diff conflicts with Mainline.

Final Stages - 1 Week (August 15 - August 21)
During the final week I plan on doing mostly clean up work, catching up on documentation and hopefully getting the diffs integrated back into Mainline QEMU. I may be crunched for time moving into a new apartment and preparing for grad school this week (my school year begins the day GSOC ends) so I'm planning on having most everything done before.

Monday, May 16, 2011

First Day

For those of you coming here unaware, allow me to summarize the project.

When Google wanted to create an emulator for their Android OS they chose to base their design off of one of the most popular, QEMU, to save on design work. They forked the project from the 0.8.2 release and made modifications to it to enable the emulation of an Android image. Additionally, some design improvements introduced to mainline QEMU may have been cherry picked and inserted into the Android Emulator project which could provide for some confusion down the line. Now that this Android Emulator has matured and is viable, mainline QEMU wants to include all of the necessary bits to run Android as well, leading to this Summer of Code Project.

The task laid out for this summer is straightforward in its description, select the appropriate changes made to QEMU 0.8.2 necessary to run Android images and import those changes into the mainline QEMU. To do this I must analyze the current Android Emulator code for the necessary core components and then work on porting the components to the mainline. As I get deeper into my analysis and understanding of the system throughout this week, I'll be providing a planned schedule of my goals expanding on these thoughts.

Current Work
Due to school and other issues I have only just begun to work on the project, which will give me a full week of preparation before the official start. I have been setting up my development environment complete with build scripts and I will post an instructional for doing so in a day or two. Additionally I will be mapping out a schedule for the summer and hopefully getting to know the community a bit during this last week.

I'll be logged in under my username 'pjack' and lurking on #qemu and #qemu-gsoc on irc.oftc.net whenever I can remember to do so. And I'm a bit new to using IRC, so don't be too mean ;)