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

[Alexander Graf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 27.12.2010, at 02:01, Rob Landley wrote:

> 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...

Few people jump through the hoops to run an emulator to compile and run qemu 
inside then when they only want to verify if their patches break something. The 
general philosophy I've seen is that the best we can expect is a "does 
./configure && make break on your x86_64 box?".

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

I really dislike out-of-tree. As soon as an architecture runs publicly 
available code, it should get upstream, so others can benefit from it.


Alex

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEUEARECAAYFAk0jilwACgkQq7Wi27wfN1P+ggCWKSPiYeZJnEEaSoFWsroBx7rL
5ACfVxQlUZAY+jZSRTvHRF+EKQh9W84=
=1JOQ
-----END PGP SIGNATURE-----