Re: PPC64

[Hollis Blanchard]

Traditionally, firmware has refused to load an ELF file without a NOTE
segment. I feel like I heard that actually changed recently (maybe in
the p5 timeframe), but I never investigated further. You could easily
test by running grub-mkimage without the -n switch.

-- 
Hollis Blanchard
IBM Linux Technology Center

On Fri, 2008-10-24 at 10:10 -0200, Manoel wrote:
> 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.
> >