All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: PPC64
@ 2008-10-21 20:52 Hollis Blanchard
  2008-10-21 22:04 ` PPC64 Pavel Roskin
  2008-10-23 18:00 ` PPC64 Manoel
  0 siblings, 2 replies; 28+ messages in thread
From: Hollis Blanchard @ 2008-10-21 20:52 UTC (permalink / raw)
  To: Manoel; +Cc: grub-devel, Carlos Roberto do Nascimento Costa

Please CC me, since I'm no longer subscribed to grub-devel.

> From: Manoel <mrabran@linux.vnet.ibm.com>
> To: The development of GRUB 2 <grub-devel@gnu.org>
> 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.

That is really strange. I wonder if you have an ABI issue like
sizeof(long)... how is the grub-mkimage tool compiled? Please make sure
it's 32-bit. The grub binary that executes at boot should also 32-bit.

> 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.

We put the modules into a separate PT_LOAD ELF segment, and these must
be aligned.

One other possibility is that your firmware doesn't like the way
grub-mkimage throws out the section table on the ELF file. You could try
changing that behavior.

I suppose you could also try to extend the existing PT_LOAD segment
instead of creating a new one, but architecturally creating a new
segment for the modules is much nicer.

> 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? 

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

Offset tells you where in the file each segment begins. FileSiz is how
many bytes to read from the file. VirtAddr/PhysAddr is where in memory
to copy it, and MemSiz is how many bytes the segment will occupy in
memory. (If MemSiz > FileSiz, the trailing bytes are zero.)

0x38f4c, where you found the header, is about 50KB inside the second
LOAD segment (which was added by grub-mkimage and contains the modules).
Either the firmware's ELF loader did something bad loading the file, or
grub-mkimage did something bad constructing the file.

Since you said you can manually verify that file offset 0xcc98 does in
fact contain the magic number, and we can all see that it *should* be
loaded at 0x2d000, that makes it seem like the loader did something
wrong.

Can you report the bug to the firmware team, supply the broken binary,
and see if they'll take a look at it?

By the way, what filesystem is GRUB located on, and how big is the
partition? Historically IBM firmware has had bugs loading from many
filesystems, but I think FAT12 is OK as long as it's on a small
partition.

> > 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
> properties. 

I didn't get these.

You'll need to refer to the PowerPC and CHRP bindings to IEEE 1275 to
interpret the /memory/available properties. I don't remember the field
widths off the top of my head, but they are basically a list of <base,
length> pairs that denote regions of memory available to applications.

I was just wondering if maybe firmware was occupying the memory
specified in the ELF header for the modules segment, and was doing
something stupid after that.

-- 
Hollis Blanchard
IBM Linux Technology Center




^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: PPC64
@ 2008-10-27  8:04 rubisher
  0 siblings, 0 replies; 28+ messages in thread
From: rubisher @ 2008-10-27  8:04 UTC (permalink / raw)
  To: grub-devel; +Cc: mrabran, crncosta, grub-devel

---------- Initial header -----------

From      : grub-devel-bounces+rubisher=scarlet.be@gnu.org
To          : "Manoel" mrabran@linux.vnet.ibm.com
CC          : "The development of GRUB 2" grub-devel@gnu.org,"Carlos Roberto
do Nascimento Costa" crncosta@linux.vnet.ibm.com
Date      : Thu, 23 Oct 2008 14:08:55 -0500
Subject : Re: PPC64

> On Thu, 2008-10-23 at 16:00 -0200, Manoel wrote:
> >
[snip]
>
> PAPR was based on the older CHRP specification.
>
mmm, from my aix boot: '# lscfg -vp' report me:
[snip]
  Model Architecture: chrp
[snip]

Hth,
r.

ps: I would like to help more but not enough time right now.


[snip]


---
More than 2000 Scarlet customers don't pay a subscription anymore!
Join and surf free of charge! >> http://www.scarlet.be/nl/mgm




^ permalink raw reply	[flat|nested] 28+ messages in thread
* PPC64
@ 2008-10-20 19:18 Manoel
  2008-10-20 19:32 ` PPC64 Hollis Blanchard
  0 siblings, 1 reply; 28+ messages in thread
From: Manoel @ 2008-10-20 19:18 UTC (permalink / raw)
  To: grub-devel; +Cc: Carlos Roberto do Nascimento Costa, Hollis Blanchard

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]



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.

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.

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.

[-- Attachment #2: grub2.txt --]
[-- Type: text/plain, Size: 3402 bytes --]

cursor-on, unknown wordWelcome to GRUB!

search= 0x38f4c
end =0x24098
gap =0x8000
align=0x1000
base_mod=0x2d000
modinfo = 0x2d000
modinfo->magic = 0x3063ffff
modinfo = 0x38f4c
modinfo->magic = 0x676d696d
../kern/dl.c:527: module at 0x38f64, size 0xbc0
../kern/dl.c:556: relocating to 0x2b8f0
../kern/dl.c:513: flushing 0x14 bytes at 0x2b350
../kern/dl.c:513: flushing 0x69 bytes at 0x2b3a0
../kern/dl.c:513: flushing 0x460 bytes at 0x2b440
../kern/dl.c:570: module name: acorn
../kern/dl.c:571: init function: 0x2b440
../kern/dl.c:527: module at 0x39b30, size 0xefc
../kern/dl.c:556: relocating to 0x2b240
../kern/dl.c:513: flushing 0x97 bytes at 0x2aa30
../kern/dl.c:513: flushing 0x6ec bytes at 0x2ab00
../kern/dl.c:570: module name: fshelp
../kern/dl.c:571: init function: 0x0
../kern/dl.c:527: module at 0x3aa38, size 0x1aa4
../kern/dl.c:556: relocating to 0x2a8b0
../kern/dl.c:513: flushing 0x4 bytes at 0x29af0
../kern/dl.c:513: flushing 0x20 bytes at 0x29b30
../kern/dl.c:513: flushing 0x89 bytes at 0x29b80
../kern/dl.c:513: flushing 0xbf4 bytes at 0x29c40
../kern/dl.c:570: module name: affs
../kern/dl.c:571: init function: 0x29c40
../kern/dl.c:527: module at 0x3c4e8, size 0x1be8
../kern/dl.c:556: relocating to 0x29a20
../kern/dl.c:513: flushing 0x4 bytes at 0x287f0
../kern/dl.c:513: flushing 0x20 bytes at 0x28830
../kern/dl.c:513: flushing 0x28 bytes at 0x28880
../kern/dl.c:513: flushing 0x4 bytes at 0x288e0
../kern/dl.c:513: flushing 0x108c bytes at 0x28920
../kern/dl.c:570: module name: afs
../kern/dl.c:571: init function: 0x28920
../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
DEFAULT CATCH!, exception-handler=fff00300 
at   %SRR0: 0000000000013f88   %SRR1: 0000000000003002 
Open Firmware exception handler entered from non-OF code

Client's Fix Pt Regs:
 00 0000000000000010 00000000018dff50 0000000000000000 0000000065765b1b
 04 000000000001a944 0000000000000000 0000000000003002 0000000000000010
 08 00000000018dfe08 000000000001a944 000000000000000a 0000000065765b1b
 0c 0000000000000000 0000000000000000 0000000000000000 0000000000000000
 10 0000000000000000 0000000000000000 0000000000000000 0000000000000000
 14 0000000000c00000 0000000000000008 0000000000000000 0000000000000000
 18 0000000000000000 000000000001af4c 000000000001a944 000000000003fbb8
 1c 0000000000000007 000000000004881c 0000000000027940 000000000003fbb8
Special Regs:
    %IV: 00000300     %CR: 24000048    %XER: 00000000  %DSISR: 08000000 
  %SRR0: 0000000000013f88   %SRR1: 0000000000003002 
    %LR: 000000000001291c    %CTR: 0000000000017930 
   %DAR: 0000000065765b1b 
Virtual PID = 0 
PFW: Unable to send error log!
 ofdbg
0 > 


[-- Attachment #3: readelf.txt --]
[-- Type: text/plain, Size: 1578 bytes --]

ELF Header:
  Magic:   7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF32
  Data:                              2's complement, big endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           PowerPC
  Version:                           0x1
  Entry point address:               0x10000
  Start of program headers:          52 (bytes into file)
  Start of section headers:          0 (bytes into file)
  Flags:                             0x0
  Size of this header:               52 (bytes)
  Size of program headers:           32 (bytes)
  Number of program headers:         4
  Size of section headers:           40 (bytes)
  Number of section headers:         0
  Section header string table index: 0 <corrupt: out of range>

There are no sections in this file.

There are no sections in this file.

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

There is no dynamic section in this file.

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

^ permalink raw reply	[flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-11-06 17:46 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-21 20:52 PPC64 Hollis Blanchard
2008-10-21 22:04 ` PPC64 Pavel Roskin
2008-10-21 22:40   ` PPC64 Hollis Blanchard
2008-10-23  5:25     ` PPC64 Pavel Roskin
2008-10-23 15:06       ` PPC64 Hollis Blanchard
2008-10-23 16:52         ` PPC64 Pavel Roskin
2008-10-23 18:00 ` PPC64 Manoel
2008-10-23 19:08   ` PPC64 Hollis Blanchard
2008-10-24 12:10     ` PPC64 Manoel
2008-10-24 14:51       ` PPC64 Hollis Blanchard
2008-10-24 21:53     ` PPC64 Manoel
2008-10-27 17:19       ` PPC64 Pavel Roskin
2008-11-04 16:05         ` PPC64 Manoel
2008-11-04 16:12           ` PPC64 Hollis Blanchard
2008-11-04 18:18             ` PPC64 mlongcall gcc flag Manoel
2008-11-04 18:21               ` Manoel
2008-11-04 19:16               ` Robert Millan
2008-11-04 23:48               ` Pavel Roskin
2008-11-05  9:43                 ` Robert Millan
2008-11-05 15:35                   ` Pavel Roskin
2008-11-05 17:25                 ` Hollis Blanchard
2008-11-05 19:27                   ` Manoel
2008-11-06 15:12                   ` Robert Millan
2008-11-06 17:42                     ` Manoel
  -- strict thread matches above, loose matches on Subject: below --
2008-10-27  8:04 PPC64 rubisher
2008-10-20 19:18 PPC64 Manoel
2008-10-20 19:32 ` PPC64 Hollis Blanchard
2008-10-21 16:43   ` PPC64 Manoel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.