Grrr, I sent this last night, but it didn't go through because of the attached image. Here's the link to the image I wanted to send: http://dave.is/bootinglinux.png --- Hey All, Here's an update on the progress I've made. I now have QEMU booting on the emulated device with graphical output on SDL. The image is distorted, most likely some problem with the resolution passed into the kernel. The catch is that I still can't accomplish this without using gdb to change a function parameter at runtime. What happens without this intervention is that qemu_console_resize() gets called with a width of 640. Because the emulator (and the device) have a screen width of 320, SDL dies a quick death after trying to set the frame buffer to an unsupported mode. In gdb, breaking on qemu_console_resize and setting width=320 is enough to make qemu boot. I have been unable to direct keyboard input at the emulated system, but that is a battle for another day. Unlike in graphics_console_init, It does not seem that width is hardcoded to 640. One would think it would be easy enough to find out where qemu_console_resize is getting called from, but all gdb will give me as a backtrace is the following: #0 qemu_console_resize (ds=0x88e008, width=640, height=480) at console.c:1424 #1 0x00147cec in __stl_mmu (addr=3363889180, val=6185, mmu_idx=0) at ../softmmu_template.h:214 #2 0x01303708 in ?? () Using grep and some well placed printf()s, I've narrowed down my search to pl110_resize in pl110.c. which is called from pl110_write(). The PL110 is a color LCD controller. This seems to agree with the info I can get from gdb. Frame 1 points to this at line 214 of softmmu_template.h: io_mem_write[index][SHIFT](io_mem_opaque[index], physaddr, val); in a function called glue(). I believe the function pointer to pl110_resize is stored in io_mem_write with the call cpu_register_io_memory() from pl110_init(). What this all looks like is a call to mmapped IO to manipulate the screen. If you look at the call to pl110_write, val is used to set the width and height (but not at the same time) for pl110_resize. val is of course passed into glue() in soft_mmu.h and I cannot find out where glue is being called from. glue() is also an inline function, which might affect gdb in ways I don't fully know about. If any of you guys have a deeper understanding of either qemu or gdb than I do, perhaps you can point me in the right direction. Best, -David
