That's awsome. The next thing is to try kvmtest on the physical device. You can use the main branch (I think). We'll sit down Wednesday and compile some detailed instructions. /Andreas Citerar David Albert <dba2104 at columbia.edu>: > 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 >> > > _______________________________________________ > Android-virt mailing list > Android-virt at lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/android-virt > >
