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
properties.
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 <[EMAIL PROTECTED]>
IBM Linux Technology Center Brasil
name memory
device_type memory
reg 00000000 00000000 00000000 08000000
available 00000000 00004000 00000000 00bfc000 00000000 01c00000
00000000 06400000
#address-cells 00000001
#size-cells 00000000
ibm,associativity 00000004 00000000 00000000 00000000 000000
0 > .properties
ibm,model-class E5
ibm,pci-full-cfg 00000001
ibm,extended-clock-frequency
00000000 1f78a400
clock-frequency 1f78a400
device_type chrp
#address-cells 00000002
#size-cells 00000002
ibm,max-boot-devices 00000005
ibm,fw-bytes-per-boot-device
00000100
ibm,extended-address
ibm,lpar-capable
ibm,converged-loc-codes
ibm,eeh-default 00000001
ibm,partition-no 00000009
ibm,partition-name 706f7765 72706163 6b2d7465 73743200
ibm,platform-hardware-notification
00000001 504f5745 52355f30 30334230 33303100
ibm,aix-diagnostics
name IBM,9133-55A
model IBM,9133-55A
compatible IBM,9133-55A
ibm,aix-uid 02a1b3d6
system-id IBM,0306301FH
ibm,drc-indexes 00000208 80000001 80000002 80000003 80000004 80000005
80000006 80000007
20000001 20000002 20000003 20000004 20000005 20000006
20000007 20000008
20000009 2000000a 2000000b 2000000c 2000000d 2000000e
2000000f 20000010
20000011 20000012 20000013 20000014 20000015 20000016
20000017 20000018
20000019 2000001a 2000001b 2000001c 2000001d 2000001e
2000001f 20000020
20000021 20000022 20000023 20000024 20000025 20000026
20000027 20000028
20000029 2000002a 2000002b 2000002c 2000002d 2000002e
2000002f 20000030
20000031 20000032 20000033 20000034 20000035 20000036
20000037 20000038
... 00000824bytes total
ibm,drc-types 00000208 4d454d00 4d454d00 4d454d00 4d454d00 4d454d00
4d454d00 4d454d00
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
50484200 50484200 50484200 50484200 50484200 50484200
50484200 50484200
... 00000825bytes total
ibm,drc-names 00000208 4c4d4232 004c4d42 33004c4d 4234004c 4d423500
4c4d4236 004c4d42
37004c4d 42380050 48422031 00504842 20320050 48422033
00504842 20340050
48422035 00504842 20360050 48422037 00504842 20380050
48422039 00504842
20313000 50484220 31310050 48422031 32005048 42203133
00504842 20313400
50484220 31350050 48422031 36005048 42203137 00504842
20313800 50484220
31390050 48422032 30005048 42203231 00504842 20323200
50484220 32330050
48422032 34005048 42203235 00504842 20323600 50484220
32370050 48422032
38005048 42203239 00504842 20333000 50484220 33310050
48422033 32005048
... 00000fd0bytes total
ibm,drc-power-domains 00000208 ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
ffffffff ffffffff
... 00000824bytes total
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel
