From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:39935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv5sZ-0000D7-0i for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:40:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rv5sS-0007Yz-3q for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:40:02 -0500 Received: from relay1.mentorg.com ([192.94.38.131]:59091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rv5sR-0007Ye-Vn for qemu-devel@nongnu.org; Wed, 08 Feb 2012 06:39:56 -0500 From: Paul Brook Date: Wed, 8 Feb 2012 11:39:47 +0000 References: <1328687721-16030-1-git-send-email-peter.crosthwaite@petalogix.com> <201202081044.14202.paul@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201202081139.49413.paul@codesourcery.com> Subject: Re: [Qemu-devel] [RFC PATCH] arm boot: added QOM device definition List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, qemu-devel@nongnu.org, agraf@suse.de > > I suspect we want to replace the arm_load_kernel call with an > > arm_linux_loader device with appropriate properties. > > Ok, so does this mean the machine model would still explicitly instantiate > the bootloader device? Yes. Bootloaders inherently have machine specific knowledge. They need to know ram location, board ID, secondary CPU boot protocols, etc. Requiring the user specify all these things separately from the rest of the machine description is IMO not acceptable. > Will there be a way of removing the bootloader from > the machine model so if I need to create my own custom bootloader flow i > can? We are doing some custom non-linux boots in our application where > arm-boot.c is not working for us so being able to swap out arm_boot.c for > another implemenation is one of our goals. The bootloader-as-a-device flow > is ideal for this but only works if a user can choose their bootloader on > the command line. I think that's solved the same lines as any other custom machine variant. It's also part of the reason I think it's important to cleanly separate devices that provide functionality from those that are just convenience objects for creating a particular assembly of devices. Having generic ELF and maybe binary blob image loaders is certainly useful. They can all coexist happily within the same machine. I'm inclined to say that anything else isn't worth the effort. Users with other special needs can use third party tools[1] to embed/wrap their magic in a regular image. Paul [1] In many cases cases you just need to splat the supplied bootloader+kernel images into ram, not postprocessing is necessary. For most of the rest objcopy is sufficient.