Re: grub-install on powermac newworld

[Mike Small]

On Thu, Nov 17, 2005 at 12:05:00AM -0600, Hollis Blanchard wrote:
...
> > I didn't really exercise the nvsetenv part of the script since I've
> > had problems setting the boot device on this machine before (466
> > Powermac G4 - it seems to want to add ,\\:tbxi to whatever
> > boot-device string I set)
> 
> Are you sure it's not ybin trying to do that? I would be very surprised
> if nvsetenv or OF itself do.

I was confused here.  What I thought was the appended string was
hd:,\\:tbxi and it was only the next column over in the openfirmware
printenv output, showing the factory defaults.  I was fooled because
the long device string pushed the columns out of alignment.  Sorry
about that.

I tried testing the nvsetenv part of grub-install and it almost
worked.  There's a problem with the regex that pulls off the partition
number from a device file name.  If you have more than one digit in
your partition (mine was at /dev/hda11) it only grabs the last one
because of greedy matching on .*.  I included a fix for this in the
attached patch.

> > After I moved the files from /mnt/boot/grub to the root of my boot
> > partition (which is hfs) and rebooted, grub seemed to work okay (more
> > than okay really, I love that you can cat files from the bootloader -
> > neat stuff) until I typed in an initrd command.  Then I got the error
> > message: "Can not claim memory."  This was with a backported 2.6.12
> > kernel from a debian developer's site (Sven Luther) but the same thing
> > happened with the standard Sarge 2.6.8 kernel.  The kernel was 4641711
> > bytes and the initrd image was 4820992 bytes.
...

> grub_claimmap is a call to firmware to request access to a particular
> area of memory. Trying to access memory without it could result in
> scribbling over memory somebody else (e.g. OF itself) is using, or could
> result in a page fault because it wasn't mapped.
> 
> Two related notes: I believe Marco mentioned that we should keep
> attempting to find a space for the initrd. We do this already for the
> kernel (notice the for loop around the other grub_claimmap call), but
> not yet for initrd.

This worked for me, and I've enclosed a patch with the a similar loop
to the one used for the linux command.  It also has debugging messages
before the grub_claimmap calls.  

I'm wondering though, does it matter very much how grub grabs memory?
Once the operating system takes over it takes all of memory and
whatever grub allocated doesn't matter anymore.  Is that correct?  The
reason I ask is that I tried making that loop retry the claim at every
4 bytes instead of at every megabyte and found it settled on an
address only four bytes higher than the one it failed on.  So maybe
it's possible to be more precise than the code in this patch is.

My guess would be that open firmware allocates with a resolution of 8
bytes, at least on my machine.  In that second test, the address that
the grub_claimmap failed on was 1b99F84 and the one it succeeded on
was 1b99F88.  1b99F84 was the exact end of the space allocated by the
linux command (at 1400000, size 799f84), so if o.f. grabbed in 8 bytes
increments it would have had up to 1b99F88, causing the failure.
Plausible?

-- 
Mike Small
address@hidden

initrdclaim.patch
Description: Text document