On 21.12.2010, at 01:33, Andreas Färber wrote: > 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 >
This one boots for me on qemu from SLES10SP3 (0.8.2): http://www.oszoo.org/wiki/index.php/Debian_Etch_ppc_(PowerPC)_-_Qemu_Ready Alex
