Re: Testing on PowerMac G4

[Robert Millan <rmh@aybabtu.com>]

On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >>The module base address is calculated separately in kernel.elf and in
> >>grub-mkimage.  kernel.elf uses the "_end" symbol, whereas grub-mkimage
> >>looks for the ELF segment with the highest end address.
> >
> >Ok, so you mean this setting:
> >
> >  phdr->p_vaddr = grub_host_to_target32 (modbase);
> >  phdr->p_paddr = grub_host_to_target32 (modbase);
> >
> >is not what it's used to calculate _end ?
> 
> OK, it turns out the values of _end actually match, so it's not a problem.
> 
> It turns out there needs to be a gap between _end and the module base.  
>  16k (0x4000) is not enough.  32k (0x8000) is enough.

Why?  Does the firmware impose this restriction, or is it GRUB itself that
gets confused?

> This patch against the current CVS version fixes loading:
> 
> diff --git a/kern/powerpc/ieee1275/init.c b/kern/powerpc/ieee1275/init.c
> index 4727d7d..d2fa980 100644
> --- a/kern/powerpc/ieee1275/init.c
> +++ b/kern/powerpc/ieee1275/init.c
> @@ -231,5 +231,5 @@ grub_get_rtc (void)
>  grub_addr_t
>  grub_arch_modules_addr (void)
>  {
> -  return ALIGN_UP(_end, GRUB_MOD_ALIGN);
> +  return ALIGN_UP(_end + 0x8000, GRUB_MOD_ALIGN);
>  }
> diff --git a/util/elf/grub-mkimage.c b/util/elf/grub-mkimage.c
> index 9e44af1..c39717a 100644
> --- a/util/elf/grub-mkimage.c
> +++ b/util/elf/grub-mkimage.c
> @@ -228,6 +228,7 @@ add_segments (char *dir, FILE *out, int chrp, char  
> *mods[])
>        phdr->p_offset = grub_host_to_target32 (ALIGN_UP  
> (grub_util_get_fp_size (out),
>  						   sizeof (long)));
> 
> +      modbase += 0x8000;
>        load_modules (modbase, phdr, dir, mods, out);
>      }

This might differ from the init.c counterpart.  There's an ALIGN_UP just
a few lines above, if you set it to:

  modbase = ALIGN_UP(grub_end + 0x8000, GRUB_MOD_ALIGN);

both alignment and 0x8000 gap are still garanteed, without claiming more
space than necessary.

That is, if it really is a gap that you need :-)

> I haven't looked at binutils yet.  Anyway, the problem doesn't exist  
> with the current grub code because it suppressed build ID on  
> kernel.elf.  My workaround to get older grub compiled didn't actually  
> strip build ID, it just fooled the objcopy test.

Ah, ok.

> But it would be great to detect and skip the segment corresponding to  
> the build ID in grub-mkimage, just to make it more robust.

Can we make this work per inclusion rather than exclusion?  The names
of needed segments are well-known, right?

> >>I actually doubt that it's the right behavior to go through segments.
> >
> >No idea about that I'm afraid :-(
> 
> We need to figure out why the extra gap is needed.  Maybe something  
> doesn't get counted.

Yep.  How did you find that an extra gap solves the problem?

> >>But maybe it's because in the normal mode with all modules loaded,
> >>unlike bare kernel.elf.
> >
> >But you don't need modules for ofdisk to work, it's built into the kernel.
> 
> Just going to the rescue mode with the "rescue" command won't cause  
> those hidden failures.  It seems like they are caused by some missing  
> module.  I need to look into it.

It might be simpler than this.  If you check what is the code flow between
those two:

disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
kern/disk.c:299: Opening `ide1/disk' failed.

that'll give more details.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call, if you are unable to speak?
(as seen on /.)