From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MGG8D-0008MR-Sp for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:38:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MGG88-0008Ek-U2 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:38:05 -0400 Received: from [199.232.76.173] (port=55024 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MGG88-0008EG-Fv for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:38:00 -0400 Received: from mail-qy0-f191.google.com ([209.85.221.191]:47911) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MGG87-0000Y5-T1 for qemu-devel@nongnu.org; Mon, 15 Jun 2009 13:38:00 -0400 Received: by qyk29 with SMTP id 29so4803274qyk.4 for ; Mon, 15 Jun 2009 10:37:59 -0700 (PDT) MIME-Version: 1.0 Sender: slightlyunconventional@gmail.com In-Reply-To: References: <3cdfa5bc0906142140nf2a78rf2a07c3185a9614d@mail.gmail.com> Date: Mon, 15 Jun 2009 12:37:59 -0500 Message-ID: Subject: Re: [Qemu-devel] PowerPC 440 support From: Hollis Blanchard Content-Type: multipart/alternative; boundary=00032557492ae87d3d046c6684e9 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Baojun Wang , "Richard W.M. Jones" , qemu-devel@nongnu.org --00032557492ae87d3d046c6684e9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jun 15, 2009 at 11:52 AM, Blue Swirl wrote: > On 6/15/09, Hollis Blanchard wrote: > > KVM PPC execution doesn't use firmware today. Instead we create the > device > > tree in qemu itself, stuff it into guest memory, and point a guest > register > > at it on entry. This was just a shortcut/hack, because we didn't have > enough > > time to enable both Linux and uboot. > > > > I agree that the best way to do things long-term is to run u-boot inside > the > > guest environment. That will likely require improvements to qemu's device > > emulation, and also we'll probably need to work out a way for qemu to > pass > > parameters (e.g. memory size) to u-boot. IMHO, the best approach there > would > > be to have u-boot interpret a device tree from qemu, then modify it and > pass > > it on to the kernel. Obviously that will require u-boot work. > > I'm not familiar with u-boot, could we use OpenBIOS instead? Is u-boot > used on real hardware? > Yes, u-boot is used on a wide variety of real hardware. Open Firmware is almost unheard-of in embedded systems. -Hollis --00032557492ae87d3d046c6684e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Jun 15, 2009 at 11:52 AM, Blue Swirl <blauwirbel@gmail= .com> wrote:
On 6/15/09, Hollis Blanchard <hollis@penguinppc.org> wrote:
> KVM PPC execution doesn't use firmware today. Instead we create th= e device
> tree in qemu itself, stuff it into guest memory, and point a guest reg= ister
> at it on entry. This was just a shortcut/hack, because we didn't h= ave enough
> time to enable both Linux and uboot.
>
> I agree that the best way to do things long-term is to run u-boot insi= de the
> guest environment. That will likely require improvements to qemu's= device
> emulation, and also we'll probably need to work out a way for qemu= to pass
> parameters (e.g. memory size) to u-boot. IMHO, the best approach there= would
> be to have u-boot interpret a device tree from qemu, then modify it an= d pass
> it on to the kernel. Obviously that will require u-boot work.

I'm not familiar with u-boot, could we use OpenBIOS instead? Is u= -boot
used on real hardware?

Yes, u-boot is used on a wide variety of real hardwa= re. Open Firmware is almost unheard-of in embedded systems.

-Hollis<= br> --00032557492ae87d3d046c6684e9--