grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PPC64


From: Manoel
Subject: Re: PPC64
Date: Fri, 24 Oct 2008 19:53:21 -0200

Changing the load-base worked in the P5 machine but when I tested in the
P6 machine I got the following message:
        Relocation overflow
In function  grub_arch_dl_relocate_symbols.
It means that I'm lacking memory?


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 Brazil





reply via email to

[Prev in Thread] Current Thread [Next in Thread]