From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L3K0u-0003ua-Ef for qemu-devel@nongnu.org; Thu, 20 Nov 2008 19:36:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L3K0s-0003s8-Dk for qemu-devel@nongnu.org; Thu, 20 Nov 2008 19:36:47 -0500 Received: from [199.232.76.173] (port=41131 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L3K0s-0003ru-8Y for qemu-devel@nongnu.org; Thu, 20 Nov 2008 19:36:46 -0500 Received: from 42.mail-out.ovh.net ([213.251.189.42]:38496) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L3K0r-0000pI-Sv for qemu-devel@nongnu.org; Thu, 20 Nov 2008 19:36:46 -0500 Date: Fri, 21 Nov 2008 01:30:44 +0100 From: Jean-Christophe PLAGNIOL-VILLARD Subject: Re: [Qemu-devel] [5765] uImage: only try to load 'kernel' images (Hollis Blanchard) Message-ID: <20081121003044.GE10892@game.jcrosoft.org> References: <36864959917-BeMail@laptop> <1227224277.16341.19.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1227224277.16341.19.camel@localhost.localdomain> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 17:37 Thu 20 Nov , Hollis Blanchard wrote: > On Thu, 2008-11-20 at 23:29 +0100, François Revol wrote: > > > IH_TYPE_STANDALONE images could be loaded, but would unexpectedly > > > fail if they > > > tried to use any uboot services. > > > > Hmm how is it planned to support the external API that is being > > developped ? > > It's being added for NetBSD IIRC, and I'll probably need that for Haiku > > as well, or use the boot loader as a standalone image. > > I don't know anything about it, but assuming you mean a runtime API > u-boot offers to applications it's loaded, I don't see that qemu needs > to be involved at all. > > > We would still have an u-boot rom around anyway, wouldn't we? > > It's possible to implement the API in qemu itself (using a magic > "call-out" instruction), but running u-boot itself inside the VM is the > best option. (At one point Jocelyn claimed that this already works with > qemu's 405 emulation, but I could never get it to work.) I'm interested too it he can send info about it > > The code that I've posted is specifically to load uImages, so it > wouldn't be used to load u-boot itself. In the Bamboo patches I'm > working on, I just replicate the post-load environment u-boot leaves > behind (register state, device tree, kernel load address, TLB entries, > etc). This bypasses the need for a u-boot ROM. IMHO I'll prefer to boot qemu with u-boot also to be the nearest of the reallity Best Regards, J.