Re: [patch] set prefix on PPC

[Marco Gerards <metgerards@student.han.nl>]

Hollis Blanchard <hollis@penguinppc.org> writes:

> On Feb 13, 2005, at 12:35 PM, Marco Gerards wrote:
>
>> Hollis Blanchard <hollis@penguinppc.org> writes:
>>
>>> This code sets the GRUB "prefix" environment variable from the OF
>>> /chosen/bootpath property. It must therefore translate between the two
>>> syntaxes.
>>
>> 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
> http://lists.penguinppc.org/yaboot-users/2002/yaboot-users-200210/
> msg00008.html as an example), but he doesn't like to substantiate his
> claims.

this is interesting.  We could put a warning in the manual (when
writing it), but I most certainly don't want to force people to use
some kind of partition.

> 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.)

Yeah, ok.  This is something we should not worry about at the moment.
If the HFS filesystem is broken, which I doubt, we could either fix it
or install GRUB there using a similar script.

> 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).

How is the file blessed and why does that make it a problem to keep
/boot on a HFS partition?

> 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.

No, of course not.  But I usually take warnings seriously.  And yaboot
is full of those. :)

>> 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.

Right.

>> 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.

Ok.  If we use your patch, this is not that important, I guess.  If it
works right that is.

> 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.

This might be nice someday.

>> 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  <metgerards@student.han.nl>
>>
>> 	* 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.

I don't want to add a fancy parser yet.  At the moment we just use a
single argument.  If more will be used, this code has to be changed.

>> 	* 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?

It is required to make GNU/Linux boot here, just like the bootargs
stuff. ;)

It is separated with a blank line to make clear they do not serve the
same purpose.

Thanks,
Marco