Qemu

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Qemu

Peter J. Philipp-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Karel Gardas

Hi Peter,

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.

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.

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.

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
>

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
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
> >

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Wolfgang Pfeiffer
On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote:

> [ ... ]  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,

   Re. the boot chime: some live image for ppc64 might help: on
Debian-like distros something like

nvsetvol 0

then should do it.  I've found some ppc 32-bit lubuntu live image to
get that done, some time ago, IIRC.  Alternatively:

https://cdimage.debian.org/cdimage/ports/2019-05-09/

Starting an install with an iso from there (they have 64-bits, it
seems) and then switching to a console might be worth a try.

Good luck!

  Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
Hi Wolfgang,

Thanks for the hint.  Right now my G5 has Apple Tiger or something on the drive
and on the SSD that I added to it has OpenBSD 6.5/macppc.  I select from
Openfirmware which one I want to run.  The problem with booting a linux to
install it where Apple Tiger is, is that my CD's that I have are not accepted
by the DVD drive for some odd reason.  It takes it, thinks a bit, motors whirr
and then it opens up and spits it out.  I tried netbooting OpenSUSE and debian
but beyond grub I don't get anywhere...after loading the initrd it breaks out
into the monitor with SRR0 and SRR1 displayed.  I played a little with the
boot-volume setenv in openfirmware changing it from 3 to 0, -1, but that didn't
help, chime sound is still on.  I remember managing to turn off the sound on
my ibook 19 years ago, but that was a long time ago and I don't remember what
I did except that it took me multiple tries in a library and pissing off
people :-).  Anyhow until I get some accepted CD's I'M kinda stuck with the
setup as it is now.

Best Regards,
-peter


On Sun, May 26, 2019 at 05:29:56PM +0200, Wolfgang Pfeiffer wrote:

> On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote:
>
> > [ ... ]  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,
>
>   Re. the boot chime: some live image for ppc64 might help: on
> Debian-like distros something like
>
> nvsetvol 0
>
> then should do it.  I've found some ppc 32-bit lubuntu live image to
> get that done, some time ago, IIRC.  Alternatively:
>
> https://cdimage.debian.org/cdimage/ports/2019-05-09/
>
> Starting an install with an iso from there (they have 64-bits, it
> seems) and then switching to a console might be worth a try.
>
> Good luck!
>
>  Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
In reply to this post by Peter J. Philipp-3
On Sun, May 26, 2019 at 12:29:58AM +0200, Peter J. Philipp wrote:
> It's late and I'm gushing my heart out,  I better go to bed.

I have created a second project webpage:  https://centroid.eu/ppc/
Along with this I have made 3 image files available to get VMM or VMware to
the point where I am now, if anyone is interested in looking.  Warning it's
a little messy (everything), but I intend to clean up things when I manage
to make it boot.

I feel confident the aimee image will help me get to booting 64-bit PPC,
unless someone starts another porting attempt and beats me to it.  It's
not a race, and I'd be saving myself a lot of time if someone pulled a 64-bit
port out of their sleeve. :-).  Consumerism is easy, producing stuff is really
freakin' hard.

Take care,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
In reply to this post by Karel Gardas
On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote:
> 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.
>
> Thanks,
> Karel

Hi Karel,

Last weeks answer wasn't to my own satisfaction, so I'll try again.  Last
year I spent considerable time and effort to make the bsd kernel compile for
aim64 arch.  aim64 arch is like macppc arch, and powerpc64 is like powerpc,
only that some variables are different and the asm has been changed.  ie.
ppc_mtmsr() asm macro has been changed to ppc_mtmsrd() (doubleword to
indicate that 64-bit flag can be set on the MSR register, it's the highest
bit also called PSL_SF found in /sys/arch/powerpc64/include/psl.h, this I
also had changed).  Everything was changed around ie. a long in powerpc would
be a uint32_t in powerpc64 unless the variable size can go higher to 64 bit, in
that case it would be uint64_t).

So I get to build a 64-bit kernel whoowee, it's like a little lightbulb that
goes poof when I apply current to it.  Basically the kernel starts in locore0.S,
and it branches off into the ofwreal.S asm file, here it stopped last year at
entry into a C routine.  I had given up there.  Closer examination with qemu
though this year showed that it can go further into C routines, I'm not sure
if it was the fact that I compiled with gcc (I tried it out, basically and it
worked).  I was experimenting a bit with the temporary 64-bit bridge which is
a bit one can set to have 32-bit functionality on opcodes like mfsrin.  This
for a moment got me so far as pmap.c but crashed/panic'ed on data that was
supposed to be gotten from openfirmware.  The fact that the stdout console
was not initialized showing me the panic string was another indicator that
these were awry.

Last year I also hacked on the bootloader ofwboot to boot 64-bit ELF images.
This works for the most part and it starts in 32-bit mode and hands off the
execution to the kernel in 32-bit mode, which then does the following opcodes
to set 64-bit mode:

        mfmsr   %r0
        lis     %r21, 1
        insrdi  %r0, %r21, 1, 0 /* set PSL_SF */
        mtmsrd  %r0
        isync
        nop

This I learned from reading the FreeBSD asm and it's not changed much except
perhaps the register #'s.  Ultimately this is called first, and I don't think
I'll see an alignment issue either as 64-bit opcodes are 4 bytes just like
32-bit opcodes.

OK if I didn't already say it I'm focusing on bsd kernel not bsd.rd, when the
day comes when bsd kernel boots but panics on no root filesystem is when I
am going to work on bsd.rd.  That day is still a long ways off I think as I
gotta have locore0.S, open firmware routines, and locore.S right.  locore.S
still nees a lot of work and I'm not even there yet because I'm approaching
the bootstrapping as it executes, and once I'M past the openfirmware I know
it will panic or do funky things once the cpu and memory bootstrapping is done.

Does this better explain where I am at?  There is still a lot to do, and
I'm not really that proud of what I have accomplished thus far, but I started
not knowing any asm, not knowing much in general about kernel work, sure I
poked in ther kernel before but mostly in the networking areas, this is totally
new territory.  And it's hard.  I still can't turn away/walk away, somehow I
keep thinking I can make the lightbulb glow.  I'm approaching this different
though than last year.  Last year I wanted to get something done by christmas.
This year there is no due date.  I'm curious to see how far I can take it.

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Mark Kettenis
> Date: Thu, 30 May 2019 18:09:01 +0200
> From: "Peter J. Philipp" <[hidden email]>
>
> On Sat, May 25, 2019 at 07:58:36PM +0200, Karel Gardas wrote:
> > 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.
> >
> > Thanks,
> > Karel
>
> Hi Karel,
>
> Last weeks answer wasn't to my own satisfaction, so I'll try again.  Last
> year I spent considerable time and effort to make the bsd kernel compile for
> aim64 arch.  aim64 arch is like macppc arch, and powerpc64 is like powerpc,
> only that some variables are different and the asm has been changed.  ie.
> ppc_mtmsr() asm macro has been changed to ppc_mtmsrd() (doubleword to
> indicate that 64-bit flag can be set on the MSR register, it's the highest
> bit also called PSL_SF found in /sys/arch/powerpc64/include/psl.h, this I
> also had changed).  Everything was changed around ie. a long in powerpc would
> be a uint32_t in powerpc64 unless the variable size can go higher to 64 bit, in
> that case it would be uint64_t).
>
> So I get to build a 64-bit kernel whoowee, it's like a little lightbulb that
> goes poof when I apply current to it.  Basically the kernel starts in locore0.S,
> and it branches off into the ofwreal.S asm file, here it stopped last year at
> entry into a C routine.  I had given up there.  Closer examination with qemu
> though this year showed that it can go further into C routines, I'm not sure
> if it was the fact that I compiled with gcc (I tried it out, basically and it
> worked).  I was experimenting a bit with the temporary 64-bit bridge which is
> a bit one can set to have 32-bit functionality on opcodes like mfsrin.  This
> for a moment got me so far as pmap.c but crashed/panic'ed on data that was
> supposed to be gotten from openfirmware.  The fact that the stdout console
> was not initialized showing me the panic string was another indicator that
> these were awry.
>
> Last year I also hacked on the bootloader ofwboot to boot 64-bit ELF images.
> This works for the most part and it starts in 32-bit mode and hands off the
> execution to the kernel in 32-bit mode, which then does the following opcodes
> to set 64-bit mode:
>
>         mfmsr   %r0
>         lis     %r21, 1
>         insrdi  %r0, %r21, 1, 0 /* set PSL_SF */
>         mtmsrd  %r0
>         isync
>         nop
>
> This I learned from reading the FreeBSD asm and it's not changed much except
> perhaps the register #'s.  Ultimately this is called first, and I don't think
> I'll see an alignment issue either as 64-bit opcodes are 4 bytes just like
> 32-bit opcodes.
>
> OK if I didn't already say it I'm focusing on bsd kernel not bsd.rd, when the
> day comes when bsd kernel boots but panics on no root filesystem is when I
> am going to work on bsd.rd.  That day is still a long ways off I think as I
> gotta have locore0.S, open firmware routines, and locore.S right.  locore.S
> still nees a lot of work and I'm not even there yet because I'm approaching
> the bootstrapping as it executes, and once I'M past the openfirmware I know
> it will panic or do funky things once the cpu and memory bootstrapping is done.
>
> Does this better explain where I am at?  There is still a lot to do, and
> I'm not really that proud of what I have accomplished thus far, but I started
> not knowing any asm, not knowing much in general about kernel work, sure I
> poked in ther kernel before but mostly in the networking areas, this is totally
> new territory.  And it's hard.  I still can't turn away/walk away, somehow I
> keep thinking I can make the lightbulb glow.  I'm approaching this different
> though than last year.  Last year I wanted to get something done by christmas.
> This year there is no due date.  I'm curious to see how far I can take it.

Ome thing to keep in mind with hte G5 is that it is a bit strange and
event when running in 32-bit mode it takes traps in 64-bit mode.  And
for some reason the bits in the MSR register aren't where you expect
them to be.  This is what the nop_32_Ns/Ne labels are about in the
powerpc locore..S Those bits are there to fix this up on G5 and are
overwritten with NOP instructions on older 32-bit CPUs.

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
On Thu, May 30, 2019 at 07:03:56PM +0200, Mark Kettenis wrote:
> Ome thing to keep in mind with hte G5 is that it is a bit strange and
> event when running in 32-bit mode it takes traps in 64-bit mode.  And
> for some reason the bits in the MSR register aren't where you expect
> them to be.  This is what the nop_32_Ns/Ne labels are about in the
> powerpc locore..S Those bits are there to fix this up on G5 and are
> overwritten with NOP instructions on older 32-bit CPUs.

Hi Mark,

If I read the macppc code right..., then in powerpc/cpu_subr.c cpu_bootstrap()
these instructions are called, pretty ingenious I must say.  However it makes
me a bit unsure as this is what I see:

------>
       cpu = ppc_mfpvr() >> 16;

        switch (cpu) {
        case PPC_CPU_IBM970:
        case PPC_CPU_IBM970FX:
        case PPC_CPU_IBM970MP:

                ...
                break;
        case PPC_CPU_MPC83xx:
                ...
                /* FALLTHROUGH */
        default:
                ...
        }
<------

These are the G5 CPU (IBM970*) but you're not looping through nop32_start
but rather rfi_start in the same manner.  Is that what you meant?

The default switch is for anything but G5 and does this nice for() loop on
nop32_start.  Could this be a bug in that it's not doing what was intended?

https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain

I could see a mtmsrd being called on a G4 then if I didn't know any better,
and those were 32-bit processors right?

Let me know if I'm misreading this code,

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Mark Kettenis
> Date: Thu, 30 May 2019 20:12:40 +0200
> From: "Peter J. Philipp" <[hidden email]>
>
> On Thu, May 30, 2019 at 07:03:56PM +0200, Mark Kettenis wrote:
> > Ome thing to keep in mind with hte G5 is that it is a bit strange and
> > event when running in 32-bit mode it takes traps in 64-bit mode.  And
> > for some reason the bits in the MSR register aren't where you expect
> > them to be.  This is what the nop_32_Ns/Ne labels are about in the
> > powerpc locore..S Those bits are there to fix this up on G5 and are
> > overwritten with NOP instructions on older 32-bit CPUs.
>
> Hi Mark,
>
> If I read the macppc code right..., then in powerpc/cpu_subr.c cpu_bootstrap()
> these instructions are called, pretty ingenious I must say.  However it makes
> me a bit unsure as this is what I see:
>
> ------>
>        cpu = ppc_mfpvr() >> 16;
>
>         switch (cpu) {
>         case PPC_CPU_IBM970:
>         case PPC_CPU_IBM970FX:
>         case PPC_CPU_IBM970MP:
>
> ...
> break;
> case PPC_CPU_MPC83xx:
> ...
> /* FALLTHROUGH */
> default:
> ...
> }
> <------
>
> These are the G5 CPU (IBM970*) but you're not looping through nop32_start
> but rather rfi_start in the same manner.  Is that what you meant?
>
> The default switch is for anything but G5 and does this nice for() loop on
> nop32_start.  Could this be a bug in that it's not doing what was intended?
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain
>
> I could see a mtmsrd being called on a G4 then if I didn't know any better,
> and those were 32-bit processors right?
>
> Let me know if I'm misreading this code,

I think you are.  For the G5 the code is essentially overwriting all
rfi instructions with rfid instructions.  On G4 and earlier the code
is overwriting the sequences that use the mtmsrd instruction with
nop instructions.  

Anyway, all I wanted to do is give a heads-up to say that this stuff
can be quite non-intuitive.  Especially the how the bits move around
between the 32-bit and 64-bit representation of the msr register on
the G5.  This isn't helped by the way IBM numbers bits from zero for
the most-significant bit.

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Karel Gardas
In reply to this post by Peter J. Philipp-3

Peter,

thanks for the answer, however for me the most important bit is still
mising.

1) how do you invoke qemu to load bsd?

2) how do you connect qemu and gdb in order to debug bsd?

3) how do you cross-compile to ppc64? -- see my next email about issues
with cross-compilation.

Thanks,
Karel

On 5/30/19 6:09 PM, Peter J. Philipp wrote:
> Hi Karel,
>
> Last weeks answer wasn't to my own satisfaction, so I'll try again.

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
In reply to this post by Mark Kettenis
On Thu, May 30, 2019 at 08:44:43PM +0200, Mark Kettenis wrote:

> > https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/arch/powerpc/powerpc/cpu_subr.c?rev=1.8&content-type=text/plain
> >
> > I could see a mtmsrd being called on a G4 then if I didn't know any better,
> > and those were 32-bit processors right?
> >
> > Let me know if I'm misreading this code,
>
> I think you are.  For the G5 the code is essentially overwriting all
> rfi instructions with rfid instructions.  On G4 and earlier the code
> is overwriting the sequences that use the mtmsrd instruction with
> nop instructions.  

They are patching the instructions.  Cool!  If I can bug you one more time
on something.  I see a lot of mtmsrd opcodes then in locore.S that aren't
followed with an immediate isync opcode.  Isn't that needed?  I'm looking
at trapcode() near nop32_1e:

In section 2.3.16 of "Programming Environments Manual for 64-bit Micro-
processors" it talks about it, I think I have a copy of it here:

https://centroid.eu/enhancedrisc/pem_64bit_v3.0.2005jul15.pdf

If not I don't want to take up too much of your time.  In fact I kept a
low profile on asking questions anyhow since you guys are generally overloaded
with work.

> Anyway, all I wanted to do is give a heads-up to say that this stuff
> can be quite non-intuitive.  Especially the how the bits move around
> between the 32-bit and 64-bit representation of the msr register on
> the G5.  This isn't helped by the way IBM numbers bits from zero for
> the most-significant bit.

I know what you mean.  Like in that same hyperlinked document section 2.3.1.

Best Regards,
-peter

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
In reply to this post by Karel Gardas
On Thu, May 30, 2019 at 09:02:54PM +0200, Karel Gardas wrote:
>
> Peter,
>
> thanks for the answer, however for me the most important bit is still
> mising.
>
> 1) how do you invoke qemu to load bsd?

Hi Karel,

Sorry for excluding this.

aimee# more qemu-start.sh
/usr/local/bin/qemu-system-ppc64 -machine mac99 -cpu 970fx -nographic \
                -cdrom /tmp/install64.iso -boot order=d -m 2048 -d guest_errors

> 2) how do you connect qemu and gdb in order to debug bsd?

I don't.  Inside Qemu I use the monitor control-a / show registers to see the
registers and in the code I set markers in floating point registers to see
where in the code it's been.  It's ghetto I know.

> 3) how do you cross-compile to ppc64? -- see my next email about issues with
> cross-compilation.

Here is what aimee vm does:

--------->
aimee# which cc
/usr/cross/aim64/usr/cross/aim64/usr/bin/cc
aimee# head /usr/cross/aim64/usr/cross/aim64/usr/bin/cc
#!/bin/sh

#exec /usr/local/bin/clang  --target=powerpc64-unknown-openbsd6.4 ${@}
exec /usr/local/bin/powerpc64-unknown-openbsd-gcc -m64 ${@}
exit 0
<------------

And the gcc I built a port for very very early last year (probably in august).
All the steps (albeit kinda messy) should be described in the following diary:

https://centroid.eu/enhancedrisc/

I'm just looking right now check out 2018-07-30 entry.

> Thanks,
> Karel

Best Regards,
-peter



> On 5/30/19 6:09 PM, Peter J. Philipp wrote:
> > Hi Karel,
> >
> > Last weeks answer wasn't to my own satisfaction, so I'll try again.

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Wolfgang Pfeiffer
In reply to this post by Peter J. Philipp-3
On Thu, May 30, 2019 at 04:46:58PM +0200, Peter J. Philipp wrote:
>Hi Wolfgang,
>
>Thanks for the hint.  Right now my G5 has Apple Tiger or something on the drive
>and on the SSD that I added to it has OpenBSD 6.5/macppc.  I select from
>Openfirmware which one I want to run.  The problem with booting a linux to
>install it where Apple Tiger is, is that my CD's that I have are not accepted
>by the DVD drive for some odd reason.  It takes it, thinks a bit, motors whirr
>and then it opens up and spits it out.

  No need for a CD drive: tried to load a live or installer linux via
some USB thumb already? Instructions:

https://marc.info/?l=openbsd-ppc&m=155231977928919&w=2

I did complete installs (32-bit) this way ...  I have no idea whether
the Debian installer has that "nvsetvol" tool on board, but it might
be worth a try.

>I tried netbooting OpenSUSE and debian but beyond grub I don't get
>anywhere...after loading the initrd it breaks out into the monitor
>with SRR0 and SRR1 displayed.

Maybe try newer Debian images, or try somewthing like

boot [some usb pattern here??]:,\\:tbxi

see:
https://lists.debian.org/debian-powerpc/2019/05/msg00112.html

lubuntu live:

http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/

And I'm not sure whether this image

http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso

is 64-bit or not.

>I played a little with the boot-volume setenv in openfirmware
>changing it from 3 to 0, -1, but that didn't help, chime sound is
>still on.

Thanks for the hint - but maybe you *might* (be careful, I'm not an OF
expert) need to save the changes to nvram:

see:
"
  [to save the results into NVRAM]
  reset-all
"
from:
https://ftp.openbsd.org/pub/OpenBSD/6.5/macppc/INSTALL.macppc

Good luck!
  Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Wolfgang Pfeiffer
On Fri, May 31, 2019 at 09:35:32AM +0200, Wolfgang Pfeiffer wrote:

>lubuntu live:

.. although I'm not sure whether they're 'live' for ppc ...

>
>http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/
>
>And I'm not sure whether this image
>
>http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso
>
>is 64-bit or not.
>

Wolfgang

Reply | Threaded
Open this post in threaded view
|

Re: Qemu

Peter J. Philipp-3
On Fri, May 31, 2019 at 09:53:48AM +0200, Wolfgang Pfeiffer wrote:

> On Fri, May 31, 2019 at 09:35:32AM +0200, Wolfgang Pfeiffer wrote:
>
> > lubuntu live:
>
> .. although I'm not sure whether they're 'live' for ppc ...
>
> >
> > http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/
> >
> > And I'm not sure whether this image
> >
> > http://cdimage.ubuntu.com/lubuntu/releases/16.04/release/lubuntu-16.04-alternate-powerpc.iso
> >
> > is 64-bit or not.
> >
>
> Wolfgang

I managed to turn the boot chime off with Tiger.  Not sure what it did in
openfirmware, I did notice the boot-volume setenv was changed to 1, I think I
had it at 3.  There is need to install Linux just yet.  (I had some problems
using usb ports on this G5). Thanks for the links!  

Best Regards,
-peter