[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] set prefix on PPC

From: Hollis Blanchard
Subject: Re: [patch] set prefix on PPC
Date: Sun, 13 Feb 2005 13:52:48 -0600

On Feb 13, 2005, at 12:35 PM, Marco Gerards wrote:

Hollis Blanchard <address@hidden> writes:

This code sets the GRUB "prefix" environment variable from the OF
/chosen/bootpath property. It must therefore translate between the two

Personally I don't like setting prefix to the path grubof was loaded
from.  Mainly because of the way how things work on the macintosh.  It
has a special HFS[+] boot partition (at least my installation, but I
think this is the common practice).

I don't like installing all modules and the configuration file on this
partition.  There were some problems with writing to this partition
IIRC and it is not comfortable to use.  It should not be touched by a
user, I just can't remember why.  I will look that up.

Please let me know if you find any actual data. I have heard the ybin author rant about this for years (see msg00008.html as an example), but he doesn't like to substantiate his claims.

I believe there were two problems with keeping /boot on an HFS partition: 1) The Linux HFS driver wasn't overly reliable. That's unfortunate if you're writing a kernel there, or editing grub.cfg. For that reason, /boot is typically kept as a Linux-native filesystem, and to install a kernel ybin invokes hfsutils to do the copying to the "bootstrap" partition. (Note the similarity in names "boot" and "bootstrap" causes confusion.) 2) HFS has a concept called "blessed"; basically the firmware can automatically find and boot blessed executables without needing to specify a file name or even partition. Some versions of Mac OS allegedly will unbless a non-Mac OS blessed file. For that reason, ybin prefers the HFS "bootstrap" partition be of a type that Mac OS will not mount (and so will not alter).

However, please do not mistake "this is how ybin does it" for "this is the only way to do it". I have never seen these problems (though I personally ran an HFS /boot partition that Mac OS mounted), and I have never seen data as to what exact software versions or scenarios cause a problem. The user in the URL above claims no problems either, and I haven't heard of other users with these problems.

What I would prefer is a way to encode the prefix into the grubof
binary.  The only disadvantage is that it might be hard to detect this
install time.

If possible, placing grub.cfg next to grubof will be the easiest solution. That way, no matter how or where you boot GRUB (even from rescue CD or whatever), you will always know what grub.cfg it will load.

Example: you're making a distribution installer and need to boot from CD. What prefix do you embed in GRUB? There is no guarantee that every machine out there has a "cd" devalias, nor would you want to require users to create that in OF before booting. Simply looking adjacent to the grubof binary is a much better solution.

What I would prefer is this:

1)  Set prefix to whatever was set in the binary.

This would involve more post-compilation ELF manipulation. To accomplish that, if we do decide to go that route, I think it would be worth converting the existing module segment into a more general-purpose segment, containing all the added arguments.

Remember, right now we load modules at a fixed address. At runtime, GRUB finds at that address:
1. the size of the modules in memory
2. the module binaries

We can change this to be more general-purpose, e.g. a chain or "parameter" structures that could contain the module binaries, the size of modules, the prefix, etc.

2)  If nothing was set, use `bootpath'.

So it's not such a bad idea after all huh? :)

3)  Read the arguments and if a prefix was passed to GRUB, use it to
    override the prefix.

For #3 I wrote a patch, but I forgot to send it to grub-devel... It's
included with this email.  As far as I am concerned #1 is what is
really important for us.

2005-02-13  Marco Gerards  <address@hidden>

        * kern/powerpc/ieee1275/init.c (grub_machine_init): Initialize the
        prefix env variable with the bootargs when it has a valid value.

I don't like that this assumes bootargs only contains the prefix. For example, if we ever get our fancy debugging support, it would be very nice to boot grub with "debug=all" as an argument.

        * loader/powerpc/ieee1275/linux.c (grub_rescue_cmd_linux): Don't
        initialize `init_addr' yet, set it to 0 instead.

Confused... how is this related to bootargs and prefix?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]