[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 11:23:01 -0500
User-agent: Internet Messaging Program (IMP) H3 (4.1.4)

Quoting Robert Millan <address@hidden>:

On Thu, Jan 03, 2008 at 10:28:46AM -0500, Pavel Roskin wrote:
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 ?

I can answer it now. No, it's not used to calculate _end, it needs to be incremented separately.

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?

I wish I knew it. 0x7000 is not OK, 0x8000 is OK. Less granularity makes no sense since the value is aligned at the 0x1000 boundary.

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

Thanks, that would be safer indeed, although it makes no difference for the values divisible by 0x1000.

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

Segments don't have names AFAIK. Sections have names. But anyway, it should be possible to recognize what we need. On the other hand, "work per inclusion" would make me nervous about breaking other architectures.

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?

I started with the original boundary at 0x300000, then I tried 0x30000, then _end+0xb000 (_end is something like 0x2496c), then _end+0x1000 and so on, until I found that 0x7000 is not enough and 0x8000 is enough.

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.

There is a possibility that grub_errno remains set to some error.

Pavel Roskin

reply via email to

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