[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation

[Rob Landley]

On Monday 20 December 2010 03:04:38 Alexander Graf wrote:
> On 19.12.2010, at 20:12, Andreas Färber wrote:
> > Am 19.12.2010 um 16:34 schrieb Alexander Graf:
> >> On 19.12.2010, at 16:04, Andreas Färber wrote:
> >>> Am 19.12.2010 um 10:54 schrieb Alexander Graf:
> >>>> On 14.12.2010, at 01:49, Andreas Färber wrote:
> >>>>> Hello,
> >>>>>
> >>>>> Based on an earlier attempt of mine to make OpenBIOS work with -M
> >>>>> prep, with kind support from Hervé Poussineau here's an initial stab
> >>>>> at fixing the long-broken PReP emulation and preparing migration from
> >>>>> 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 second,
> >>>>> real IBM 40p machine based on Hervé'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 just
> >>> an FYI for testing the preceding patches and still needs investigation.
> >>>
> >>> 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 the
> >>> Aboriginal Linux tree.
> >>
> >> I'm not sure on the copyright problems we might run into when delivering
> >> binary firmware.
> >
> > No one suggested shipping proprietary firmware.
> >
> > I was advocating enabling users to use the available firmware rather than
> > 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 
http://landley.net/aboriginal/downloads/binaries (grab the system-image 
tarballs and run the "run-emulator.sh" or "dev-environment.sh" scripts out of 
them).  (I'm actually working on a new release now, should be out by new 
year's.)

However, my goal is to provide native development environments (optionally 
calling out to the cross compiler on the host via distcc), so I switched from 
prep to mac99 a few years back because it was better supported and the 
architecture (compiler config) and userspace were identical.  I can dig up prep 
again, but last I checked qemu -kernel didn't work and I was using a custom 
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 
hercules, the same way I have instructions for running m68k under Aranym.  But 
in general, if QEMU doesn't support it I have a hard time making myself 
care...

I have been know to test out of tree architecture patches, though.  I only 
ever got sh4 to work by patching qemu, for example.

Rob
-- 
GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem 
Forever, and as welcome as New Coke.