Re: PPC64

[Hollis Blanchard <hollisb@us.ibm.com>]

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.

-- 
Hollis Blanchard
IBM Linux Technology Center