> Date: Thu, 30 May 2019 20:12:40 +0200
> From: "Peter J. Philipp" <p...@centroid.eu>
>
> 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.
