[Top][All Lists]

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

Re: PPC64

From: Manoel
Subject: Re: PPC64
Date: Tue, 21 Oct 2008 14:43:25 -0200

Hi Hollis,

On Mon, 2008-10-20 at 14:32 -0500, Hollis Blanchard wrote: 
> On Mon, 2008-10-20 at 17:18 -0200, Manoel wrote:
> > 
> > I'm working in a project to use grub2 to boot some ppc machines(p6 , p5
> > and so on) and we had some difficulties with a grub modules problem.
> > Grub fails to load modules.
> > 
> > When debugging I noted that grub try to find the headerinfo modules
> > struc (which is identified by the magic number 0x676d696d) in the
> > address 0x2d000 (_end + gap aligned in 4k blocks).
> > but this address does not contains the headerinfo.
> > 
> > So i altered the source code such as the memory is searched to find the
> > magic number. It is then found at address 0x38f4c and then grub find
> > some modules (but fails after) has showed in attachment grub2.txt.
> ...
> ../kern/dl.c:527: module at 0x3e0dc, size 0xc9c
> ../kern/dl.c:556: relocating to 0x28720
> ../kern/dl.c:513: flushing 0x4 bytes at 0x28190
> ../kern/dl.c:513: flushing 0x14 bytes at 0x281d0
> ../kern/dl.c:513: flushing 0x68 bytes at 0x28220
> ../kern/dl.c:513: flushing 0x410 bytes at 0x282c0
> ../kern/dl.c:570: module name: amiga
> ../kern/dl.c:571: init function: 0x282c0
> ../kern/dl.c:527: module at 0x3ed84, size 0xe28
> ../kern/dl.c:556: relocating to 0x280a0
> ../kern/dl.c:513: flushing 0x4 bytes at 0x27a30
> ../kern/dl.c:513: flushing 0x14 bytes at 0x27a70
> ../kern/dl.c:513: flushing 0xfc bytes at 0x27ac0
> ../kern/dl.c:513: flushing 0x458 bytes at 0x27bf0
> ../kern/dl.c:570: module name: apple
> ../kern/dl.c:571: init function: 0x27bf0
> ../kern/dl.c:527: module at 0x3fbb8, size 0xeca4
> ../kern/dl.c:556: relocating to 0x27940
> Notice how much larger that last module is than the ones before it.
> That's a bit suspicious... do you have any modules that size?

I'd like to address this issue later but their size are really messed
up. Grub can find the modules (how you can see by the modules names)
though. The modules should have 7k at most but grub identified them has
having about 50k.
I'm also curious why we must have a GAP between _end and the modules.
Why do not put the modules right after the _end address.
I need to look more into the source code but I noted the modules are
allocated in address in a decrementing order. The next module is always
loaded in a address below the previous module. I don't know if this
memory is allocated by the OF or if Grub forces the address to load the
modules this way.
How I have said before that I will look at this issue after the modules
header info location address issue is resolved.
> > that address calculation led me to believe that I can tell where the
> > struct will be on memory based in its place in the binary.
> > 
> > I also noted that basemod ( indicates where the modules sections begin)
> > used by grub_mkelfimage is the same calculated by grub (_end + GAP). but
> > it seems to not store it on the necessary address.
> > 
> > using hexedit I could see that in the address 0xCC98 (in the file
> > generated by grub_mkelfimage) is stored the struct header info.
> Well, hmm. Given the readelf output below, file offset 0xcc98 should be
> loaded right at 0x2d000. Since you can see the magic number there
> (correct?), I can't explain why the ELF loaded places it at 0x38f4c.

Yes, the magic number is exactly at the address 0xcc98 on the file
generated by the grub_mkelfimage. How can you tell the address it should
appear in memory based on its address in file? Maybe it's only valid in
some old OF version? 
> Can you report what memory firmware is using on this system? IIRC you
> can decode it from the "available" properties in the memory nodes.
I couldn't find any apparently useful information in the memory nodes
properties. I have attached it anyway, I have also attached the "/" node

The OF version we are using is that below:
PowerPC Firmware
Version SF240_299

> > so in resume.
> > 
> > address where grub tries to find the header 0x2d000.
> > address where it is actually stored  0x38f4c.
> > address where it is in the generated file 0xCC98.
> > 
> > So my doubts are:
> > How this address calculation works?
> > How can I know where the struct will be in memory based in its address
> > in the binary?
> > It really works or only in some old OpenFirmare version?
> > 
> > 
> > I followed the wiki tutorial in the process.  
> > 
> > That is the exit of the command: "readelf -l" (binary + modules):
> > 
> > Elf file type is EXEC (Executable file)
> > Entry point 0x10000
> > There are 4 program headers, starting at offset 52
> > 
> > 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
> > 
> > 
> > the exit of "readelf -a" is showed in attachment readelf.txt
> > 
> > ´╗┐If you could help me, I will appreciate it. Thanks in advance!
> > Best regards.
> > Abranches, Manoel R.

Best Regards,

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

Attachment: OF-memory-properties.txt
Description: Text document

Attachment: OF-properties.txt
Description: Text document

reply via email to

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