On Sun, 18 Aug 2019, Mark Cave-Ayland wrote:
On 18/08/2019 19:41, Jd Lyons via OpenBIOS wrote:
I’ve been working a little to see if I can get multi-threaded TGC to work for the Mac OS/X in qemu, but Openbios doesn’t seem to support more than one CPU and doesn’t build any device for a second CPU.
I’ve looked at the openbios/arch/ppc/qemu/init.c, and that seems to be the place to apply a patch for multi cpu support, but I don’t really seem any graceful way of doing it.
Can anyone offer any help?
TGC-Work/bin/qemu-system-ppc -M mac99,via=pmu -serial stdio -smp 2,cores=2,threads=1 -accel tcg,thread=multi -cpu g4 -boot c -prom-env auto-boot?=true -prom-env boot-args=-v -hda /Users/jam/os9.2.1.img -m 256 -bios /Users/jam/aty7/openbios/obj-ppc/openbios-qemu.elf heathrow_class_init: init 2 core99_machine_class_init: init 2 qemu-system-ppc: warning: Guest not yet converted to MTTCG - you may get unexpected results s>> et_property: NULL phandle
============================================================= OpenBIOS 1.1 [Aug 6 2019 02:05] Configuration device id QEMU version 1 machine id 1 CPUs: 2 Memory: 256M UUID: 00000000-0000-0000-0000-000000000000 CPU type PowerPC,G4
milliseconds isn't unique.
switching to new context: call-method slw_update_keymap failed with error ffffffdf call-method slw_update_keymap failed with error ffffffdf
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.
(I probably should not be pushing this further but I can't resist, sorry. I promise to stop after this one. This is strictly technical discussion, nothing against anyone.)
Remember what I've said about relying on random hacks that you were offended by? The whole FW_CFG stuff were just added as needed and I think we already have more than should be there. It would be much cleaner to pass this whole thing in one FDT than bits and pieces that also need knowledge in OpenBIOS to understand and assemble into a device tree again. Then a lot of logic in OpenBIOS now only there for this could be cleaned up. Also the above only fixes it for PPC/QEMU, what about other archs? They would need to implement similar mechanisms separately while with FDT unflattening all QEMU archs and machines could use the same way without needing more knowledge in OpenBIOS. (I think we're at a point where not adding more but removing stuff would be an improvement as that would make OpenBIOS simpler and more generic. Firmwares are usually highly board specific with intricate knowledge about the hardware when they run on real hardware but for emulation like QEMU where most hardware init that is the source of knowledge about hardware is not needed a firmware can be generic as SLOF has demonstrated.)
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...
I haven't thought about this before but now you say it this is likely where more hacks may be needed if you rely on FW_CFG only or you end up hard coding knowledge into OpenBIOS and get something only working with current machines emulated by QEMU that will need to be changed when QEMU is changed.
On the other hand this info is already in QEMU which could put it in the FDT (on embedded systems this is what the dtb is used for so it can describe it) then after unflattening, the references should be replaced with the appropriate Forth handles which can be done generically without knowledge about the board. The SLOF fdt.fs has code for this but I could not get that work yet as I had nothing to test with so far.
So I think it would be better to go towards the FDT way rather than adding more knowledge that are just for one arch or may need to be refined later even if that's initially more work but could be better on the long run.
But it's your decision so if I still could not convince you this would be a good idea I'll leave it and won't bring this up again.
Regards, BALATON Zoltan