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
