qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mac99 SMP


From: BALATON Zoltan
Subject: Re: mac99 SMP
Date: Fri, 7 Mar 2025 13:59:33 +0100 (CET)

On Fri, 7 Mar 2025, Andrew Randrianasulu wrote:
пт, 7 мар. 2025 г., 04:15 BALATON Zoltan <balaton@eik.bme.hu>:
On Fri, 7 Mar 2025, Andrew Randrianasulu wrote:
вс, 2 мар. 2025 г., 11:26 Howard Spoelstra <hsp.cat7@gmail.com>:
On Sat, Mar 1, 2025 at 7:07 AM Howard Spoelstra <hsp.cat7@gmail.com>
wrote:

Here is a patched openbios.
Changes are in arch/ppc/qemu/init.c:

The 7450 cpu is a G4 cpu, therefore I think it should init with cpu_g4
init
So at line 570 I changed .initfn = cpu_750_init, into
.initfn = cpu_g4_init,

To set any cpu except the first to state stopped (as JD's device tree
dump indicated) at boot, at line 1087 I added:
 if (i!=0){
        push_str("stopped");
        fword("encode-string");
        push_str("state");
        fword("property");
        }


The openbios included in the previous post was built from:
https://github.com/mcayland/openbios/
with the here included patch applied. The patch itself is based on
openbios-cpus.patch
available here:
https://lists.nongnu.org/archive/html/qemu-ppc/2025-02/msg00316.html



https://github.com/mcayland/openbios/blob/3468259fc6b217cdaef2f63a52b9d8eee9896204/arch/ppc/qemu/init.c#L558

hm ... does this comment mean I can simply read

MPC7450 RISC Microprocessor Family Reference Manual

https://www.nxp.com/docs/en/reference-manual/MPC7450UM.pdf

and find them there, or real machine tests needed ?

Also, 970MP case missed as I suspected ....

I don't know about the above. I think device tree generation would be
better done in QEMU where all the data is available then it does not have
to be duplicated or communicated to OpenBIOS outside the device tree. Then
OpenBIOS would not need a coordinated update if somthing changes in QEMU
and all this CPU info stuff could be deleted from OpenBIOS as QEMU already
has it. SLOF does this way on spapr and I had some prototype to do the
same in OpenBIOS (and also OpenFirmware with pegasos2 as an experiment)
but we could not agree on if this would be accepable so to not waste my
time on something that will not be merged I've stopped with that. But I
still think that would be better than trying to patch OpenBIOS to add more
CPUs and hard coded defaults for QEMU machines if you ask me, but I'm not
the one who decides what OpenBIOS does.

but why patch removes
+    //cpu_add_pir_property(); ?

Due to macos 9 SMP or something else?

I can answer this. The PPC manual says:

| Processor Identification Register (PIR)
|
| The PIR register is used to differentiate between individual processors
| in a multiprocessor environment.
|
| Note: The PIR is an optional register in the PowerPC Architecture and
| may be implemented differently (or not at all) in the design of each
| processor. The user’s manual of a specific processor will describe the
| functionality of the PIR, if it is implemented in that processor.

(The 7450 manual just says: see the PPC manual so we have a circular
reference with no real answers.)


For expectation info I looked into

http://www.bitsavers.org/components/motorola/PowerPC/2001_MPCFPE32B_PowerPC_Programming_Environments_Manual_Rev_2.pdf

but it does not dive into multiprocessor operations ....

This says PIR is read only so that suggests it would be set by hardware but the 7450 manual additinaly says:

Implementation Note The MPC7450 provides write access to the PIR with mtspr using SPR 1023.

So it's possible that on PowerMac OpenFirmware would set it if it's set at all. It should be possible to verify on a real machine if it's set but I don't have a real machine and don't want to spend time on writing a test program for this. (I guess a test program would invove using a C program with inline asm with mfspr as noted in the implementation note then find out how to run that on specific CPU on MacOS X. JD has a machine so he could write such program and test it to help.)

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]