From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LSZay-00015T-QX for mharc-grub-devel@gnu.org; Thu, 29 Jan 2009 11:18:24 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSZat-00012F-Tn for grub-devel@gnu.org; Thu, 29 Jan 2009 11:18:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSZap-000118-2G for grub-devel@gnu.org; Thu, 29 Jan 2009 11:18:18 -0500 Received: from [199.232.76.173] (port=44930 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSZan-00010m-Kb for grub-devel@gnu.org; Thu, 29 Jan 2009 11:18:14 -0500 Received: from darkcity.gna.ch ([195.226.6.51]:47910 helo=mail.gna.ch) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSZan-0007gD-A2 for grub-devel@gnu.org; Thu, 29 Jan 2009 11:18:13 -0500 Received: from localhost (localhost [127.0.0.1]) by darkcity.gna.ch (Postfix) with ESMTP id 1745DC32AB for ; Thu, 29 Jan 2009 17:18:08 +0100 (CET) X-Virus-Scanned: amavisd-new at gna.ch Received: from mail.gna.ch ([127.0.0.1]) by localhost (gna.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qNi+f1lU+rmy for ; Thu, 29 Jan 2009 17:18:07 +0100 (CET) Received: from thor.local (84-75-214-119.dclient.hispeed.ch [84.75.214.119]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by darkcity.gna.ch (Postfix) with ESMTPSA id 9F3FBC32AA for ; Thu, 29 Jan 2009 17:18:07 +0100 (CET) Received: from daenzer by thor.local with local (Exim 4.69) (envelope-from ) id 1LSZag-0006SZ-Oq for grub-devel@gnu.org; Thu, 29 Jan 2009 17:18:06 +0100 From: Michel =?ISO-8859-1?Q?D=E4nzer?= To: The development of GRUB 2 In-Reply-To: <1233197867.2727.39.camel@dv> References: <1233040781.5108.98.camel@thor.local> <1233197867.2727.39.camel@dv> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jan 2009 17:18:06 +0100 Message-Id: <1233245886.10368.110.camel@thor.local> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: State of GRUB on PowerPC 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, 29 Jan 2009 16:18:20 -0000 On Wed, 2009-01-28 at 21:57 -0500, Pavel Roskin wrote: > On Tue, 2009-01-27 at 08:19 +0100, Michel D=C3=A4nzer wrote: > > I was able to reproduce Jordi's findings on my PowerBook G4. (Well, > > except device.map seems to get generated correctly and the search > > command seems to work for me, maybe this is due to differences between > > our OF device trees or something like that) > >=20 > > After some printf-style debugging over the weekend, the failure to load > > some modules indeed turns out to be an hfs.mod bug: the problem is that > > strncasecmp() doesn't match the HFS B-tree sort order, which in > > particular breaks lookup of files with an underscore in their name. The > > first attached patch fixes this using a lookup table from Linux > > fs/hfs/string.c. >=20 > Actually, the return value of grub_strncasecmp() was incorrect until > recently. Maybe the current version would work for you? Unfortunately not; I verified with a simple program that the glibc strncasecmp() also has a different order between underscore and characters. The HFS sort order seems quite peculiar. > I'm not against your patch, but I'd like to understand how important it > is for GRUB. The failure to look up some files on HFS filesystems makes it hard for most PowerPC Mac Linux users to switch from yaboot to GRUB. > Please write a ChangeLog entry for the patch. How about this: 2009-01-29 Michel D=C3=A4nzer * fs/hfs.c (grub_hfs_cmp_catkeys): Use lookup table for HFS B-tree sort order. Otherwise we fail to look up some files, e.g. with an underscore in the name, so e.g. the _linux module =20 can't be loaded from an HFS filesystem. > > The failure to auto-load some modules like search was also caused by > > this, the auto-loading process aborts after failing to load a module. I= t > > might be better to continue auto-loading other modules anyway. >=20 > Patches are welcome. With explanations, please. Just tossing out an idea. > > BTW, I also need the second attached patch to be able to boot my > > self-built 32 bit kernels configured to support 2GB lowmem. > > elf->ehdr.ehdr32.e_entry ends up as 0x70000000. >=20 > Strange. The original mask should ensure that elf->ehdr.ehdr32.e_entry > is less than 0x40000000. Right, that's the problem. :) Apparently the kernel's early boot code relies on it remaining unchanged. --=20 Earthling Michel D=C3=A4nzer | http://www.vmware.c= om Libre software enthusiast | Debian, X and DRI developer