Re: PPC64

[Manoel]

I changed the load-base to 0x200000 in the note segment that mkelfimage
creates. After that grub2 found the modules info header in the correct
position (as stated in the program header) and was able to load all
modules correctly.
Maybe the Open Firmware detected the overlapping and tried to load the
segment in another place, and for some reason the data write was
corrupted.
Sounds like a OF's bug and I'll report it as you suggested. To me the
correct behavior would be load things in place and correctly even with
overlapping memory.

And about the note section, what is the point in create it with
hardcoded variables? I don't see a reason to have this note segment
unless the user want to use different variables values than the
configured in OF. 
 

Thanks for the help so far, it was very useful.
On Thu, 2008-10-23 at 14:08 -0500, Hollis Blanchard wrote:
> On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote:
> > 
> > I talked with some folks at #pppc64 on freenode an they suggest that
> > the
> > OF is loading things in the wrong place could a problem with my
> > load-base:
> > 
> >         real-base                c00000              c00000 
> >         virt-base                ffffffff            ffffffff 
> >         real-size                1000000             1000000 
> >         virt-size                ffffffff            ffffffff 
> >         load-base                4000                4000
> > 
> > they suggested to change load-base from 4000 to 200000 but I hava yet
> > to try it.  They also said that the note section can override
> > load-base (and maybe we have some problem there?)
> 
> It's possible. See below.
> 
> > I'm now reading PARP documentation to learn more about OF behavior. I
> > thought these machine were CHRP but they are actually PARP (is that
> > right?). Son only today I was able to get the correct documentation.
> 
> PAPR was based on the older CHRP specification.
> 
> > > Look at the segment list again:
> > > > Program Headers:
> > > >  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> > > >  LOAD           0x0000b4 0x00010000 0x00010000 0x0cbe4 0x14098 RWE 0x10
> > > >  GNU_STACK      0x00cc98 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
> > > >  LOAD           0x00cc98 0x0002d000 0x0002d000 0x5c1c8 0x5c1c8 RWE 0x4
> > > >  NOTE           0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R   0x4
> > > 
> > NOTE 0x068e60 0x00000000 0x00000000 0x0002c 0x00000 R 0x4
> > this line look somehow wrong. NOTE will be loaded at the address 0?
> > and will occupy no memory? that is the same as don't having NOTE at
> > all right?
> 
> NOTE is interpreted by the loader (firmware), but not actually loaded
> into memory. This is a binary structure that can be used to set some of
> the environment variables you mention above.
> 
> The NOTE segment (segment, not section) is created by
> util/elf/grub-mkimage.c . You can see that load-base is set to 0x4000 in
> that code. Since your text starts at 0x10000, that means your binary can
> be at most 0xc000 bytes (48KB) large before it overlaps the text area.
> That isn't necessarily a problem; firmware is probably using memmove()
> (which handles overlapping areas) to load the segments into place.
> 
> It's probably worth trying a different load-base to see if that could be
> the problem here.
> 
-- 
Best Regards,

Manoel Abranches <address@hidden>
IBM Linux Technology Center Brasil