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. > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
