From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.33) id 1CaGXg-0002TO-5A for mharc-grub-devel@gnu.org; Fri, 03 Dec 2004 11:44:24 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CaGXe-0002TI-Cb for grub-devel@gnu.org; Fri, 03 Dec 2004 11:44:22 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CaGXd-0002T6-MY for grub-devel@gnu.org; Fri, 03 Dec 2004 11:44:22 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CaGXd-0002T3-KF for grub-devel@gnu.org; Fri, 03 Dec 2004 11:44:21 -0500 Received: from [145.74.66.11] (helo=mail-cn.han.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CaGNe-0000h5-JD for grub-devel@gnu.org; Fri, 03 Dec 2004 11:34:03 -0500 Received: from localhost (charlie.han.nl [145.74.66.9]) by mail-cn.han.nl (Postfix) with ESMTP id 4752AAB5A for ; Fri, 3 Dec 2004 17:11:56 +0100 (CET) Received: from mail-cn.han.nl ([145.74.66.11]) by localhost (charlie.han.nl [145.74.66.9]) (amavisd-new, port 10024) with ESMTP id 28919-05 for ; Fri, 3 Dec 2004 17:11:54 +0100 (CET) Received: from mail1.han.nl (mail1.han.nl [145.74.103.11]) by mail-cn.han.nl (Postfix) with ESMTP id 2C0C9AB47 for ; Fri, 3 Dec 2004 17:11:54 +0100 (CET) Received: from marco.marco-g.com (mgerards.xs4all.nl [82.92.27.129]) by mail1.han.nl (Postfix) with ESMTP id DA0F2C04F for ; Fri, 3 Dec 2004 17:11:53 +0100 (CET) Mail-Copies-To: metgerards@student.han.nl To: The development of GRUB 2 References: <20041203053646.GA22463@miracle> <87mzwvlf4o.fsf@marco.marco-g.com> <95B8E280-453E-11D9-A999-000A95A0560C@penguinppc.org> From: Marco Gerards Date: Fri, 03 Dec 2004 16:10:45 +0000 In-Reply-To: <95B8E280-453E-11D9-A999-000A95A0560C@penguinppc.org> (Hollis Blanchard's message of "Fri, 3 Dec 2004 09:18:28 -0600") Message-ID: <871xe7l5ve.fsf@marco.marco-g.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new@vscan-cn.han.nl Subject: Re: [ppc patch] grub-mkimage 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: Fri, 03 Dec 2004 16:44:22 -0000 Hollis Blanchard writes: >>> It may be possible to place module variables into their own section >>> containing nothing else, yet still in a LOAD segment. Then >>> grub-mkimage >>> could parse the *section* table (right now it only does segments) and >>> overwrite the contents of this section to inform the runtime of the >>> module location. I'm not convinced it's worth the effort. >> >> Whatever is the most flexible seems the best to me... > > I was aiming for simplicity really... What's the simplest possible way > we can inform grubof of the location of its modules? :) The solution with the other LOAD segment sounded the cleanest to me. The one that assumed it would follow immediately after the rest of GRUB sounded a bit hard to me. I mean, can you really rely on such assumptions? >> AS Hollis said, I'm working on the relocator for PPC at the moment. >> It is quite easy, but PPC_REL24 is a bit more complex. It is used for >> relative jumps. That means the module should be loaded close to >> grubof, which IMHO really sucks... > > 24-bit offsets give you a 16 MiB range, is that really a problem? The modules are loaded into the free memory of grubof. And grubof is loaded to where it is linked, IIRC. So I think that would cause problems. :) >> I am now trying to get option 2 to work first (by using black magic to >> get everything loaded at the right address ;)) and when module loading >> works for me I will try to make 3 work. > > I agree this makes sense. I'm not sure that option 3 will end up being > necessary, but option 2 is obviously needed. Right, and it is finished now. I am quite sure it is required, but we can test it. >> Does someone else think I >> try to do something else, or can someone help a bit somehow? As you >> might have noticed I really suck at this stuff and doing it just >> because no one else does. ;) > > I've never seen relocation code before, but if it's still not working > when I get back I'd be happy to take a look... Cool. Thanks, Marco