grub_machine_fini

grub_machine_fini

[Yoshinori K. Okuji]

I added a new function grub_machine_fini which is an arch-specific 
function. This function is not called automatically, and used only for 
grub-emu at the moment. I implemented this function for grub-emu and 
PC.

This function should be implemented for all architectures, and should be 
called before GRUB exits. I think it is unnecessary to call this 
function from reboot or halt, because the machine should be reset 
completely in this case. So this should be called maybe only from boot.

BTW, I disabled SIGINT in grub-emu, because I wanted to let grub-emu 
catch C-c. When you want to quit grub-emu, you can use halt or reboot 
(or C-\).

Okuji

Re: grub_machine_fini

[Marco Gerards]

"Yoshinori K. Okuji" <okuji@enbug.org> writes:

> I added a new function grub_machine_fini which is an arch-specific 
> function. This function is not called automatically, and used only for 
> grub-emu at the moment. I implemented this function for grub-emu and 
> PC.
>
> This function should be implemented for all architectures, and should be 
> called before GRUB exits. I think it is unnecessary to call this 
> function from reboot or halt, because the machine should be reset 
> completely in this case. So this should be called maybe only from boot.

This sounds useful.  On the PPC this should be used to free memory, I
think.  I don't think this is required for linux, so it is not
implemented yet.

> BTW, I disabled SIGINT in grub-emu, because I wanted to let grub-emu 
> catch C-c. When you want to quit grub-emu, you can use halt or reboot 
> (or C-\).

In that case, I assume, all memory should have been free'ed.  If
valgrind would work for grub-emu we could make sure that there are no
memory leaks.

Valgrind does not work because of this bug:
http://bugs.kde.org/show_bug.cgi?id=69511

If someone can get some memory tester to work with grub-emu, I will be
very happy.  I did not succeed in getting something to work yet.

Thanks,
Marco

Re: grub_machine_fini

[Hollis Blanchard]

On Feb 15, 2005, at 2:41 PM, Marco Gerards wrote:

> "Yoshinori K. Okuji" <okuji@enbug.org> writes:
>
>> I added a new function grub_machine_fini which is an arch-specific
>> function. This function is not called automatically, and used only for
>> grub-emu at the moment. I implemented this function for grub-emu and
>> PC.
>>
>> This function should be implemented for all architectures, and should 
>> be
>> called before GRUB exits. I think it is unnecessary to call this
>> function from reboot or halt, because the machine should be reset
>> completely in this case. So this should be called maybe only from 
>> boot.
>
> This sounds useful.  On the PPC this should be used to free memory, I
> think.  I don't think this is required for linux, so it is not
> implemented yet.

I discovered that this was the source of my boot failures. This is 
PPC's grub_machine_fini:
void
grub_machine_fini (void)
{
   grub_ofdisk_fini ();
   grub_console_fini ();

   grub_ieee1275_release (grub_heap_start, grub_heap_len);
   /* XXX Release memory claimed for Old World firmware.  */
}

The thing is, modules were loaded into heap memory. When we "release" 
that memory, Apple OF (remember, running in translated mode) unmaps it 
or makes it otherwise inaccessible. The very next function called after 
grub_machine_fini is the boot function pointer, which points into a 
module. Some sort of exception occurs (probably a "missing instruction 
mapping"), causing OF to fall over (and it's impossible to get any 
debug info).

In other words, either:
- the boot function must be part of the core, not in a module
- or we cannot release heap memory

If we remove the release call, then all that's left are those two _fini 
calls, which do almost nothing themselves. Also, we may want to print 
debug messages after this point, so grub_console_fini doesn't make 
sense here (luckily it doesn't actually stop grub_printf from 
working)...

So I'm not sure how to use grub_machine_fini properly...?

The good news is that when I comment out the release call, I can boot 
Linux again.

-Hollis

Re: grub_machine_fini

[Marco Gerards]

Hollis Blanchard <hollis@penguinppc.org> writes:

> The thing is, modules were loaded into heap memory. When we "release"
> that memory, Apple OF (remember, running in translated mode) unmaps it
> or makes it otherwise inaccessible. The very next function called
> after grub_machine_fini is the boot function pointer, which points
> into a module. Some sort of exception occurs (probably a "missing
> instruction mapping"), causing OF to fall over (and it's impossible to
> get any debug info).
>
> In other words, either:
> - the boot function must be part of the core, not in a module
> - or we cannot release heap memory

This is, AFAIK, already the case.  From kern/loader.c:

grub_err_t
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  grub_machine_fini ();
  
  return (grub_loader_boot_func) ();
}

So grub_machine_fini and the call to the loader are both in the core.
The main problem is the loader itself is not.  The
grub_loader_boot_func is a function pointer to the boot function of
the active loader.

> If we remove the release call, then all that's left are those two
> _fini calls, which do almost nothing themselves. Also, we may want to
> print debug messages after this point, so grub_console_fini doesn't
> make sense here (luckily it doesn't actually stop grub_printf from
> working)...
>
> So I'm not sure how to use grub_machine_fini properly...?
>
> The good news is that when I comment out the release call, I can boot
> Linux again.

So the best thing to do is commenting this out in CVS and thinking
about a better solution.


How about this... I assume every loader on the PPC is just a call to
some address with some arguments.  Before that call is made some stuff
is set up.  For example the linux loaders sets up bootargs.  So what
we can do is change the boot function so it does not make the actual
call and just prepares for that.  The loader specific boot function
could return some information about the address that kern/load.c
should jump to and how to set up the arguments, etc.

So if we implement this, the loader can be properly unloaded after it
did the set up.  So the new function would look, basically, like this:

grub_err_t
grub_loader_boot (void)
{
  if (! grub_loader_loaded)
    return grub_error (GRUB_ERR_NO_KERNEL, "no loaded kernel");

  grub_loader_boot_func (&bootinfo);

  grub_machine_fini ();

  ... some code to boot the machine using bootinfo ...
}


Of course it will not work like this if bootinfo is stored on the
heap.  So you could use alloca or something like that.  But I hope you
understand the basic idea.

What do you think?

Thanks,
Marco