question about low-level SMP detail;s in G4 Macs?
Posted: Wed May 15, 2024 1:36 pm
I bothered comrade Zoltan about this , he suggested to post my question to broader audience
so ... wall of text from my yesterday research
so ... wall of text from my yesterday research
So my main problem is finding relevant for emulation details about how this openPIC, MPCI2 ? was connected to rest of the system on especially G4 machines (G5 SMP is different beast). Guess qemu must told openfirmware to generate more than one "cpu" node, so guests will try to init more than one CPU at very minimum? But for openfirmware compilation I need x86-> ppc cross compiler, right?>>>>> https://opensource.apple.com/source/xnu ... .auto.html
>>>>>
>>>>> talks about Daystar SMP machine.? Not sure if enough info survived
>>>>> about those ..... not sure where new g4 stuff lives ....
>>>>>
>>>>> Funnily someone found Mac on Mac early hypervizor (?) at
>>>>> https://forums.macrumors.com/threads/po ... 653/page-3
>>>>>
>>>>>
>>>>> files themselves on macintoshgarden, will try to get them just for look
>>>>> .. there was some sort of virtual coreaudio device, might be useful too?
>>>>>
>>>>> this is in response to SMP ppc request(s) that surface once in few
>>>>> years (each time someone tries to build *fox on qemu ?)
>>>>>
>>>>> ps: yes, I see you work on main qemu-devel. do not want to interrupt,
>>>>> but may be some of this will be of any use....
>>>>>
>>>>
>>>>
>>>> according to this changelog FreeBSD 8.2 supported SMP on PowerMac 3.3
>>>>
>>>> https://www.freebsd.org/releases/8.2R/r ... -detailed/
>>>>
>>>> https://svnweb.freebsd.org/base?view=re ... ion=209767
>>>>
>>>> at least in FreeBSD case we can see OF properties it tries to access?
>>>>
>>>
>>>
>>> so, fbsd set IPI inter procrssor interrupt using powerpc's Programmable
>>> Interrupt Controller ?
>>>
>>>
>>> https://svnweb.freebsd.org/base/stable/ ... rev=209767
>>>
>>>
>>> 3 void
>>> 244 powerpc_register_pic(device_t dev, u_int ipi)
>>> 245 {
>>> 246
>>> 247 pic = dev;
>>> 248 ipi_irq = ipi + ISA_IRQ_COUNT;
>>> 249 }
>>> 250
>>> 251 void
>>> 252 powerpc_register_8259(device_t dev)
>>> 253 {
>>> 254
>>> 255 pic8259 = dev;
>>> 256 }
>>> 257
>>> 258 int
>>> 259 powerpc_enable_intr(void)
>>> 260 {
>>> 261 struct powerpc_intr *i;
>>> 262 int error, vector;
>>> 263
>>> 264 if (pic == NULL)
>>> 265 panic("no PIC detected\n");
>>> 266
>>> 267 #ifdef SMP
>>> 268 /* Install an IPI handler. */
>>> 269 error = powerpc_setup_intr("IPI", ipi_irq,
>>> powerpc_ipi_handler,
>>> 270 NULL, NULL, INTR_TYPE_MISC | INTR_EXCL | INTR_FAST,
>>> &ipi_cookie);
>>> 271 if (error) {
>>> 272 printf("unable to setup IPI handler\n");
>>> 273 return (error);
>>> 274 }
>>> 275 #endif
>>>
>>> not sure how qemu mac99 machine set up interrupts ... need to dig! (I
>>> tried this few years ago without any success .. may be on Nth try)
>>>
>>
>> ah, linux sources (cmt) says timebase freeze done on smp g4 via gpio .
>>
>>
>> https://elixir.bootlin.com/linux/latest ... rmac/smp.c
>>
>>
>>
>> not sure why it must work this way? is it part of online cpu
>> enable/disable? Ah no this is optional with sw fallback ....
>>
>>
>>
>> https://elixir.bootlin.com/linux/latest ... rmac/pic.c
>>
>> ====
>>
>> /* We first try to detect Apple's new Core99 chipset, since mac-io
>> * is quite different on those machines and contains an IBM MPIC2.
>> */
>>
>>
>> ====
>>
>>
>> amazing ... yet another name!
>>
>>
>> https://mail.coreboot.org/hyperkitty/li ... 575PJMALR/
>>
>>
>> so interrupt controller itself seems
>>
>> to be in openfirmware since early days
>>
>> ===
>>
>> 0x1014, 0xFFFF,
>> + PCI_VENDOR_ID_IBM, PCI_DEVICE_ID_IBM_OPENPIC2,
>> "open-pic", "MPIC2", NULL, "chrp,open-pic\0",
>>
>> =====
>>
>>
>> guess I need something like diagram for figuring out
>>
>> how smp interrupts were supposed to work ...
>>
>>
>> http://web.mit.edu/darwin/src/modules/A ... leMPIC.cpp
>>
>>
>> // IPI Vectors start masked with priority 14.
>> regTemp = kIntnVPRMask | (14 << kIntnVPRPriorityShift);
>> regTemp |= vectorNumber << kIntnVPRVectorShift;
>> stwbrx(regTemp, vectorBase + kIPInVecPriOffset);
>> eieio();
>>
>>
>> my lack of fundamental knowledge really shows
>>
>>
> in e500 machine openpic inited like
>
>
> dev = qdev_new(TYPE_OPENPIC);
> object_property_add_child(OBJECT(machine), "pic", OBJECT(dev));
> qdev_prop_set_uint32(dev, "model", pmc->mpic_version);
> qdev_prop_set_uint32(dev, "nb_cpus", smp_cpus);
>
> yet in newworld mac machine it inited like
>
>
> pic_dev = DEVICE(object_resolve_path_component(macio, "pic"));
> for (i = 0; i < 4; i++) {
> qdev_connect_gpio_out(uninorth_pci_dev, i,
> qdev_get_gpio_in(pic_dev, 0x1b + i));
> }
>
> may be it also need
>
> qdev_prop_set_uint32(dev, "nb_cpus", smp_cpus);
>
> set on it? because I saw openpic controller defaults to 1 cpu