Re: Testing on PowerMac G4

[Robert Millan <rmh@aybabtu.com>]

On Thu, Jan 03, 2008 at 03:09:17AM -0500, Pavel Roskin wrote:
> Quoting Robert Millan <rmh@aybabtu.com>:
> 
> >just take the grub-mkimage.c part of it and try to revert it on CVS HEAD,
> >that would confirm it's a grub-mkimage problem.  Then apply the hunks
> >selectively untill you find the exact change that broke it.  And finally
> >it's just a matter of "looking hard" at that hunk untill it's coerced to
> >reveal the problem :-)
> 
> OK, here's what I have so far.  The patch tries to make the memory  
> layout more compact.  Two changes are make to the layout.  kernel.elf  
> is loaded at 64k instead of 2M and the modules are loaded at the  
> lowest 4k boundary after kernel.elf rather that at 3M.
> 
> Moving the kernel.elf load address is fine.  Moving the modules is not.
> 
> 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 thought _end was calculated by the ELF loader (our own ELF loader,
multiboot.c seems to calculate _end and pass it to its payload).

> 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 actually doubt that it's the right behavior to go through segments.   

No idea about that I'm afraid :-(

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

> The linear ChangeLog with everybody changing it in the same place (in  
> the beginning) doesn't work well with parallel development.

It's not that much of a problem, I just write them in the patch header and
copy them at the last minute before commit.

> >>disk/ieee1275/ofdisk.c:65: Opening `ide1/disk:0'.
> >>disk/ieee1275/ofdisk.c:74: Opened `ide1/disk:0' as handle 0xff9d1c00.
> >>kern/disk.c:299: Opening `ide1/disk' failed.
> >>kern/disk.c:312: Closing `ide1/disk'.
> >
> >This seems to be contradictory.  If OF returned a handle, why does the
> >open fail ?  Looks like GRUB doesn't like something but isn't telling you
> >what.  I'd investigate that part;  at the least it can mean our error
> >handling isn't good enough.
> 
> Actually, there are no "failures" with the version from 2007-02-20.   

Does a snapshot from 2007-02-21 also have this 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.

-- 
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 /.)