grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clean patch for i386-qemu port (Re: [PATCH] i386-qemu port)


From: Robert Millan
Subject: Re: clean patch for i386-qemu port (Re: [PATCH] i386-qemu port)
Date: Tue, 23 Jun 2009 13:38:50 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]