On Mon, 19 Aug 2019, Jd Lyons via OpenBIOS wrote:
On Aug 18, 2019, at 4:49 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote: You can grab the current number of CPUs from the fwcfg interface at register FW_CFG_NB_CPUS. As a starting point I'd try writing a for loop somewhere around https://github.com/openbios/openbios/blob/master/arch/ppc/qemu/init.c#L996 to create the relevant number of CPU nodes in the DT.
Once that is done I suspect the next part of the puzzle will be figuring out how to wire up the machine and its IRQs correctly...
Thanks Mark,
Doing this gets me 2 /cpus but both are @0
/* This needs adjusting if #size-cells gets increased. Alternatively use multiple (address, size) tuples. */ PUSH(ram_size & 0xffffffff); fword("encode-int"); fword("encode+"); push_str("reg"); fword("property");
cpu = id_cpu(); cpu->initfn(cpu); printk("CPU type %s\n", cpu->name);
cpu = id_cpu(); cpu->initfn(cpu); printk("CPU type %s\n", cpu->name);
snprintf(buf, sizeof(buf), "/cpus/%s", cpu->name); ofmem_register(find_dev("/memory"), find_dev(buf)); node_methods_init(buf);
How would I go about making the second cpu be @1?
I can’t seem to figure where in the code the cpu is set to @0, is this a function of Openbios or Qemu?
I think this comes from the reg property so you'd need to set that for additional CPUs to increasing numbers. The cpu->initfn() you call above is a function pointer defined in the static const struct cpudef ppc_defs[] array which directs it to different init functions for different cpu types (as identified by id_cpu() by looking at PVR). Some of these init functions actually set reg to 0 for some reason, I think that's wrong and the reg property should be set in arch_of_init instead when adding a cpu but if you're just hacking (as you haven't added a for loop above just another cpu) you can ignore that for now and just override reg property after adding second cpu and see if that works.
(I'm not mentioning that all of the above mess with CPU table and functions could be gone if this info came from QEMU via FDT. Knowledge about CPUs might be needed on real hardware but this is in qemu specific part which could be generic. OK, I promised not to bring it up again but I see a lot of these simplifications possible by going that way so I really think that would make OpenBIOS more managable.)
Regards, BALATON Zoltan