On Mon, Jun 22, 2009 at 09:29:41PM -0400, Pavel Roskin wrote: > On Tue, 2009-06-23 at 01:07 +0200, Robert Millan wrote: > > This is my first "clean" (kludge-free) patch for the i386-qemu port. It > > doesn't depend on any other patch; I send it for some final review before > > checking it in. > > In some cases, "2" appears on the command line. Perhaps the initial > keyboard state is not cleared.
I can't reproduce this, but we can flush the keyboard on startup. Do you mind if we discuss this after base qemu support is merged? > If I use all modules, the image is too big: > grub-mkimage: error: Core image is too big (0xa8200 > 0xa0000) Strange, with all modules I get 0x88200. Anyway, GRUB_MEMORY_MACHINE_UPPER can be increased up to GRUB_BOOT_MACHINE_LINK_ADDR, this was just copied from the coreboot port. With GRUB_BOOT_MACHINE_LINK_ADDR (0xffe00) you should be able to fit all of GRUB in. Increasing it further would involve either compression or breaking the 0x100000 barrier (imposed by the Linux loader). I think compression for qemu is just silly, but fixing the Linux loader is not trivial (Vladimir's memory management proposal could help on this). > If I exclude lua.mod, I can build the image, but it fails in qemu with > the message "no module name found". Removing udf.mod helps. Likewise, > removing several other modules helps. I believe memory is corrupted if > there are too many modules. I get memory corruption too. I'll have a look. > And it appears on the new line every time a key is pressed. I believe > grub_exit() should call grub_halt() for i386-coreboot and i386-qemu. Is grub_halt() really what we want? grub_exit() callers expect that the user doesn't lose access to the machine when this function is invoked. How about grub_reboot() instead? -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
