Re: State of GRUB on PowerPC

[Michel Dänzer]

On Wed, 2009-01-28 at 21:57 -0500, Pavel Roskin wrote:
> On Tue, 2009-01-27 at 08:19 +0100, Michel Dänzer 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)
> > 
> > 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.
> 
> 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änzer  <address@hidden>

        * 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  
        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. It
> > might be better to continue auto-loading other modules anyway.
> 
> 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.
> 
> 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.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer