[Top][All Lists]

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

Re: Testing on PowerMac G4

From: Pavel Roskin
Subject: Re: Testing on PowerMac G4
Date: Thu, 03 Jan 2008 10:28:46 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)

Quoting Robert Millan <address@hidden>:

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.

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_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);

One problem in grub-mkimage is the infamous build ID, which is present
in kernel.elf.  It is located in a loadable segment starting at
0x10000d4 (i.e. just about 256M).  That's what confuses objcopy, and
it must be confusing grub-mkimage as well.

Isn't build ID a recent change in binutils?  We had this problem for a while.

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.

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.

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.

Linux style description.  The first line is the synopsis.  If it
doesn't fit 72 characters, the patch is a candidate for splitting.
Then an empty line.  Then a more detailed description of the patch,
including the motivation behind the changes.  The list of the affected
files can be generated by the version control system.

Looks good. But I guess you'll have to convince Marco and Okuji about this :-)

Sure, it's in my TODO list :)

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.

Pavel Roskin

reply via email to

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