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