[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On Wednesday 05 January 2011 06:31:01 Alexander Graf wrote: On 05.01.2011, at 13:07, Rob Landley wrote: On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote: 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. I have some pages bookmarked hinting how to get S390 Linux to boot under hercules, the same way I have instructions for running m68k under Aranym. But in general, if QEMU doesn't support it I have a hard time making myself care... Few people jump through the hoops to run an emulator to compile and run qemu inside then when they only want to verify if their patches break something. The general philosophy I've seen is that the best we can expect is a does ./configure make break on your x86_64 box?. If you're talking about running qemu on a non-x86 host, I don't do that. But if you're talking about running non-x86 code on qemu, my project's motto is we cross compile so you don't have to. The thing is designed so you grab a tarball and go ./run-emulator.sh to get a shell prompt in your emulated environment, with full development tools. If you go ./dev-environment.sh instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can wget and build fairly large packages. I've built the whole of Linux From Scratch 6.7 inside this this, on a couple different platforms. (Still debugging powerpc and mips, probably uClibc issues. Less spare time than I used to have...) In theory I could do the same with qemu itself, just like any other software package. If you feed it just one architecture in a --target-list it shouldn't take _too_ long to build. But in practice running the result would be too slow to do more than boot to a shell prompt and demonstrate that it worked. Yeah, don't worry. My point was that anything that doesn't build and run on x86 hosts has little chance of getting test coverage. Which is half the reason I did Aboriginal Linux. Download one of the prebuilt system images, use ./dev-environment.sh to get a shell prompt in the emulator with full development tools, wget your source code, ./configure, make, run test suite. That means people who don't own this hardware can still test it on their laptop, or from a cron job. It means you can package up a test environment with your bug report so a package maintainer (who hasn't got the hardware either) can reproduce your non-x86 bug and test their fixes. I did a giant evil presentation on this once upon a time, over 200 slides. (An 8 hour, day-long course to actually cover all that, but everybody kept wanting 1 hour summaries... Oh well.) http://landley.net/aboriginal/downloads/presentation.pdf I have been know to test out of tree architecture patches, though. I only ever got sh4 to work by patching qemu, for example. I really dislike out-of-tree. I can't stand 'em, but I don't control what gets merged into most projects. The main issue is that it takes time and effort to get stuff upstream - and it's good that way. There are people out there who are great programmers, but unfortunately don't have the patience to go through an upstream merging cleanup process. Sometimes it's not a question of cleanup, sometimes it's a question of the upstream developers simply not wanting to do something you want to do. It's possible to disagree on _goals_. If the then-kconfig maintainer thinks miniconfig is simply a bad idea, you can't exactly work around him by rewriting the implementation. I've been submitting perl removal patches to the linux kernel build on and off since Peter Anvin went crazy and simultaneously introduced perl as a build prerequisite to the 2.6.25 kernel (and every other project he contributed to, ala klibc and syslinux and such, all at the same time). He resists the removal on principle because he thinks it's GOOD that the kernel depends on perl to build. I have no idea why. Is sysfs an ABI the kernel exports to userspace that should be stable and documented, or is it a private channel that Greg KH and Kay Sievers made for their userspace udev package that nobody else should ever use? When Linus believes one thing and Greg and Kay clearly believe another but won't _admit_ it, you can get some (hilarious or frustrating, depending on your point of view) squirming out of them: http://lkml.org/lkml/2007/7/20/487 Technical issues I'll engage with ad nauseam, but irreconcilable differences of _opinion_ you can't always work around. The squashfs maintainer's efforts to get his patch merged upstream were positively _heroic_, but really: by the time EVERY SINGLE DISTRO is shipping an out of tree patch, the vanilla kernel not including it is a problem with the vanilla kernel. (And yes a year or so before it was merged I checked, and couldn't find a non-toy distro (I.E. one with a package management
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote: 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. I have some pages bookmarked hinting how to get S390 Linux to boot under hercules, the same way I have instructions for running m68k under Aranym. But in general, if QEMU doesn't support it I have a hard time making myself care... Few people jump through the hoops to run an emulator to compile and run qemu inside then when they only want to verify if their patches break something. The general philosophy I've seen is that the best we can expect is a does ./configure make break on your x86_64 box?. If you're talking about running qemu on a non-x86 host, I don't do that. But if you're talking about running non-x86 code on qemu, my project's motto is we cross compile so you don't have to. The thing is designed so you grab a tarball and go ./run-emulator.sh to get a shell prompt in your emulated environment, with full development tools. If you go ./dev-environment.sh instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can wget and build fairly large packages. I've built the whole of Linux From Scratch 6.7 inside this this, on a couple different platforms. (Still debugging powerpc and mips, probably uClibc issues. Less spare time than I used to have...) In theory I could do the same with qemu itself, just like any other software package. If you feed it just one architecture in a --target-list it shouldn't take _too_ long to build. But in practice running the result would be too slow to do more than boot to a shell prompt and demonstrate that it worked. I have been know to test out of tree architecture patches, though. I only ever got sh4 to work by patching qemu, for example. I really dislike out-of-tree. I can't stand 'em, but I don't control what gets merged into most projects. As soon as an architecture runs publicly available code, it should get upstream, so others can benefit from it. Entirely agreed. I've been waiting for any of the m68k improvements to QEMU (to run more than just coldfire) work to get merged for a long time. And I have a todo item to look at https://github.com/uli/qemu-s390 also... Alex Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 05.01.2011, at 13:07, Rob Landley wrote: On Tuesday 04 January 2011 15:00:12 Alexander Graf wrote: 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. I have some pages bookmarked hinting how to get S390 Linux to boot under hercules, the same way I have instructions for running m68k under Aranym. But in general, if QEMU doesn't support it I have a hard time making myself care... Few people jump through the hoops to run an emulator to compile and run qemu inside then when they only want to verify if their patches break something. The general philosophy I've seen is that the best we can expect is a does ./configure make break on your x86_64 box?. If you're talking about running qemu on a non-x86 host, I don't do that. But if you're talking about running non-x86 code on qemu, my project's motto is we cross compile so you don't have to. The thing is designed so you grab a tarball and go ./run-emulator.sh to get a shell prompt in your emulated environment, with full development tools. If you go ./dev-environment.sh instead you get a 2 gigabyte pesistent ext2 image mounted on /home so you can wget and build fairly large packages. I've built the whole of Linux From Scratch 6.7 inside this this, on a couple different platforms. (Still debugging powerpc and mips, probably uClibc issues. Less spare time than I used to have...) In theory I could do the same with qemu itself, just like any other software package. If you feed it just one architecture in a --target-list it shouldn't take _too_ long to build. But in practice running the result would be too slow to do more than boot to a shell prompt and demonstrate that it worked. Yeah, don't worry. My point was that anything that doesn't build and run on x86 hosts has little chance of getting test coverage. I have been know to test out of tree architecture patches, though. I only ever got sh4 to work by patching qemu, for example. I really dislike out-of-tree. I can't stand 'em, but I don't control what gets merged into most projects. The main issue is that it takes time and effort to get stuff upstream - and it's good that way. There are people out there who are great programmers, but unfortunately don't have the patience to go through an upstream merging cleanup process. As soon as an architecture runs publicly available code, it should get upstream, so others can benefit from it. Entirely agreed. I've been waiting for any of the m68k improvements to QEMU (to run more than just coldfire) work to get merged for a long time. And I have a todo item to look at https://github.com/uli/qemu-s390 also... I'm currently working on the s390 parts, so no worries. I have a cleaned up tree and partially working system emulation already. Alex
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27.12.2010, at 02:01, Rob Landley wrote: On Monday 20 December 2010 03:04:38 Alexander Graf wrote: 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 prebuilt binaries for a bunch of different targets at http://landley.net/aboriginal/downloads/binaries (grab the system-image tarballs and run the run-emulator.sh or dev-environment.sh scripts out of them). (I'm actually working on a new release now, should be out by new year's.) However, my goal is to provide native development environments (optionally calling out to the cross compiler on the host via distcc), so I switched from prep to mac99 a few years back because it was better supported and the architecture (compiler config) and userspace were identical. I can dig up prep again, but last I checked qemu -kernel didn't work and I was using a custom boot sector from Milton Miller to make it boot. 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. I have some pages bookmarked hinting how to get S390 Linux to boot under hercules, the same way I have instructions for running m68k under Aranym. But in general, if QEMU doesn't support it I have a hard time making myself care... Few people jump through the hoops to run an emulator to compile and run qemu inside then when they only want to verify if their patches break something. The general philosophy I've seen is that the best we can expect is a does ./configure make break on your x86_64 box?. I have been know to test out of tree architecture patches, though. I only ever got sh4 to work by patching qemu, for example. I really dislike out-of-tree. As soon as an architecture runs publicly available code, it should get upstream, so others can benefit from it. Alex -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) iEUEARECAAYFAk0jilwACgkQq7Wi27wfN1P+ggCWKSPiYeZJnEEaSoFWsroBx7rL 5ACfVxQlUZAY+jZSRTvHRF+EKQh9W84= =1JOQ -END PGP SIGNATURE-
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On Sunday 19 December 2010 09:04:00 Andreas Färber wrote: 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 switched from prep to c99 over a year ago, but the old file is still buried in the archives circa 2008 or so: http://landley.net/hg/hgwebdir.cgi/aboriginal/file/ad65353ad01c/sources/toys Look for ppc_rom.bin and make-ppc_rom.tar.bz2 both more or less from Milton Miller. The corresponding ppc configuration is in sources/targets/powerpc and it worked at the time. (I just switched to something I could do a normal -kernel with like all the other targets.) Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On Monday 20 December 2010 03:04:38 Alexander Graf wrote: 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 prebuilt binaries for a bunch of different targets at http://landley.net/aboriginal/downloads/binaries (grab the system-image tarballs and run the run-emulator.sh or dev-environment.sh scripts out of them). (I'm actually working on a new release now, should be out by new year's.) However, my goal is to provide native development environments (optionally calling out to the cross compiler on the host via distcc), so I switched from prep to mac99 a few years back because it was better supported and the architecture (compiler config) and userspace were identical. I can dig up prep again, but last I checked qemu -kernel didn't work and I was using a custom boot sector from Milton Miller to make it boot. 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. I have some pages bookmarked hinting how to get S390 Linux to boot under hercules, the same way I have instructions for running m68k under Aranym. But in general, if QEMU doesn't support it I have a hard time making myself care... I have been know to test out of tree architecture patches, though. I only ever got sh4 to work by patching qemu, for example. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On Sunday 19 December 2010 09:34:24 Alexander Graf wrote: 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. 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 :). Milton Miller wrote the ppc_bin in the last message from scratch, and made it available to me under GPLv2. The tarball is the source (which includes a snapshot of dtc, which these days you can suck out of the linux kernel) and the .bin file is the output. I used my own powerpc toolchain (built by the build scripts in the same source tree) to compile it. Rob -- GPLv3: as worthy a successor as The Phantom Menace, as timely as Duke Nukem Forever, and as welcome as New Coke.
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 22.12.2010, at 00:51, Andreas Färber andreas.faer...@web.de wrote: Am 21.12.2010 um 01:46 schrieb Alexander Graf: On 21.12.2010, at 01:33, Andreas Färber wrote: 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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 $ qemu-system-ppc -m 256 -M prep -kernel .../zImage.prep -hda .../debian-ppc-qemu.qcow -nographic shows same error as above. Could this be due to the IRQ issue? The older kernel did expect IRQ 13 twice. I would expect it to get a little further before running into such an error... Phew - I doubt it too. There have been quite some changes since it last worked I guess ;). First thing that sounds reasonable now would be to find a known good version and check when the interpreted code paths start to differ. Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 21.12.2010 um 01:46 schrieb Alexander Graf: On 21.12.2010, at 01:33, Andreas Färber wrote: 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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=0x0580 msr=0x2000 dar=0x dsisr=0x 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 $ qemu-system-ppc -m 256 -M prep -kernel .../zImage.prep -hda .../ debian-ppc-qemu.qcow -nographic shows same error as above. Could this be due to the IRQ issue? The older kernel did expect IRQ 13 twice. I would expect it to get a little further before running into such an error... Andreas
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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? :) Alex
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 13:19, François Revol wrote: 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. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. 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. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: 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. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. 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. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. Andreas
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 23:24, Andreas Färber wrote: Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: 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. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. if that works, yes. If instead loading netbsd or haiku is easier, go for those. Anything that actually runs is good :). 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. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. And I very much appreciate that! In fact, I think we're thinking along the same line here. The only difference is that I'd like to see a full patch set in 2 weeks from now that makes prep do something useful, while you wouldn't mind getting those 2 early patches in upstream right now. Either way, you have my full support on this. If you want to stop working on prep after those patches, let's merge them in now - it's an improvement either way. If instead you're keen on improving it, let's let them mature for a while while you continue to work on them. I'm sure you'll spot even more stuff and maybe even find out that you need to go a completely different route in the end :). Whatever happens, I'm very happy to see you work on this! Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
On 20.12.2010, at 23:24, Andreas Färber wrote: Am 20.12.2010 um 13:30 schrieb Alexander Graf: On 20.12.2010, at 13:19, François Revol wrote: 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. This holds only for Linux which imposes its own startup API to bootloaders and go with kernel drivers directly. Other OS like Haiku use a 2nd stage bootloader which assumes a working callable BIOS (OF on ppc), and getting it to run on U-Boot is already tricky on its own. That was my point :). I'm not aware of us supporting firmware on ppcemb, so it's capable of running an OS all by itself already. No, you rather mean: It's capable of running The OS so you don't care about proper firmware there. By the same argument we could just load a Linux kernel directly on PReP and be good with it. Any pointers appreciated. 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. Thanks for thinking about Haiku ;) Btw there are other existing targets, like AROS, MorphOS, or AmigaOS which uses a modified U-Boot with a 'boota' command that passes their 2nd stage Parthenope bootloader a list of BIOS-like callbacks into U-Boot, cf. : http://www.acube-systems.biz/index.php?page=hardwarepid=2 http://www.acube-systems.biz/download/u-boot-1.3.1c_20101206_prod.tar.gz Though they probably won't run on PReP, and PReP support in Haiku might come only for the sake of supporting the BeBox, which had its own dumb firmware (MAME seems to have some emulation support for BeBox). OTOH, I've been thinking about adding a Sam440 target, but it'd still require the custom U-Boot to start AmigaOS for example. I'd call U-Boot the firmware that we can ship with Qemu then because it's open source :). I'm not advocate for openBIOS. If it works, great. If something else works better, let's take that. The only thing I really want to see is a target that does something useful. That's it :). A target that loads proprietary firmware halfway through is not valuable to users IMHO. A target that loads proprietary firmware and boots an OS is valuable. A target that doesn't need firmware and loads an OS is valuable. Maybe a target that doesn't boot an OS quite yet, but loads open source firmware pretty well is valuable too. Then we agree, a target that doesn't load any firmware or kernel is not really valuable. If you look around then you'll find all kinds of starved QEMU branches, e.g., alpha es40, avr32 and z80. They're collecting virtual dust while QEMU grows things like qdev. That's why I'm trying to fix (note: fix) things in upstream, not create another fork to bitrot. Also on the other forks. I'm not sure what happened with the Alpha port, but for AVR32 and z80 I have not seen any upstream submissions since I joined qemu. I know that the AVR32 people were eager in learning things, but I haven't seen any code submitted upstream. I don't believe this is what will happen with you. You're well aware of how open source works and will hopefully pester at least me - preferably others too - until stuff gets in :). Alex
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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
Re: [Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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? Alex
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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 am planning to queue reviewed patches for upstream on a new branch. Then we can either pull them into your ppc queue or directly into master. Andreas
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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. 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 :). I am planning to queue reviewed patches for upstream on a new branch. Then we can either pull them into your ppc queue or directly into master. I'd say let's wait until we get to a point where we can boot any (really, any) guest. As soon as we're there, let's pull the whole thing in to qemu. Until then, I'm sure little enough code changes upstream that it's fine to keep it in a separate tree. If it gets too cumbersome to keep it separate, just nag me and I'll reconsider :). Alex
[Qemu-devel] Re: [PATCH 0/4] ppc: Fix PReP emulation
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. 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. 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. Andreas
