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

[Andreas Färber]

Am 21.12.2010 um 00:07 schrieb 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! :)
>
> [...] seriously - is it really too much work left to do? The target  
> did work at one point in time already, right?

Not with OpenBIOS, no. It's a nightmare, since we don't even get  
serial output because PReP doesn't use ESCC or not in the locations it  
expects. This is hardcoded in the config file and thus not fw_cfg- 
dependent.

The switch to OpenBIOS really marked the beginning of my being able to  
use qemu-system-ppc. OpenHack'Ware never worked for me before.  
Supposedly patched Linux kernels loaded via -kernel, still searching  
for a working one though...

$ qemu-system-ppc -M prep -nographic
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

$ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -nographic # 
http://www.olifantasia.com/qemu/
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution

$ qemu-system-ppc -M prep -kernel .../vmlinuz-2.4.25 -append  
'ide0=0x1f0,0x3f6,13 ide1=0x170,0x376,13 netdev=9,0x300,eth0  
console=ttyS0 console=tty0 root=/dev/hda' -nographic
ERROR: BUG caught...
BIOS execution exception
nip=0x05800000 msr=0x00002000 dar=0x00000000 dsisr=0x00000000
Stopping execution