On Wed, 26 Jan 2022 00:59:24 +0100 (CET) BALATON Zoltan balaton@eik.bme.hu wrote:
On Tue, 25 Jan 2022, Glenn Washburn wrote:
Hi Balaton,
On Tue, 25 Jan 2022 14:01:38 +0100 (CET) BALATON Zoltan balaton@eik.bme.hu wrote:
On Mon, 24 Jan 2022, Glenn Washburn wrote:
On Mon, 24 Jan 2022 08:04:07 +0000 Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 20/01/2022 21:12, Glenn Washburn wrote:
Hi list,
I've gotten the qemu-ppc target to build correctly, however, I'm having issues with the qemu-ppc64 target. I'm using the 10.1.0 GCC ppc64 compiler distributed at kernel.org[1].
I'm doing the following: $ PATH=/home/user/cross/gcc-10.1.0-nolibc/powerpc64-linux/bin:$PATH $ ./config/scripts/switch-arch qemu-ppc64 $ make V=1
The make is fine until the forthstrap command, which has this output: ./forthstrap -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/bootstrap/ -I/home/user/openbios.git/forth/lib/ -I/home/user/openbios.git/forth/device/ -I/home/user/openbios.git/forth/debugging/ -I/home/user/openbios.git/forth/admin/ -I/home/user/openbios.git/forth/util/ -I/home/user/openbios.git/forth/packages/ -I/home/user/openbios.git/forth/system/ -I/home/user/openbios.git/libopenbios/ -I/home/user/openbios.git/packages/ -I/home/user/openbios.git/drivers/ -I/home/user/openbios.git/arch/ppc/ -I/home/user/openbios.git -I./forth -D bootstrap.dict -M bootstrap.dict.d -c bootstrap.dict-console.log forth/bootstrap/start.fs panic: segmentation violation at 0xa6dbc62c dict=0x7fa7a6dbc010 here=0x7fa7a6dbc638(dict+0x628) pc=0x0(dict+0x59243ff0) dstackcnt=0 rstackcnt=0 instruction=deadbeef dstack: 0x0 rstack: 0x0 Writing dictionary core file
Is anyone else seeing this? Can someone with forth experience help here?
Glenn
[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/10.1.0/...
I haven't tried building with a powerpc64 compiler for a while as the output binary for ppc is always 32-bit. IIRC there is some runtime patching around rfi/rfid and management of the MSR_SF flag to allow things to work under both qemu-system-ppc and qemu-system-ppc64.
Can you get a backtrace from the above? You'll need to clear out any existing obj-* directories and tweak HOSTCFLAGS and CFLAGS in Makefile.target to specify -O0 -g before re-running switch-arch.
Here's backtrace output ia GDB.
Not sure what do you want to do with qemu-ppc64 but the only tested and working config is qemu-ppc which should also work with 64bit PPC but only used for qemu-system-ppc64 -M mac99 which is some G5 Mac like hardware (incomplete emulation of a G5 Mac with a U3 chipset) but still says PowerMac3,1 in the device tree which might confuse anything else than Linux.
Thank you for confirming that qemu-ppc64 is not working. My naive intent was to use the 64bit firmware for the 64bit PPC QEMU. The documentation leads one to believe that this is a valid build target. Perhaps it should be removed or at least documented that it does not work?
There are a lot of things that could be improved but there aren't many developers working on OpenBIOS. In fact Matk is alone and doesn't have much time for it so apart from the regularly used parts others may have shortcomings. In the past I think OpenBIOS was used by other projects too and remnants of that are still there but nowadays it's mostly only used for QEMU's ppc and sparc targets so only those are likely to work. It's still not identical to the original firmware of those machines so it probably boots common OSes but may have some differences or missing parts compared to real hardware. This may be a limitation for testing software that's not already known to work on real hardware. It may help for getting it running but to make sure you should also verify on real hardware at the end. (QEMU's machine emulation is not complete enough to run the orginal firmware of the real machines, at least for PPC Macs, some sparc Suns may work better but I don't know about those.)
If the qemu-ppc64 target were to build successfully, would it also have the same restrictions of only being able to be used by the mac99 machine?
Very likely or not even on that as arch/ppc64 seems to lack all the stuff needed for recognising the machine and fill in the device tree compared to what we have in arch/ppc. I don't know if ppc64 target was ever used for anything or if it's just a provision to build for that platform but was never finished.
For further context, I'm doing this as a part of working on GRUB's testing. Checking again though, it looks like GRUB probably only runs in 32-bit mode on PPC64 anyway.
QEMU comes with openbios-ppc binary that's built from qemu-ppc target so if you want to run on that that's what you need to rebuild it from source. I don't know if it's documented, maybe somewhere on QEMU or OpenBIOS wiki.
On Tue, 25 Jan 2022, Glenn Washburn wrote:
I forgot to mention that OpenBIOS seems to work with qemu machine type "g3beige" as well for ppc and ppc64, and this is the default machine for 32-bit PPC. I'm not sure what the difference between g3beige and mac99 is.
It's used in QEMU as default firmware for mac machines (g3beige, mac99) and 40p as well as sparc and apatc64 machines but that's a different binary. The mac99 machine is a bit strange in that it emulates different machines depedning on how you run it: it's a G4 Mac with cuda/ADB by default in qemu-system-ppc -M mac99 (something like some PowerBooks) but a G5 Mac in qemu-system-ppc64 -M mac99. None of these are like any real machine though, the closest is actually qemu-system-ppc -M mac99,via=pmu which is most simliar to a PowetMac3,1 that has PMU/USB but not every detail is emulated. The g3beige is an older G3 Mac that has slightly different hardware although much of the code is shared in QEMU. Look in qemu/hw/ppc/mac_oldworld.c and qemu/hw/ppc/mac_newworld.c for details. Maybe this is also explained somewhere in QEMU docs or wiki.
Thanks for the details. Sounds like mac99,via=pmu is what should be used for test GRUB since its closest to a real machine. I think I'll discontinue with trying to get PPC64 to build because it doesn't seem that useful for me.
Glenn