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 1AMHrL-000320-SS for qemu-devel@nongnu.org; Tue, 18 Nov 2003 21:14:23 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMHqo-0002z4-Un for qemu-devel@nongnu.org; Tue, 18 Nov 2003 21:14:22 -0500 Received: from [202.81.18.30] (helo=gaston) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AMHqo-0002yU-4u for qemu-devel@nongnu.org; Tue, 18 Nov 2003 21:13:50 -0500 Received: from benh by gaston with local (Exim 3.36 #1 (Debian)) id 1AMGsp-0001Ly-00 for ; Wed, 19 Nov 2003 12:11:51 +1100 Subject: Re: [Qemu-devel] [ADD] PPC processor emulation From: Benjamin Herrenschmidt In-Reply-To: <1069195839.13658.2379.camel@rapid> References: <1069195839.13658.2379.camel@rapid> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1069204310.31651.20.camel@gaston> Mime-Version: 1.0 Date: Wed, 19 Nov 2003 12:11:51 +1100 Sender: Benjamin Herrenschmidt Reply-To: benh@kernel.crashing.org, qemu-devel@nongnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org > > 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... You don't need much. You need a device-tree and a few client interface calls. MOL does that already and it makes all MacOS "newworld" and OS X happy. > > 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. Well... You can since MOL do have the option of emulating some Mac HW ;) The "native" bridge drivers were added to MOL later on, first versions did indeed only HW emulation > 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... And the linux/ppc one :) Actually, you really don't need to emulate much HW to get any of the MacOSes up. Especially true with Darwin where you can feed the Mach kernel with proper platform drivers at boot time. For MacOS 9, you need some bits (PCI config space, interrupt controller, via-cuda, ...) but for most things like block storage, networking, etc..., MOL just feeds MacOS with special drivers from the device-tree that do the bridging. It's all in MOL source which is GPL and so can be reused here. > 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... I don't think it's that nice ;) I'd rather go the mac way :) > > > 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. -- Benjamin Herrenschmidt