On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote: > > Hi Peter,
Hi Karel, > I think qemu on OpenBSD/macppc will not help you as this will be still using > tcg IMHO. What you would need is something like Linux on PPC64 and running > KVM there and then IMHO you will be able to run PPC code directly on CPU > avoiding possible Qemu issues in PPC isns backend. I see thanks for the info. > See following URLs about how to run Mac OS X for PPC on top of Qemu/KVM on > POWER9/Linux box: > https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac.html > > https://www.talospace.com/2018/08/making-your-talos-ii-into-power-mac_29.html > > I have POWER8 + Linux + KVM box here which is kind of working well since in > Qemu/KVM I'm running various Linuxes and FreeBSD 13-current. If you like to > have something tested there, I'm open to it, either will do it myself or > I'll give you account on the box. > Yet another possibility would be to ask RaptorCS since they promised several > times bare-metal access to POWER9 box to OS porters. I don't know if I want to go that far, just getting past the openfirmware is on my agenda for now, I still need to revisit locore.S too as all .S I wrote last year was garbage. My first most goal is to get 64 bit working on my G5 because I want to make use of the 4 GB in it. But I'd rather not boot it as 1. it sucks a lot of power, 2. I haven't turned the boot chime off yet, I want to go on with emulation somehow though until I can test it on the physical machine probably via ethernet boot. > Could you be also so kind and share information about how do you build > OpenBSD for PPC64 and how do you boot whatever you get from the build. I'm > especially curious if you build bsd.rd and somehow boot that and how exactly > do you invoke Qemu and also what Qemu version exactly do you use for that. It's not really finished, so far only the bsd kernel builds. In july last year I did a gcc cross compiler and I'm using that to compile the kernel. In theory clang also works but I had a hard time wiht it last year and since then have been poking with gcc to get the kernel compiled. Also it's still on the old 6.4-current that I used last year so everything is outdated and needs to be upgraded one day. It's late today, maybe I can make everything available for download again as a vm or vmware image next week. If you downloaded the aimee image that's basically what I'm using with qemu built from its internal ports tree. The version of qemu is old. 3.0.0 I think. Oh I don't build bsd.rd yet, also I don't see anythign on the console yet, openfirmware hasn't initialized stdout yet. I was poking at /sys/aim64/aim64/ofwreal.S for a while before being so hampered with my own lack of understanding of asm that I took many parts of FreeBSD's /sys/powerpc/ofw and connected them in place of the asm, I use the ofwreal.c functions there and modified all OF_* functions to use ofw_real_* functions. What I'm seeing now when I execute the bsd is that deep inside the ofw_real_finddevice() functions (in a function called ofw_real_map(), I think) everything falls apart after a return from that function. I think in the monitor it says a garbage pointer where it went to, meanign the LR register got a garbage value from the stack. I had a week off from this all because I needed to do some sysadmin stuff on my network this week but it's really exciting work and that's what pulls me back. I am concerned about a few things, my alignment of the asm code in locore0.S and ofwreal.S (these are the same as in /sys/arch/macppc/macppc only modified to 64 bit code). Only recently since reading teh 64-bit ABI have I been making sense of offsets in the stack, unfortunately reading the 32-bit ABI that Mark Kettenis helped me with didn't help me understand more of the ofwreal.S code from 32-bit macppc arch. There is some oddities, if I may pick on it, like an addi asm op code which has 3 registers there. Only in the spec of addi the last argument is a value not a register. Examining the code with objdump shows that r8 takes on the value 8 but it is warned about in the as stage of make. There is 2 more subi op codes that have the same problem. within 2 operations of the addi. Since ofw_init works in macppc arch I'm not too concerned about it but in my tinkering with the 64-bit port I'm exploring the import of more FreeBSD code and using a nice big asm in the ofw that makes a lot of sense to my virgin asm eyes. Weeks ago I activated the 64-bit bridge flag and actually succeeded to get past ofw_init somehow, I htink I mentioned it before in a mail. The gathered memory specs from the qemu system were so wrong that the code crashed in pmap.c in steal_avail_pages() or some function like that (forgive me I'm writing this all on memory alone, so if I am off on something it's because I haven't revisited my eyes on the code tonight). I have made aliases in the root shell of the aimee vm that allows me quick building of bsd, quick building of install64.iso and fast call of qemu. The commands are mk, bk, and qs (for qemu-start.sh a shell script that executes 64 bit powerpc qemu), I just haven't yet found out a way to pass the argument boot cd:,ofwboot /bsd and have to still type that in qemu. I use non-used floating point registers to "flag" my way past points that I define in the execution flow with a asm volatile call. This way I know that function X was called but not returned from it yet before execution stops and i'M able to dump registers to see the floating point registers. It's a somewhat tedius, glad I'm only on an emulator. 2 weeks ago I was suspicious of the registers though and something weird happend. I turned off setting the PSL_SF (to go to 64-bit mode) flag. And surprisingly the execution got quite far. Past ld opcodes which I believe would make a 32-bit mode stop in its tracks. asm is fairly finicky and I'm still learning the best way how to go about these things. It's late and I'm gushing my heart out, I better go to bed. Best Regards, -peter > Thanks, > Karel > > On 5/25/19 2:07 AM, Peter J. Philipp wrote: > > Hi, > > > > Last week I worked a bit on my powerpc64 port and I ran into some trouble. > > I'll try to formulate what that trouble was in another post (maybe) in the > > next few days but I just have this question: How can I use Qemu better? > > I'm using the 970FX emulation with 1 cpu for now and I'm running into some > > LR register corruption, and at first glance it seems the asm is alright (in > > that it saves LR on the stack after a mflr, and pops the stack later and > > restores LR with mtlr. > > > > Would it be beneficial to use Qemu on the macppc arch instead of the amd64 > > arch or doesn't it matter? One good thing with the amd64 arch is that I can > > take my work along on weekends to my parents house, where i have no access > > to > > the G5. I'm not letting the G5 idle at 140 Watts. > > > > The 6.5 macppc qemu is broken, so I'll have to take my G5 to -current > > perhaps > > to see if I can get qemu to compile. > > > > Another thing with Qemu that I have problems with is the entire 'show > > registers' output in the monitor, it doesn't feel like it correctly > > displays right data. > > I have also used the x (examine) function in the monitor which is like the > > gdb > > memory examination. Is there any other monitor commands that you might have > > experience with that are a really good debug tool? > > > > Regards, > > -peter > >
