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

[Alexander Graf]

On 21.12.2010, at 00:00, Andreas Färber wrote:

> Am 20.12.2010 um 10:04 schrieb Alexander Graf:
> 
>> 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 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.
>> 
>> Since prep would at least get built for everyone, there's less of an issue, 
>> yes.
>> 
>>> 
>>>> So we certainly do need some open source firmware solution for prep to at 
>>>> least have Linux running. For other guests, I don't see a reason why users 
>>>> shouldn't try to fetch a real firmware blob separately :).
>>> 
>>> We're not shipping any firmware for ppcemb either, so that argument seems 
>>> moot. OpenBIOS, SeaBIOS and ZIPL are the only ones currently. Feel free to 
>>> supply additional blobs for U-Boot etc.
>> 
>> IIUC you don't need u-boot for the embedded targets. You just pass in a 
>> kernel and the rest is magic.
>> 
>>> Recent vanilla Linux kernels wouldn't run on PReP. So what Linux do you 
>>> want to run using open source firmware?
>>> I certainly do not intend to write firmware for the upcoming 40p machine. 
>>> If Linux runs on real 40p hardware then it should run with real firmware 
>>> under emulation, too. QEMU is an emulation project, not a Linux testing 
>>> framework.
>> 
>> I completely agree. Linux is usually easy because it's fully open source and 
>> supports a lot of targets. If you feel like running NetBSD or Haiku instead, 
>> feel free to do so.
>> 
>> I'd even be willing to say that running any OS with a proprietary firmware 
>> blob is enough to pull stuff in. And really, I mean _any_ OS. I just really 
>> want to see some value for users, so in case the whole system just doesn't 
>> work at all, we can rather apply a big bunch of removal commits instead of 
>> fixes that won't end up in anything working either.
>> 
>> Having said that, I have faith in your skills to get this working. So I 
>> assume you'll have something that meets the "something runs" criteria in at 
>> most a couple of weeks. Shouldn't be too bad, no? :)
> 
> Listen, I won't spend a couple of weeks on a firmware that I don't need just 
> because you want me to.
> I can't work on QEMU all day nor am I getting paid for it, so I'd rather 
> spend my time on getting ppc/ppc64 Mac emulation working for my needs! :)

Yup. I thought you were the incredible Hulk and would manage to get everything 
working nevertheless :). No, seriously - is it really too much work left to do? 
The target did work at one point in time already, right?

> 
> My interest in PReP is of historical nature only - it would be 'cool' to see 
> BeOS/ppc emulated (and - if feasible - extend Haiku/ppc to run on it, too).

I fully agree!

> 
> The three QEMU PReP projects we're talking about here - 'prep', '40p' and 
> BeBox share a common core like some memory-mapped registers but use different 
> devices and different firmware. The IBM 40p works with a binary firmware - 
> got it to show some graphics on OpenSolaris/amd64 host yesterday (hinting 
> towards endianness issues on Darwin/ppc64 host). The BeBox BootROM however 
> uses a custom format with Be-specific headers and some PE stuff as it seems 
> [1]. Writing firmware for the 'prep' machine buys us nothing there... Fixing 
> it is not even strictly needed, but it seems a good deed while we're at it.

I see. Well, don't do it then. Just get something proprietary running and be 
good. I merely wanted to save you from the troubles I go through with S/390 
where people simply don't test that target since they can't run it...


Alex