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.
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
> >
Locked
