Re: Testing on PowerMac G4

[Pavel Roskin]

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.

--
Regards,
Pavel Roskin