From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AMFZY-0006mf-UW for qemu-devel@nongnu.org; Tue, 18 Nov 2003 18:47:52 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMFZ2-0006fD-CW for qemu-devel@nongnu.org; Tue, 18 Nov 2003 18:47:51 -0500 Received: from [62.210.158.46] (helo=teheran.magic.fr) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AMFZ1-0006f0-U8 for qemu-devel@nongnu.org; Tue, 18 Nov 2003 18:47:20 -0500 Received: from 10.0.0.2 (ppp-181.net-555.magic.fr [62.210.255.181]) by teheran.magic.fr (8.11.6/8.11.2) with ESMTP id hAIMjke04624 for ; Tue, 18 Nov 2003 23:45:46 +0100 (CET) Subject: Re: [Qemu-devel] [ADD] PPC processor emulation From: "J. Mayer" In-Reply-To: References: Content-Type: text/plain Message-Id: <1069195839.13658.2379.camel@rapid> Mime-Version: 1.0 Date: 18 Nov 2003 23:50:39 +0100 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tue, 2003-11-18 at 22:48, Chad Page wrote: > On 18 Nov 2003, Jocelyn Mayer wrote: > > > Well, you're right, in some way: > > there is no syscall emulation to do for vl. But you have to emulate > > a machine that looks like a real one. I think most of the softmmu code > > for ix86 could be re-used for PPC and that peripheral emulation could be > > separated into hardware emulation, independant from the target, and > > bus-glue, which defines how the device will be accessed for a given > > target. I think that trying to have some code to emulate a CHRP or a > > PREP machine would be a good start, but we _need_ PCI for those targets. > > But, if we get one of those hardware emulated, with improvements for > > the CPU emulation to handle supervisor instructions and exceptions, > > we would be able to try to boot AIX, Linux, maybe AUX & old MacOSes. > > > > It would be great to do this ! > > AUX was 68K only IIRC. Ooops, you're right... > But on the MacOS front if we can glom code > from MacOnLinux - or beef up user space mode and emulate the MOL kernel > module - then we could get everything from 8.6 to 10.3 working. The older > MacOS's are actually tougher because you have to have a Mac ROM. > Well, we'll need somthing like an OpenFirmware for recent MacOS too. I don't think there is a free firmware available for PPC which would be as complete as freebios... OpenBios seems far from this, as far as I know... > MOL can't run a "stock" Linux kernel, yet... the problem with > LinuxPPC is there *is* no such thing as a stock kernel, unless you > actually emulate Mac HW. > But a real Mac would be difficult to fully emulate, as I think it uses some obscure components. We can imagine the way it runs, looking at Darwin's code, sure... But MacOs is supposed to run on PREP, which is well described and share a lot of components with PC hardwares. That's why I think it would be a good start to emulate this platform... > > In my opinion, the hardest points are: PPC emulation improvement, > > cleaning the current vl code to separate x86 dedicated parts from > > generic ones and PCI. But I don't think we have to worry about PCI: x86 > > emulation will need it too :=) > > Yup... it's kind of surreal to play with Linux under qemu - "ppro" > cpu, but with 486-era peripherals... and more importantly using bus > mastered IO will be much more efficient. I wonder if the bochs code could > be used as a reference for at least some of it, although I think they > mostly emulate ISA stuff too (and yet need the speed boost much more ;) ) > Yes, and we miss AGP & hyper-transport too :=). Seriously, I also think bochs is mainly based on ISA. I took a look to FreeBios: it doesn't allocate PCI ressources at boot time, so all PCI stuff are quite hardcoded in the drivers. There are a few: PCI host bridge, PCI to ISA bridge, VGA controler and USB. -- J. Mayer Never organized