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

[Andreas Färber]

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! :)

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

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.

Andreas

[1] http://www.bebox.nu/tech.php?s=tech/bootROM