From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1JAP0M-0007Ve-6E for mharc-grub-devel@gnu.org; Thu, 03 Jan 2008 07:16:58 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAP0K-0007VV-BU for grub-devel@gnu.org; Thu, 03 Jan 2008 07:16:56 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAP0H-0007VI-RI for grub-devel@gnu.org; Thu, 03 Jan 2008 07:16:55 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAP0H-0007VF-ME for grub-devel@gnu.org; Thu, 03 Jan 2008 07:16:53 -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 1JAP0E-0003wG-62; Thu, 03 Jan 2008 07:16:50 -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 1JAOzD-0006ky-IN; Thu, 03 Jan 2008 13:15:48 +0100 Received: from rmh by thorin with local (Exim 4.63) (envelope-from ) id 1JAOum-00020B-7C; Thu, 03 Jan 2008 13:11:12 +0100 Date: Thu, 3 Jan 2008 13:11:12 +0100 From: Robert Millan To: Pavel Roskin Message-ID: <20080103121112.GB6169@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080103030917.jl75lsuhkc8gk4w8@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: The development of GRUB 2 , 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 12:16:56 -0000 On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote: > Quoting Robert Millan : > > >just take the grub-mkimage.c part of it and try to revert it on CVS HEAD, > >that would confirm it's a grub-mkimage problem. Then apply the hunks > >selectively untill you find the exact change that broke it. And finally > >it's just a matter of "looking hard" at that hunk untill it's coerced to > >reveal the problem :-) > > OK, here's what I have so far. The patch tries to make the memory > layout more compact. Two changes are make to the layout. kernel.elf > is loaded at 64k instead of 2M and the modules are loaded at the > lowest 4k boundary after kernel.elf rather that at 3M. > > Moving the kernel.elf load address is fine. Moving the modules is not. > > 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 ? I thought _end was calculated by the ELF loader (our own ELF loader, multiboot.c seems to calculate _end and pass it to its payload). > One problem in grub-mkimage is the infamous build ID, which is present > in kernel.elf. It is located in a loadable segment starting at > 0x10000d4 (i.e. just about 256M). That's what confuses objcopy, and > it must be confusing grub-mkimage as well. Isn't build ID a recent change in binutils? We had this problem for a while. > I actually doubt that it's the right behavior to go through segments. No idea about that I'm afraid :-( > Linux style description. The first line is the synopsis. If it > doesn't fit 72 characters, the patch is a candidate for splitting. > Then an empty line. Then a more detailed description of the patch, > including the motivation behind the changes. The list of the affected > files can be generated by the version control system. Looks good. But I guess you'll have to convince Marco and Okuji about this :-) > The linear ChangeLog with everybody changing it in the same place (in > the beginning) doesn't work well with parallel development. It's not that much of a problem, I just write them in the patch header and copy them at the last minute before commit. > >>disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'. > >>disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00. > >>kern/disk.c:299: Opening `ide1/disk' failed. > >>kern/disk.c:312: Closing `ide1/disk'. > > > >This seems to be contradictory. If OF returned a handle, why does the > >open fail ? Looks like GRUB doesn't like something but isn't telling you > >what. I'd investigate that part; at the least it can mean our error > >handling isn't good enough. > > Actually, there are no "failures" with the version from 2007-02-20. Does a snapshot from 2007-02-21 also have this 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. -- 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 /.)