From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KtO1p-0000wJ-HK for mharc-grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:41 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KtO1n-0000vs-Nr for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KtO1m-0000vL-6i for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:39 -0400 Received: from [199.232.76.173] (port=49875 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KtO1m-0000vI-02 for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:38 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]:34320) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KtO1l-0005EJ-Pl for grub-devel@gnu.org; Fri, 24 Oct 2008 10:52:38 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m9OEqY9U007276 for ; Fri, 24 Oct 2008 10:52:34 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m9OEpcRT093464 for ; Fri, 24 Oct 2008 10:51:38 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m9OEpcOi026119 for ; Fri, 24 Oct 2008 10:51:38 -0400 Received: from [9.53.41.42] (slate.austin.ibm.com [9.53.41.42]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m9OEpb6Y026076; Fri, 24 Oct 2008 10:51:37 -0400 From: Hollis Blanchard To: Manoel In-Reply-To: <1224850215.7358.12.camel@manoel-laptop> References: <1224622323.31194.81.camel@localhost.localdomain> <1224784802.9254.56.camel@manoel-laptop> <1224788935.16720.38.camel@localhost.localdomain> <1224850215.7358.12.camel@manoel-laptop> Content-Type: text/plain Organization: IBM Linux Technology Center Date: Fri, 24 Oct 2008 09:51:35 -0500 Message-Id: <1224859895.9634.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 Cc: The development of GRUB 2 , Carlos Roberto do Nascimento Costa Subject: Re: PPC64 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 14:52:40 -0000 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. > >