This is the patch against the current master of qemu, it should apply clean now, but things changed a little a few days ago and I had to fix the patch.
--- /home/guest/botva/src/src/qemu/hw/ppc/mac_newworld.c 2024-03-27 06:44:12.068828324 +0300 +++ /hw/ppc/mac_newworld.c 2024-05-18 20:48:32.709184875 +0300 @@ -128,6 +128,15 @@ cpu->env.nip = PROM_BASE + 0x100; }
+ +static void ppc_core99_reset_sec(void *opaque) +{ + PowerPCCPU *cpu = opaque; + CPUState *cs = CPU(cpu); + cpu_reset(cs); + cs->exception_index = EXCP_HLT; +} + /* PowerPC Mac99 hardware initialisation */ static void ppc_core99_init(MachineState *machine) { @@ -160,10 +169,27 @@ for (i = 0; i < machine->smp.cpus; i++) { cpu = POWERPC_CPU(cpu_create(machine->cpu_type)); env = &cpu->env; + CPUState *cs; + cs = CPU(cpu); + + /* + * Secondary CPU starts in halted state for now. Needs to change + * when implementing non-kernel boot. + */ + object_property_set_bool(OBJECT(cs), "start-powered-off", i != 0, + &error_abort); + //qdev_realize_and_unref(DEVICE(cs), NULL, &error_fatal);
/* Set time-base frequency to 100 Mhz */ cpu_ppc_tb_init(env, TBFREQ); + + if(!i) qemu_register_reset(ppc_core99_reset, cpu); + else + /* Secondary CPUs */ + qemu_register_reset(ppc_core99_reset_sec, cpu); + + env->spr_cb[SPR_PIR].default_value = i + 15; }
/* allocate RAM */ @@ -368,9 +394,13 @@ qdev_prop_set_chr(dev, "chrA", serial_hd(0)); qdev_prop_set_chr(dev, "chrB", serial_hd(1));
+pic_dev = DEVICE(object_resolve_path_component(macio, "pic")); + qdev_prop_set_uint32(pic_dev, "nb_cpus", machine->smp.cpus); + + pci_realize_and_unref(PCI_DEVICE(macio), pci_bus, &error_fatal);
- 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)); @@ -575,7 +605,7 @@ mc->init = ppc_core99_init; mc->block_default_type = IF_IDE; /* SMP is not supported currently */ - mc->max_cpus = 1; + mc->max_cpus = 4; mc->default_boot_order = "cd"; mc->default_display = "std"; mc->default_nic = "sungem"; --- /home/guest/botva/src/src/qemu/hw/intc/openpic.c 2024-01-06 05:14:26.186344157 +0300 +++ /hw/intc/openpic.c 2024-05-18 05:51:47.360312824 +0300 @@ -1573,6 +1573,11 @@ opp->nb_irqs = KEYLARGO_MAX_EXT; opp->vid = VID_REVISION_1_2; opp->vir = VIR_GENERIC; + + opp->frr = ((opp->nb_irqs - 1) << FRR_NIRQ_SHIFT) | + ((opp->nb_cpus - 1) << FRR_NCPU_SHIFT) | + (opp->vid << FRR_VID_SHIFT); + opp->vector_mask = 0xFF; opp->tfrr_reset = 4160000; opp->ivpr_reset = IVPR_MASK_MASK | IVPR_MODE_MASK; @@ -1582,10 +1587,15 @@ opp->irq_tim0 = KEYLARGO_TMR_IRQ; opp->brr1 = -1; opp->mpic_mode_mask = GCR_MODE_MIXED; + + for (i = KEYLARGO_MAX_EXT; i < KEYLARGO_MAX_IRQ; i++) { + opp->src[i].type = IRQ_TYPE_NORMAL; + opp->src[i].level = false; + }
if (opp->nb_cpus != 1) { - error_setg(errp, "Only UP supported today"); - return; + //error_setg(errp, "Only UP supported today"); + //return; }
map_list(opp, list_le, &list_count); I’m thinking we already had a race condition on mac99,via=pmu and smp just made it worse. The IPI code in OpenPIC likely needs some work too to clear some issues with smp. These patches are NOT Ready For Primetime by any means, I didn’t write them, they came from the list and emasculation forums.
I’ve looked them over and tested them and made a bunch of changes trying to get IDE working so we can boot an OS, but no luck, the IRQ storm and race condition screws up everything but video and you can’t mount any media on the IDE bus once you load a kernel, even OS 9’s nonaKernel.
Set debug to true in the openpic.c and you’ll get spammed with the IRQ storm.
On Feb 19, 2025, at 7:26 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
My local branch is mixed with attempted work arounds that just made the IRQ situation worse, this is the original patch to Openbios…
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index 253394c..7b7b09d 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -348,8 +348,9 @@ cpu_add_pir_property(void) unsigned long pir;
asm("mfspr %0, 1023\n"
: "=r"(pir) :);
: "=r"(pir) :);;- printk("Pir = %lu \n", pir); fword("encode-int"); push_str("reg"); fword("property");
@@ -381,9 +382,9 @@ static void cpu_g4_init(const struct cpudef *cpu) { cpu_generic_init(cpu);
- cpu_add_pir_property();
//cpu_add_pir_property();
- fword("finish-device");
- //fword("finish-device");
}
#ifdef CONFIG_PPC_64BITSUPPORT @@ -1073,13 +1074,23 @@ arch_of_init(void) push_str("reg"); fword("property");
- int i;
- for (i= 0; i<temp; i++) { cpu = id_cpu(); cpu->initfn(cpu);
printk("CPU type %s\n", cpu->name);
snprintf(buf, sizeof(buf), "/cpus/%s", cpu->name);
- printk("CPU type %s\n", cpu->name);
snprintf(buf, sizeof(buf), "/cpus/%s", cpu->name);PUSH(i);fword("encode-int");push_str("reg");fword("property");fword("finish-device");- } ofmem_register(find_dev("/memory"), find_dev(buf)); node_methods_init(buf);
#ifdef CONFIG_RTAS /* OldWorld Macs don't have an /rtas node. */
Let me do some house keeping and I’ll get you the diff for Qemu….
On Feb 19, 2025, at 4:40 AM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
On 19/02/2025 06:50, Jd Lyons via OpenBIOS wrote:
I can’t figure out this race condition but it causes an IRQ storm. I feel like I’m in the old days of PC’s when to had IRQ conflicts and had to sort them yourself deep in the bios. As a Mac person I only had to deal with that on a few friends PC’s. Starting the second CPU in a on state rather than halted just makes the race condition worse, twice as fast, and Openbios doesn’t want to get to the prompt, but throwing 3, 8, or 9 CPUs at it in a running state gets me to the prompt, but it ignores -prom-env setting with anything more that three. 300% cpu usage just speeds up the race condition and IRQ storm so IDE craps out before you can load BootX or a linux kernel. Then noting happens but the IRG storm and GPIO 1 asserting 0, likely to all the other CPUs, and that is likely the race conditions and pulling that low trigger the IRQ storm. I can’t make it stop, I even tied all IRQ and Interrupts handling to CPU0, and that working until the OS Kenral loads and starts sending stuff to CPU1, which is still in a halted state unless I start it with my hack. Even with only CPU0 dealing with IRQs and Interrupts the race condition is still there and the IRQ storm. I have to figure out why GPIO 1keeps getting triggered in a loop to pull low????
Specifically can you narrow it down to which patch or patches to QEMU/OpenBIOS cause the IRQ storm to start? It's almost impossible to provide some pointers without seeing all your changes. Perhaps push them to github or a somewhere similar?
ATB,
Mark.
OpenBIOS mailing list -- openbios@openbios.org To unsubscribe send an email to openbios-leave@openbios.org