On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <[EMAIL PROTECTED]>:
>
> >>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 /.)
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
