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.

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.

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.



7/18
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.

7/25
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.

8/1
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.

8/8
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.

8/15
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.

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.

SDL

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.

https://github.com/patricksjackson/qemu/commit/fa8d6e9d7f9b6f5449f6ad40c2f140194a00a8ba

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.

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.

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

Commit: a7faf9baad7bf85062d94d8bcc8319f098d61fa9

Goldfish interrupt integration

Commit: 6b7a1dea630337deb6778d2316131714ae82c512

Goldfish timer integration

Commit: e9a0fd9204bb803b613074a95c26016016e30e81

Goldfish tty integration

Commit: 5c819cea2ae73e4ea67e30dce806a973be3b0119

Android_arm machine integration

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