From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Gkq43-0006FY-0v for mharc-grub-devel@gnu.org; Thu, 16 Nov 2006 17:50:35 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Gkq42-0006El-2I for grub-devel@gnu.org; Thu, 16 Nov 2006 17:50:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Gkq3z-0006CC-SN for grub-devel@gnu.org; Thu, 16 Nov 2006 17:50:33 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Gkq3z-0006Bz-L6 for grub-devel@gnu.org; Thu, 16 Nov 2006 17:50:31 -0500 Received: from [32.97.182.145] (helo=e5.ny.us.ibm.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Gkq40-0004lT-6o for grub-devel@gnu.org; Thu, 16 Nov 2006 17:50:32 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAGMoTux026860 for ; Thu, 16 Nov 2006 17:50:29 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAGMoSVV197132 for ; Thu, 16 Nov 2006 17:50:29 -0500 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 kAGMoSEW032230 for ; Thu, 16 Nov 2006 17:50:28 -0500 Received: from [9.53.41.42] (basalt.austin.ibm.com [9.53.41.42]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAGMoRYg032222 for ; Thu, 16 Nov 2006 17:50:28 -0500 From: Hollis Blanchard To: The development of GRUB 2 In-Reply-To: <20061116215744.GA5939@coresystems.de> References: <1161796417.26235.28.camel@em2.my.own.domain> <87pscgwawa.fsf@xs4all.nl> <20061116215744.GA5939@coresystems.de> Content-Type: text/plain Date: Thu, 16 Nov 2006 16:50:20 -0600 Message-Id: <1163717420.26011.114.camel@basalt> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: Re: [Fwd: Re: [LinuxBIOS] grub2 as payload 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: Thu, 16 Nov 2006 22:50:34 -0000 On Thu, 2006-11-16 at 22:57 +0100, Stefan Reinauer wrote: > * Marco Gerards [061025 19:41]: > > > > >> - add support for compiling grub2 as an elf image. > > > > This is possible already. If the ELF image has specific demands, it > > will not be hard to make such changes. > > How do I do this. Running configure and make on a checked out > grub2 tree leaves me with many many modules. Can you hit my head > to some documentation on how to do this? > > * Is grub-mkimage the way to go? It produces a multiboot image, no ELF. > I understand the final image has to be composed from the modules. I don't believe this is currently possible on x86. On PowerPC, the build process creates kernel.elf and *.mod. util/powerpc/ieee1275/grub-mkimage.c then adds the modules to the kernel by creating a new PT_LOAD segment at a well-known address (I'd like that address to be dynamic but don't want to try to rewrite a global in the .data section, and linking twice sucks). On x86, grub-mkimage creates an x86-bootable image, which of course is not an ELF file. > * which module contains the int13 disk code ? So I dont accidentially > use it. disk/i386/pc/biosdisk.c . However, that's always built in to the core kernel (kernel.img). > * what modules are required to display a grub menu over a serial > console and boot a kernel (bzimage) and initrd from ext2? (assuming > there is no reiserfs driver yet) > > What others do I need? Which ones dont I need? > - boot.mod > - ext2.mod > - elf.mod > - gzio.mod? > - (_)linux.mod > - normal.mod(?) > - pc.mod > - terminal.mod > - terminfo.mod serial.mod Helper modules like gzio.mod and fshelp.mod will be pulled in automatically if needed (see moddep.lst, which is used by grub-mkimage). You don't *need* normal.mod. Of course you will need to provide your own disk module to replace biosdisk.mod. > * What's the difference between _chain and chain? > multiboot and _multiboot? This is really lame and I don't like it at all. _foo is where the real work is done, and it's supposed to be built in to "rescue mode", i.e. grub.img. foo is just a wrapper so you can access the same functionality from "normal mode". "Rescue mode" is the small image that can be loaded without needing any modules. It includes the modules needed to load *.mod from a filesystem on a disk, which gets you into "normal mode" with all the fancy menu and tab-completion. -Hollis