From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JASXN-0001ks-23 for mharc-grub-devel@gnu.org; Thu, 03 Jan 2008 11:03:17 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JASXL-0001i5-JV for grub-devel@gnu.org; Thu, 03 Jan 2008 11:03:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JASXK-0001gZ-PX for grub-devel@gnu.org; Thu, 03 Jan 2008 11:03:15 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JASXK-0001gI-MC for grub-devel@gnu.org; Thu, 03 Jan 2008 11:03:14 -0500 Received: from aybabtu.com ([69.60.117.155]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JASXK-00030I-2Q for grub-devel@gnu.org; Thu, 03 Jan 2008 11:03:14 -0500 Received: from [192.168.10.6] (helo=thorin) by aybabtu.com with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1JASW9-00076G-As; Thu, 03 Jan 2008 17:02:05 +0100 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1JASRq-0006jn-Jj; Thu, 03 Jan 2008 16:57:34 +0100 Date: Thu, 3 Jan 2008 16:57:34 +0100 From: Robert Millan To: The development of GRUB 2 Message-ID: <20080103155734.GA25410@thorin> References: <20071231031229.1ilqcnpcwkc0oww8@webmail.spamcop.net> <1199090700.15525.17.camel@peder.flower> <1199140655.7332.15.camel@dv> <20071231233451.GA6782@thorin> <20080102014604.mokv4nr54w48kcg0@webmail.spamcop.net> <20080102103218.GB4295@thorin> <20080103030917.jl75lsuhkc8gk4w8@webmail.spamcop.net> <20080103121112.GB6169@thorin> <20080103102846.mhnl7v6xw4ksk48k@webmail.spamcop.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080103102846.mhnl7v6xw4ksk48k@webmail.spamcop.net> Organization: free as in freedom X-Message-Flag: Worried about Outlook viruses? Switch to Thunderbird! www.mozilla.com/thunderbird X-Debbugs-No-Ack: true User-Agent: Mutt/1.5.13 (2006-08-11) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. Cc: Jan Nieuwenhuizen Subject: Re: Testing on PowerMac G4 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: Thu, 03 Jan 2008 16:03:16 -0000 On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote: > Quoting Robert Millan : > > >>The module base address is calculated separately in kernel.elf and in > >>grub-mkimage. kernel.elf uses the "_end" symbol, whereas grub-mkimage > >>looks for the ELF segment with the highest end address. > > > >Ok, so you mean this setting: > > > > phdr->p_vaddr = grub_host_to_target32 (modbase); > > phdr->p_paddr = grub_host_to_target32 (modbase); > > > >is not what it's used to calculate _end ? > > OK, it turns out the values of _end actually match, so it's not a problem. > > It turns out there needs to be a gap between _end and the module base. > 16k (0x4000) is not enough. 32k (0x8000) is enough. Why? Does the firmware impose this restriction, or is it GRUB itself that gets confused? > This patch against the current CVS version fixes loading: > > diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c > index 4727d7d..d2fa980 100644 > --- a/kern/powerpc/ieee1275/init.c > +++ b/kern/powerpc/ieee1275/init.c > @@ -231,5 +231,5 @@ grub_get_rtc (void) > grub_addr_t > grub_arch_modules_addr (void) > { > - return ALIGN_UP(_end, GRUB_MOD_ALIGN); > + return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN); > } > diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c > index 9e44af1..c39717a 100644 > --- a/util/elf/grub-mkimage.c > +++ b/util/elf/grub-mkimage.c > @@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char > *mods[]) > phdr->p_offset = grub_host_to_target32 (ALIGN_UP > (grub_util_get_fp_size (out), > sizeof (long))); > > + modbase += 0x8000; > load_modules (modbase, phdr, dir, mods, out); > } This might differ from the init.c counterpart. There's an ALIGN_UP just a few lines above, if you set it to: modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN); both alignment and 0x8000 gap are still garanteed, without claiming more space than necessary. That is, if it really is a gap that you need :-) > I haven't looked at binutils yet. Anyway, the problem doesn't exist > with the current grub code because it suppressed build ID on > kernel.elf. My workaround to get older grub compiled didn't actually > strip build ID, it just fooled the objcopy test. Ah, ok. > But it would be great to detect and skip the segment corresponding to > the build ID in grub-mkimage, just to make it more robust. Can we make this work per inclusion rather than exclusion? The names of needed segments are well-known, right? > >>I actually doubt that it's the right behavior to go through segments. > > > >No idea about that I'm afraid :-( > > We need to figure out why the extra gap is needed. Maybe something > doesn't get counted. Yep. How did you find that an extra gap solves the problem? > >>But maybe it's because in the normal mode with all modules loaded, > >>unlike bare kernel.elf. > > > >But you don't need modules for ofdisk to work, it's built into the kernel. > > Just going to the rescue mode with the "rescue" command won't cause > those hidden failures. It seems like they are caused by some missing > module. I need to look into it. It might be simpler than this. If you check what is the code flow between those two: disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. kern/disk.c:299: Opening `ide1/disk' failed. that'll give more details. -- Robert Millan I know my rights; I want my phone call! What use is a phone call, if you are unable to speak? (as seen on /.)