From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44773 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PX1SU-0001X2-Hn for qemu-devel@nongnu.org; Sun, 26 Dec 2010 20:01:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PX1ST-0005c2-3g for qemu-devel@nongnu.org; Sun, 26 Dec 2010 20:01:06 -0500 Received: from mail-gy0-f173.google.com ([209.85.160.173]:36666) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PX1SS-0005bt-W9 for qemu-devel@nongnu.org; Sun, 26 Dec 2010 20:01:05 -0500 Received: by gye5 with SMTP id 5so4266906gye.4 for ; Sun, 26 Dec 2010 17:01:04 -0800 (PST) From: Rob Landley Date: Sun, 26 Dec 2010 19:01:05 -0600 References: <1292287758-8009-1-git-send-email-andreas.faerber@web.de> <12817D1F-93E8-431A-B718-EAB17AEC54DC@suse.de> In-Reply-To: <12817D1F-93E8-431A-B718-EAB17AEC54DC@suse.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201012261901.05779.rob@landley.net> Subject: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Andreas =?iso-8859-1?q?F=E4rber?= , =?iso-8859-1?q?Herv=E9_Poussineau?= , QEMU Developers On Monday 20 December 2010 03:04:38 Alexander Graf wrote: > On 19.12.2010, at 20:12, Andreas F=E4rber wrote: > > Am 19.12.2010 um 16:34 schrieb Alexander Graf: > >> On 19.12.2010, at 16:04, Andreas F=E4rber wrote: > >>> Am 19.12.2010 um 10:54 schrieb Alexander Graf: > >>>> On 14.12.2010, at 01:49, Andreas F=E4rber wrote: > >>>>> Hello, > >>>>> > >>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M > >>>>> prep, with kind support from Herv=E9 Poussineau here's an initial s= tab > >>>>> at fixing the long-broken PReP emulation and preparing migration fr= om > >>>>> abandoned OpenHack'Ware to OpenBIOS as default FOSS firmware. > >>>>> > >>>>> In particular a number of hw_error()s are resolved, so that the BIOS > >>>>> can be entered at all. It is not yet working in terms of serial and > >>>>> VGA support etc. > >>>>> > >>>>> This series is also available from: > >>>>> > >>>>> git://repo.or.cz/qemu/afaerber.git prep-queue > >>>>> > >>>>> Some more work-in-progress for the curious is on my prep branch [2]. > >>>>> The corresponding work-in-progress OpenBIOS changes are at [3]. > >>>>> > >>>>> Unfortunately the prep machine is lacking documentation what exactly > >>>>> it tries to emulate. The plan thus is to merge emulation of a secon= d, > >>>>> real IBM 40p machine based on Herv=E9's work at [1], for use with > >>>>> original binary firmware. > >>>>> > >>>>> Also upcoming are new ppc_chrp machines, forked from ppc_newworld, > >>>>> emulating the 970-based IBM JS20 (using Apple U3) [4] and possibly > >>>>> the POWER5-based IntelliStation 285. These depend on the ongoing > >>>>> ppc64 port of OpenBIOS to be completed though. This relates to PReP > >>>>> in that the machine IDs will need to be coordinated. > >>>> > >>>> Does this series actually make anything work, or is it just a first > >>>> step set to get your development rolling? IOW, would users benefit > >>>> from having the patches upstream yet? > >>> > >>> As indicated above, it lets you enter a BIOS, which is a user-visible > >>> improvement. User-supplied binary firmware works with 1 + 3-4, ELF > >>> firmware with 1-4. Patch 3 depends on review comments. Patch 4 was ju= st > >>> an FYI for testing the preceding patches and still needs investigatio= n. > >>> > >>> For OpenBIOS to work, we need fw_cfg in ppc_prep.c and, independently, > >>> patches to OpenBIOS. Unless of course we want to use another firmware > >>> like OFW from the start. The main interest in PReP nowadays will be > >>> proprietary firmware anyway. I thought Rob (cc'ed) had PReP Linux > >>> kernel patches for QEMU at some point but I couldn't locate them in t= he > >>> Aboriginal Linux tree. > >> > >> I'm not sure on the copyright problems we might run into when deliveri= ng > >> binary firmware. > > > > No one suggested shipping proprietary firmware. > > > > I was advocating enabling users to use the available firmware rather th= an > > holding fixes back just because there is no fully-working FOSS > > alternative firmware yet. > > Hrm, I only partially agree. If you ship a target in qemu that people can= 't > test out of the box, it won't receive testing from contributers. I doubt > that RH people will go in and download proprietary firmware just to check > that prep didn't break. I do hope however, that they test targets that > "just work". I have prebuilt binaries for a bunch of different targets at=20 http://landley.net/aboriginal/downloads/binaries (grab the system-image=20 tarballs and run the "run-emulator.sh" or "dev-environment.sh" scripts out = of=20 them). (I'm actually working on a new release now, should be out by new=20 year's.) However, my goal is to provide native development environments (optionally= =20 calling out to the cross compiler on the host via distcc), so I switched fr= om=20 prep to mac99 a few years back because it was better supported and the=20 architecture (compiler config) and userspace were identical. I can dig up = prep=20 again, but last I checked qemu -kernel didn't work and I was using a custom= =20 boot sector from Milton Miller to make it boot. > I have this very issue with s390. The only host to run (and compile) this > on is an s390. And few people have those. So it breaks from time to time. I have some pages bookmarked hinting how to get S390 Linux to boot under=20 hercules, the same way I have instructions for running m68k under Aranym. = But=20 in general, if QEMU doesn't support it I have a hard time making myself=20 care... I have been know to test out of tree architecture patches, though. I only= =20 ever got sh4 to work by patching qemu, for example. Rob =2D-=20 GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem= =20 =46orever, and as welcome as New Coke.