Quick update: Hardcoding works just fine. QEMU now boots without any intervention. Best, -D On Apr 27, 2009, at 9:39 AM, David Albert wrote: > 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 > > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt >
