From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1DKiQx-0007Ky-Dc for mharc-grub-devel@gnu.org; Sun, 10 Apr 2005 15:49:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DKiL6-0005WM-Ax for grub-devel@gnu.org; Sun, 10 Apr 2005 15:43:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DKiKv-0005Pl-OL for grub-devel@gnu.org; Sun, 10 Apr 2005 15:43:15 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DKiKv-0005Mt-9G for grub-devel@gnu.org; Sun, 10 Apr 2005 15:43:13 -0400 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DKiiu-0007cy-Hi for grub-devel@gnu.org; Sun, 10 Apr 2005 16:08:00 -0400 Received: from vscan-cn.han.nl (venus.han.nl [145.74.65.6]) by mail-cn.han.nl (Postfix) with ESMTP id A375A87D6 for ; Sun, 10 Apr 2005 21:28:09 +0200 (CEST) Received: from mail-cn.han.nl ([145.74.66.11]) by vscan-cn.han.nl (venus.han.nl [145.74.65.6]) (amavisd-new, port 10024) with ESMTP id 23961-09 for ; Sun, 10 Apr 2005 21:28:07 +0200 (CEST) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id 817AF8783 for ; Sun, 10 Apr 2005 21:28:07 +0200 (CEST) Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id 19CEAC045 for ; Sun, 10 Apr 2005 21:28:07 +0200 (CEST) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <200502150115.56867.okuji@enbug.org> <87k6p9y2s7.fsf@marco.marco-g.com> From: Marco Gerards Date: Sun, 10 Apr 2005 21:28:07 +0200 In-Reply-To: (Hollis Blanchard's message of "Thu, 7 Apr 2005 10:31:53 -0500") Message-ID: <87r7hi8m9k.fsf@student.han.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new (2.2.0) at vscan-cn.han.nl Subject: Re: grub_machine_fini X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2005 19:49:26 -0000 Hollis Blanchard 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