Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan wrote: > On Fri, 27 Jan 2023, BALATON Zoltan wrote: > > On Thu, 26 Jan 2023, Howard Spoelstra wrote: > >> On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan > wrote: > >>> On Thu, 26 Jan 2023, Howard Spoelstra wrote: > Mac OS X > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to > adb > mouse. No recognition as HID device. > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that > point > >>> kbd > pcap shows normal interrupt operation and recognition as HID device > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that > point > >>> kbd > pcap shows normal interrupt operation and recognition as HID device > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to > adb > mouse. pcap shows no recognition as HID device. > #10.0 in both cases apple system profiler shows 2 usb buses but no > >>> devices. > >>> > >>> These are all the logs I get booting a 10.0 install iso with > >>> mac99,via=pmu > >>> > > = > > OpenBIOS 1.1 [May 25 2022 20:04] > > Configuration device id QEMU version 1 machine id 1 > > CPUs: 1 > > Memory: 256M > > UUID: ---- > > CPU type PowerPC,G4 > >>> milliseconds isn't unique. > > switching to new context: > > call-method slw_update_keymap failed with error ffdf > > call-method slw_update_keymap failed with error ffdf > >>> usb_ohci_reset pci-ohci > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_set_ctl pci-ohci: new state 0x0 > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_port_detach port #0 > >>> usb_ohci_port_attach port #0 > >>> usb_ohci_port_detach port #1 > >>> usb_ohci_port_attach port #1 > >>> dbdma_unassigned_flush: use of unassigned channel 0 > >>> dbdma_unassigned_flush: use of unassigned channel 0 > >>> usb_ohci_mem_write_bad_offset 0x30 > >>> usb_ohci_set_ctl pci-ohci: new state 0x80 > >>> usb_ohci_start pci-ohci: USB Operational > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_set_ctl pci-ohci: new state 0xc0 > >>> usb_ohci_stop pci-ohci: USB Suspended > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_hub_power_up powered up all ports > >>> usb_ohci_port_reset port #0 > >>> > >>> It's probably OK until it restarts but the seems to be stopped. Anybody > >>> wants to have a look? Maybe start with finding what the states mean. > >>> > >>> > >> I get the same with two usb-ohci controllers (so 6 ports) running Mac OS > >> 9.0.4: > >> > >> usb_ohci_set_ctl pci-ohci: new state 0x80 > >> usb_ohci_start pci-ohci: USB Operational > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_hub_power_up powered up all ports > >> usb_ohci_port_reset port #0 > >> usb_ohci_port_reset port #0 > >> > >> So both usb mouse and kbd do not work. > >> > >> the pcap file for the mouse stalls here: > >> 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response > > > > Maybe the driver gets something from the emulated HID device that it > cannot > > handle and stops during init? Can you reproduce the same with OS X 10.0 > and > > try to correlate the events you see in pcap and trace with the driver > source > > or find out how to enable and read the messages in the driver (unless > these > > are stripped from the binary in Mac OS X but maybe there's something in > the > > guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are > > implemented in hw/usb/dev-hid.c but this file does not have any debuging > or > > traces. You might try to add some printfs for testing. > > > >> However, when I use the usb probe tool from the USB DDK, to probe the > buses > >> I see the host emit a get descriptor > >> > >> 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE > >> 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE > >> 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request > >> etc. and this time the mouse is recognised as HID device, the host > starts > >> polling it and mouse and kbd start to work. > > > > It could be possible that the driver did not get to this point but once > > something else get's past that it recognises the device but I have no > idea > > how this works and not even sure which OS you had this result with. Is > this > > still 9.0.4? That's hard to debug because we don't know what its driver > is > > doing. > > > > Is there a Darwin, OpenDarwin or whatever was that called during the > years > > iso that boots on this machine (also on the real one)? That should be > fully > > open source and probably have the same drivers as Mac OS X so > reproducing > > with that could give some
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, 27 Jan 2023, BALATON Zoltan wrote: On Thu, 26 Jan 2023, Howard Spoelstra wrote: On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan wrote: On Thu, 26 Jan 2023, Howard Spoelstra wrote: Mac OS X #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. No recognition as HID device. #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. pcap shows no recognition as HID device. #10.0 in both cases apple system profiler shows 2 usb buses but no devices. These are all the logs I get booting a 10.0 install iso with mac99,via=pmu = OpenBIOS 1.1 [May 25 2022 20:04] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 256M UUID: ---- CPU type PowerPC,G4 milliseconds isn't unique. switching to new context: call-method slw_update_keymap failed with error ffdf call-method slw_update_keymap failed with error ffdf usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_port_detach port #1 usb_ohci_port_attach port #1 dbdma_unassigned_flush: use of unassigned channel 0 dbdma_unassigned_flush: use of unassigned channel 0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0xc0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 It's probably OK until it restarts but the seems to be stopped. Anybody wants to have a look? Maybe start with finding what the states mean. I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4: usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 So both usb mouse and kbd do not work. the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response Maybe the driver gets something from the emulated HID device that it cannot handle and stops during init? Can you reproduce the same with OS X 10.0 and try to correlate the events you see in pcap and trace with the driver source or find out how to enable and read the messages in the driver (unless these are stripped from the binary in Mac OS X but maybe there's something in the guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does not have any debuging or traces. You might try to add some printfs for testing. However, when I use the usb probe tool from the USB DDK, to probe the buses I see the host emit a get descriptor 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host starts polling it and mouse and kbd start to work. It could be possible that the driver did not get to this point but once something else get's past that it recognises the device but I have no idea how this works and not even sure which OS you had this result with. Is this still 9.0.4? That's hard to debug because we don't know what its driver is doing. Is there a Darwin, OpenDarwin or whatever was that called during the years iso that boots on this machine (also on the real one)? That should be fully open source and probably have the same drivers as Mac OS X so reproducing with that could give some more info or maybe its driver is more verbose about errors and has debugging. So you could try to find an early Darwin version that's about the same time as early OS X versions or look at the IOHIDFamily and try to find what part of it is running when you see the logs (as this driver is quite complex it may not be easy). The oldest Darwin CD I could find is 6.2 which boots and works so it's not old enough for us. The simplest driver is in the oldest 10.0 version so maybe we should try to look at that: https://github.com/apple-oss-distributions/IOHIDFamily/tree/IOHIDFamily-6 and the low level part is in the
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, 26 Jan 2023, Howard Spoelstra wrote: On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan wrote: On Thu, 26 Jan 2023, Howard Spoelstra wrote: Mac OS X #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. No recognition as HID device. #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. pcap shows no recognition as HID device. #10.0 in both cases apple system profiler shows 2 usb buses but no devices. These are all the logs I get booting a 10.0 install iso with mac99,via=pmu = OpenBIOS 1.1 [May 25 2022 20:04] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 256M UUID: ---- CPU type PowerPC,G4 milliseconds isn't unique. switching to new context: call-method slw_update_keymap failed with error ffdf call-method slw_update_keymap failed with error ffdf usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_port_detach port #1 usb_ohci_port_attach port #1 dbdma_unassigned_flush: use of unassigned channel 0 dbdma_unassigned_flush: use of unassigned channel 0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0xc0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 It's probably OK until it restarts but the seems to be stopped. Anybody wants to have a look? Maybe start with finding what the states mean. I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4: usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 So both usb mouse and kbd do not work. the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response Maybe the driver gets something from the emulated HID device that it cannot handle and stops during init? Can you reproduce the same with OS X 10.0 and try to correlate the events you see in pcap and trace with the driver source or find out how to enable and read the messages in the driver (unless these are stripped from the binary in Mac OS X but maybe there's something in the guest logs; ave you checked those?) In QEMU the usb-kbd and mouse are implemented in hw/usb/dev-hid.c but this file does not have any debuging or traces. You might try to add some printfs for testing. However, when I use the usb probe tool from the USB DDK, to probe the buses I see the host emit a get descriptor 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host starts polling it and mouse and kbd start to work. It could be possible that the driver did not get to this point but once something else get's past that it recognises the device but I have no idea how this works and not even sure which OS you had this result with. Is this still 9.0.4? That's hard to debug because we don't know what its driver is doing. Is there a Darwin, OpenDarwin or whatever was that called during the years iso that boots on this machine (also on the real one)? That should be fully open source and probably have the same drivers as Mac OS X so reproducing with that could give some more info or maybe its driver is more verbose about errors and has debugging. So you could try to find an early Darwin version that's about the same time as early OS X versions or look at the IOHIDFamily and try to find what part of it is running when you see the logs (as this driver is quite complex it may not be easy). Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan wrote: > On Thu, 26 Jan 2023, Howard Spoelstra wrote: > > Mac OS X > > #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb > > mouse. No recognition as HID device. > > #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point > kbd > > pcap shows normal interrupt operation and recognition as HID device > > #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point > kbd > > pcap shows normal interrupt operation and recognition as HID device > > #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb > > mouse. pcap shows no recognition as HID device. > > #10.0 in both cases apple system profiler shows 2 usb buses but no > devices. > > These are all the logs I get booting a 10.0 install iso with mac99,via=pmu > > >> = > >> OpenBIOS 1.1 [May 25 2022 20:04] > >> Configuration device id QEMU version 1 machine id 1 > >> CPUs: 1 > >> Memory: 256M > >> UUID: ---- > >> CPU type PowerPC,G4 > milliseconds isn't unique. > >> switching to new context: > >> call-method slw_update_keymap failed with error ffdf > >> call-method slw_update_keymap failed with error ffdf > usb_ohci_reset pci-ohci > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_set_ctl pci-ohci: new state 0x0 > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_port_detach port #0 > usb_ohci_port_attach port #0 > usb_ohci_port_detach port #1 > usb_ohci_port_attach port #1 > dbdma_unassigned_flush: use of unassigned channel 0 > dbdma_unassigned_flush: use of unassigned channel 0 > usb_ohci_mem_write_bad_offset 0x30 > usb_ohci_set_ctl pci-ohci: new state 0x80 > usb_ohci_start pci-ohci: USB Operational > usb_ohci_hub_power_up powered up all ports > usb_ohci_hub_power_up powered up all ports > usb_ohci_set_ctl pci-ohci: new state 0xc0 > usb_ohci_stop pci-ohci: USB Suspended > usb_ohci_hub_power_up powered up all ports > usb_ohci_hub_power_up powered up all ports > usb_ohci_port_reset port #0 > > It's probably OK until it restarts but the seems to be stopped. Anybody > wants to have a look? Maybe start with finding what the states mean. > > I get the same with two usb-ohci controllers (so 6 ports) running Mac OS 9.0.4: usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 usb_ohci_port_reset port #0 So both usb mouse and kbd do not work. the pcap file for the mouse stalls here: 12 0.007048 0.1.0 host USB 64 SET CONFIGURATION Response However, when I use the usb probe tool from the USB DDK, to probe the buses I see the host emit a get descriptor 13 115.761725 host 0.0.0 USB 64 GET DESCRIPTOR Request DEVICE 14 115.761803 0.0.0 host USB 72 GET DESCRIPTOR Response DEVICE 15 115.773719 host 0.0.0 USB 64 SET ADDRESS Request etc. and this time the mouse is recognised as HID device, the host starts polling it and mouse and kbd start to work. Best, Howard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, 26 Jan 2023, Howard Spoelstra wrote: Mac OS X #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. No recognition as HID device. #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. pcap shows no recognition as HID device. #10.0 in both cases apple system profiler shows 2 usb buses but no devices. These are all the logs I get booting a 10.0 install iso with mac99,via=pmu = OpenBIOS 1.1 [May 25 2022 20:04] Configuration device id QEMU version 1 machine id 1 CPUs: 1 Memory: 256M UUID: ---- CPU type PowerPC,G4 milliseconds isn't unique. switching to new context: call-method slw_update_keymap failed with error ffdf call-method slw_update_keymap failed with error ffdf usb_ohci_reset pci-ohci usb_ohci_stop pci-ohci: USB Suspended usb_ohci_set_ctl pci-ohci: new state 0x0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_port_detach port #0 usb_ohci_port_attach port #0 usb_ohci_port_detach port #1 usb_ohci_port_attach port #1 dbdma_unassigned_flush: use of unassigned channel 0 dbdma_unassigned_flush: use of unassigned channel 0 usb_ohci_mem_write_bad_offset 0x30 usb_ohci_set_ctl pci-ohci: new state 0x80 usb_ohci_start pci-ohci: USB Operational usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_set_ctl pci-ohci: new state 0xc0 usb_ohci_stop pci-ohci: USB Suspended usb_ohci_hub_power_up powered up all ports usb_ohci_hub_power_up powered up all ports usb_ohci_port_reset port #0 It's probably OK until it restarts but the seems to be stopped. Anybody wants to have a look? Maybe start with finding what the states mean. Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, 26 Jan 2023, Howard Spoelstra wrote: I tested all Mac OS/OSX available to me with mouse and kbd alternately connected to usb-bus1 or usb-bus2. ./qemu-system-ppc \ -M mac99,usb=off \ -L pc-bios \ -boot c \ -prom-env "auto-boot?=true" \ -display gtk -monitor stdio \ -drive file=/home/hsp/Mac-disks/9.0.4.img,format=raw,media=disk \ -device pci-ohci,id=usb-bus1 \ -device pci-ohci,id=usb-bus2 \ -device usb-mouse,bus=usb-bus1.0,pcap=9.0.4_p1_mouse-2usb.pcap \ -device usb-kbd,bus=usb-bus2.0,pcap=9.0.4_p2_kbd-2usb.pcap \ -device sungem,netdev=network01 -netdev user,id=network01 \ -trace "usb_ohci*" These are the results: Mac OS: #9.0.4 bus1 kbd: works up to usb_ohci_port_reset port #0 in trace, pcap shows normal operation and recognition as HID device . #9.0.4 bus2 mouse. Reverts to adb mouse. No recognition as HID device. #9.0.4 bus1 mouse: usb_ohci_port_reset port #0 (twice). No further traffic in trace. Reverts to adb mouse. No recognition as HID device. #9.0.4 bus2 kbd then no longer works (due to reset?) I attempted to replace the 9.0.4 disk based USB drivers with the drivers from 9.1, which did not work. #9.1/9.2: mouse and kbd work on both buses. Profiler shows 2 buses with one device each. Mac OS X #10.0 bus1 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. No recognition as HID device. #10.0 bus2 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus1 kbd: usb_ohci_stop pci-ohci: USB Suspended. Up to that point kbd pcap shows normal interrupt operation and recognition as HID device #10.0 bus2 mouse: usb_ohci_stop pci-ohci: USB Suspended. Reverts to adb mouse. pcap shows no recognition as HID device. #10.0 in both cases apple system profiler shows 2 usb buses but no devices. #10.1 bus1 mouse: pcap shows normal interrupt operation and recognition as HID device, trace shows continuous traffic #10.1 bus2 kbd: works. pcap shows normal interrupt operation and recognition as HID device, trace shows continuous traffic #10.1 bus1 kbd: works. pcap shows normal interrupt operation and recognition as HID device, trace shows continuous traffic #10.1 bus2 mouse: pcap shows normal interrupt operation and recognition as HID device, trace shows continuous traffic #10.1 Mouse does not move on desktop, but trace shows packets flow. #10.2/10.3/10.4/10.5 mouse and kbd work on both buses. Profiler shows 2 buses with one device each. Maybe we need a bit more details from around the point the traces start to differ between the versions and about 10-20 lines before it srops and 10-20 lines after (around) that point with versions that work for comparison. It seems the versions that don't work get some error and the OHCI device stops or it's something around reset as the suspend is also called from there. But we need to locate more where is it in the driver to be able to tell what's happening. Maybe also add -trace enable="usb_ohci*" -trace enable="usb_port*" and try to correlate what the driver is doing by that. The OS X driver sources are available at https://github.com/apple-oss-distributions/IOHIDFamily the versions correslonding to OS releases are at https://opensource.apple.com/releases/ 10.1.x had 8.3 and 10.2 had version 33 of this driver but new in 10.2 was https://github.com/apple-oss-distributions/IOUSBFamily/tree/IOUSBFamily-190.4.1 so it seems there was some bigger change in USB handling between those versions. Darwin sources may have more detailed info but I don't know where to find those. 10.0 and 9.0.4 seem to suffer the same issue (mouse not communicating as a HID device, but 10.1 seems to have another issue. Attempts to run Mac OS X ioreg show that it fails in that it cannot read the full registry. This was already noticed here: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05260.html If this is related to the NVRAM format as speculated in later that thread: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg05315.html Then that format is also documented in the sources: https://github.com/apple-oss-distributions/AppleCore99NVRAM and there are other emulators that implement it: https://github.com/dingusdev/dingusppc/blob/master/devices/common/ofnvram.cpp so this should be easy to fix. Ask Mark to do that in QEMU and OpenBIOS or let somebody do it without making a fuss about it. (If we could boot these OSes with a firmware ROM from the real machine we could verify if it's a problem with NVRAM format or something else. Maybe I should try OS X on g3beige but it currently stops in Toolbox ROM before display is up or accessing CD so not sure if OS X could boor. If it does not need Toolbox just OpenFirmware maybe it could work but I haven't tried yet. What's a good version of OS X to run on a real G3 beige?) -Ioreg from a real G4 running 10.4 and output from the PCI DDK name registry tool from a real G4 running 9.0.4 and from Qemu running
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 4:33 PM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan > wrote: > >> I thought MacOS 8 needed old world ROM but looks like it can also load > it > >> from disk on new world machines. Then what version of the ROM it has? > >> It seems there was some change at ROM 5.2.1 then which solves the > problem > >> with usb and older versions may have done something differently and > >> expect it to work unlike it's emulated now. > >> > >> The rom on the 8.6 Cd is version > > The disk utility on the CD cannot initialise a hard disk (something we > had > > with some 9.0.4 versions too) > > This sentence seems to be unfinished, also the disk utility problem is > maybe unrelated so just ignore that for now and focus on usb first. > > >> So it seems versions before 10.2 have a problem (except 9,1 and 9.2 > which > >> may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I > assume > >> later 9.x versions have at least this or newer Toolbox ROM) I think it's > >> esasier to debug with OS X because it's easier to get logs and the > drivers > >> may also be open source so easier to check what's happening so let's > just > >> forget about MacOS9 for now and try to find out what changed between > 10.1 > >> and 10.2 in usb handling. > >> > >>> It seems via=pmu provides usb mouse first, usb kbd second. > >>> With Mac OS 9.0.4 the second device will not work. > >>> With 10.0 / 10.1 both usb mouse and kbd do not work. > >> > >> These are added here: > >> > >> > >> > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 > >> > >> you could change the order but it does not matter if both needs to work. > >> If it makes the first one work then maybe the older USB drivers only > >> handle one port per bus? But then the problem in OS X may be different. > >> > >>> Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by > >> default I > >>> only see one bus: USB 0 into which both mouse and kdb are plugged. > >>> On the real G4 the mouse and kbd are each plugged into another bus, so > I > >>> see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. > >>> > >>> With -M mac99,via=cuda one USB bus is always created. It has id > "usb-bus" > >>> We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this > is > >>> the Apple USB controller). > >>> > >>> Then add mouse and kbd to different buses with: > >>> -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) > >>> -device usb-kbd,bus=usb1.0 (attaches to second bus). > >>> > >>> This then mimics what I see on real hardware. Should qemu-system-ppc by > >>> default provide the same? > >> > >> Does this solve the problem you have? > > > > > > No. > > OK so then we should not do that by default either unless we find it's > needed for some reason. > > >> (You talk about via=cude above but I > >> think it should be via=pmu. Is that a typo?) > > > > > > No, even with via-cuda the first usb bus is created: > > dev: pci-ohci, id "" > >masterbus = "" > >num-ports = 3 (0x3) > >firstport = 0 (0x0) > >addr = 0d.0 > >romfile = "" > >romsize = 4294967295 (0x) > >rombar = 1 (0x1) > >multifunction = false > >x-pcie-lnksta-dllla = true > >x-pcie-extcap-init = true > >failover_pair_id = "" > >acpi-index = 0 (0x0) > >class USB controller, addr 00:0d.0, pci id 106b:003f (sub > 1af4:1100) > >bar 0: mem at 0x8008 [0x800800ff] > >bus: usb-bus.0 > > type usb-bus > > > > I now think in some cases the mouse falls back to adb when usb does not > > work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to > the > > desktop. > > Can we disable usb-bus creation for via=cuda? > > Yes, try: > > qemu-system-ppc -M mac99,usb=no > > (I had to look at the code to find that out). > > > If this helps mac_newworld.c > >> could add another usb bus or do somerthing different to match real > >> hardware but you have to convince Mark about that first... Also Mac > >> keyboards have a hub where the mouse is usially connected. Does modeling > >> that setup with QEMU help? > >> > >> No, same issues with that. > > Then it's probably not about how these ports are arranged but something > about modeiling the hardware maybe (i.e. QEMU does something differently > than real hardware and this confuses the driver). > > >> Other idea you could try is to boot 10.1 and 10.2 and compare the ioreg > >> outputs for the USB devices to see if there are some differences or get > >> the USB driver versions and try to find out what changed in them. > >> > >> > > I attempted to take a look, but without mouse/kbd it is difficult to get > to > > ioreg ;-) > I tested all Mac OS/OSX available to me with mouse and kbd alternately connected to usb-bus1 or usb-bus2. ./qemu-system-ppc \ -M mac99,usb=off \ -L pc-bios \ -boot c \
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
> On Jan 4, 2023, at 2:59 PM, BALATON Zoltan wrote:
>
> Setting emulated machine type with a property called "via" is
> confusing users so deprecate the "via" option in favour of newly added
> explicit machine types. The default via=cuda option is not a valid
> config (no real Mac has this combination of hardware) so no machine
> type could be defined for that therefore it is kept for backwards
> compatibility with older QEMU versions for now but other options
> resembling real machines are deprecated.
>
> Signed-off-by: BALATON Zoltan
> ---
> hw/ppc/mac_newworld.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index f07c37328b..adf185bd3a 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
> if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> warn_report("mac99 with G5 CPU is deprecated, "
> "use powermac7_3 instead");
> +} else {
> +if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> +warn_report("mac99,via=pmu is deprecated, "
> +"use powermac3_1 instead");
so use ‘-m mac99,via=powermac3_1’ or ‘-m powermac3_1’ or ‘-m mac99,powerpmac3_1’
I have no clue which one I’m supposed to use. It would be better to tell the
user
which of these three possibilities they should really use. From the other
patches
in the series, I’m guessing it’s the middle one, but even after looking at the
code, I’m
unsure.
> +}
> +if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
> +warn_report("mac99,via=pmu-adb is deprecated, "
> +"use powerbook3_2 instead");
Same basic comment here.
I’m thinking adding '-m’ or ‘machine type’ before powerbook… in both of these
would
resolve it..
Warner
> +}
> }
> }
> /* allocate RAM */
> --
> 2.30.6
>
>
signature.asc
Description: Message signed with OpenPGP
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, 12 Jan 2023, Howard Spoelstra wrote: My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. True it never had ADB and makes not much sense to run it with a G3 (although you probably could, just nobody wanted to; but the other way around, i.e. according to https://en.wikipedia.org/wiki/Power_Mac_G4 the first PCI only G4 PowerMac1,2 had a motherboard from a G3 Mac just with a G4 CPU). But the G4 AGP could have a 900 MHz or faster CPU via a CPU upgrade: https://lowendmac.com/newsrev/07/0330.html#b https://lowendmac.com/newsrev/mnr07/1029.html https://lowendmac.com/ppc/power-mac-g4-upgrade-guide.html These links are from this page: https://lowendmac.com/1999/power-mac-g4-sawtooth/ also may be of interest: https://lowendmac.com/1998/beige-power-mac-g3-1998/ https://lowendmac.com/1997/beige-power-mac-g3-1997/ Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, 24 Jan 2023, Howard Spoelstra wrote: On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan wrote: I thought MacOS 8 needed old world ROM but looks like it can also load it from disk on new world machines. Then what version of the ROM it has? It seems there was some change at ROM 5.2.1 then which solves the problem with usb and older versions may have done something differently and expect it to work unlike it's emulated now. The rom on the 8.6 Cd is version The disk utility on the CD cannot initialise a hard disk (something we had with some 9.0.4 versions too) This sentence seems to be unfinished, also the disk utility problem is maybe unrelated so just ignore that for now and focus on usb first. So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume later 9.x versions have at least this or newer Toolbox ROM) I think it's esasier to debug with OS X because it's easier to get logs and the drivers may also be open source so easier to check what's happening so let's just forget about MacOS9 for now and try to find out what changed between 10.1 and 10.2 in usb handling. It seems via=pmu provides usb mouse first, usb kbd second. With Mac OS 9.0.4 the second device will not work. With 10.0 / 10.1 both usb mouse and kbd do not work. These are added here: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 you could change the order but it does not matter if both needs to work. If it makes the first one work then maybe the older USB drivers only handle one port per bus? But then the problem in OS X may be different. Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I only see one bus: USB 0 into which both mouse and kdb are plugged. On the real G4 the mouse and kbd are each plugged into another bus, so I see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is the Apple USB controller). Then add mouse and kbd to different buses with: -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) -device usb-kbd,bus=usb1.0 (attaches to second bus). This then mimics what I see on real hardware. Should qemu-system-ppc by default provide the same? Does this solve the problem you have? No. OK so then we should not do that by default either unless we find it's needed for some reason. (You talk about via=cude above but I think it should be via=pmu. Is that a typo?) No, even with via-cuda the first usb bus is created: dev: pci-ohci, id "" masterbus = "" num-ports = 3 (0x3) firstport = 0 (0x0) addr = 0d.0 romfile = "" romsize = 4294967295 (0x) rombar = 1 (0x1) multifunction = false x-pcie-lnksta-dllla = true x-pcie-extcap-init = true failover_pair_id = "" acpi-index = 0 (0x0) class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100) bar 0: mem at 0x8008 [0x800800ff] bus: usb-bus.0 type usb-bus I now think in some cases the mouse falls back to adb when usb does not work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to the desktop. Can we disable usb-bus creation for via=cuda? Yes, try: qemu-system-ppc -M mac99,usb=no (I had to look at the code to find that out). If this helps mac_newworld.c could add another usb bus or do somerthing different to match real hardware but you have to convince Mark about that first... Also Mac keyboards have a hub where the mouse is usially connected. Does modeling that setup with QEMU help? No, same issues with that. Then it's probably not about how these ports are arranged but something about modeiling the hardware maybe (i.e. QEMU does something differently than real hardware and this confuses the driver). Other idea you could try is to boot 10.1 and 10.2 and compare the ioreg outputs for the USB devices to see if there are some differences or get the USB driver versions and try to find out what changed in them. I attempted to take a look, but without mouse/kbd it is difficult to get to ioreg ;-) You can set up tap or vmnet network, boot it with cuda, enable ssh then you can access it from there after booting usb config. (It may even work with user network somehow, I think there's an option to forward a port from the guest to host then you could access ssh that way without having to set up bridged networking but you'll need to find that option as I don't remember what it was but I think I've seen it somewhere. Maybe in qemu-system-ppc -help or some docs on QEMU networking somewhere.) Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan > wrote: > >> On Tue, 24 Jan 2023, Howard Spoelstra wrote: > >>> From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 > due > >> to > >>> the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would > be > >>> that these suffer the same usb issue) > >>> The real powermac3,1 AGP has no adb. > >> > >> And do these OSes run on real PowerMac3,1? If so then we likely have a > bug > >> in USB emulation so maybe that could be fixed? In any case my patch does > >> not change mac99 and this should continue to work. > >> > >>> via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly > only > >>> needed for Mac OS X 10.5 guest (for which the speed reported was hacked > >> to > >>> 900Mhz to fool the installer), but should support all Mac OS/OS X that > >> are > >>> now supported. > >> > >> Since via=pmu is what should be a real machine does it run OS X >=10.2 > >> already? > >> > > > > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 > > > > qemu-system-ppc status: > > 8.6 will not boot from CD or HD. > > 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 > > usb device problem > > 9.1 and 9.2 with via=pmu > > 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also > with > > an usb problem) > > 10.2 with via=pmu (but has serious graphics speed problem, also with > > via=cuda) > > 10.3 and 10.4 with via=pmu > > 10.5 only with via=pmu (but needs the 900Mhz speed hack). > > > > *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. > > I thought MacOS 8 needed old world ROM but looks like it can also load it > from disk on new world machines. Then what version of the ROM it has? > It seems there was some change at ROM 5.2.1 then which solves the problem > with usb and older versions may have done something differently and > expect it to work unlike it's emulated now. > > The rom on the 8.6 Cd is version The disk utility on the CD cannot initialise a hard disk (something we had with some 9.0.4 versions too) > So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which > may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume > later 9.x versions have at least this or newer Toolbox ROM) I think it's > esasier to debug with OS X because it's easier to get logs and the drivers > may also be open source so easier to check what's happening so let's just > forget about MacOS9 for now and try to find out what changed between 10.1 > and 10.2 in usb handling. > > > It seems via=pmu provides usb mouse first, usb kbd second. > > With Mac OS 9.0.4 the second device will not work. > > With 10.0 / 10.1 both usb mouse and kbd do not work. > > These are added here: > > > https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 > > you could change the order but it does not matter if both needs to work. > If it makes the first one work then maybe the older USB drivers only > handle one port per bus? But then the problem in OS X may be different. > > > Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by > default I > > only see one bus: USB 0 into which both mouse and kdb are plugged. > > On the real G4 the mouse and kbd are each plugged into another bus, so I > > see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. > > > > With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" > > We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is > > the Apple USB controller). > > > > Then add mouse and kbd to different buses with: > > -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) > > -device usb-kbd,bus=usb1.0 (attaches to second bus). > > > > This then mimics what I see on real hardware. Should qemu-system-ppc by > > default provide the same? > > Does this solve the problem you have? No. > (You talk about via=cude above but I > think it should be via=pmu. Is that a typo?) No, even with via-cuda the first usb bus is created: dev: pci-ohci, id "" masterbus = "" num-ports = 3 (0x3) firstport = 0 (0x0) addr = 0d.0 romfile = "" romsize = 4294967295 (0x) rombar = 1 (0x1) multifunction = false x-pcie-lnksta-dllla = true x-pcie-extcap-init = true failover_pair_id = "" acpi-index = 0 (0x0) class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100) bar 0: mem at 0x8008 [0x800800ff] bus: usb-bus.0 type usb-bus I now think in some cases the mouse falls back to adb when usb does not work. Hence the wiggling/clicking that is needed to get 9.0.4 to get to the desktop. Can we disable usb-bus creation for via=cuda? If this helps mac_newworld.c > could add another usb bus or do somerthing different to match real > hardware but
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, 24 Jan 2023, Howard Spoelstra wrote: On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan wrote: On Tue, 24 Jan 2023, Howard Spoelstra wrote: From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due to the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be that these suffer the same usb issue) The real powermac3,1 AGP has no adb. And do these OSes run on real PowerMac3,1? If so then we likely have a bug in USB emulation so maybe that could be fixed? In any case my patch does not change mac99 and this should continue to work. via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only needed for Mac OS X 10.5 guest (for which the speed reported was hacked to 900Mhz to fool the installer), but should support all Mac OS/OS X that are now supported. Since via=pmu is what should be a real machine does it run OS X >=10.2 already? A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 qemu-system-ppc status: 8.6 will not boot from CD or HD. 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 usb device problem 9.1 and 9.2 with via=pmu 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with an usb problem) 10.2 with via=pmu (but has serious graphics speed problem, also with via=cuda) 10.3 and 10.4 with via=pmu 10.5 only with via=pmu (but needs the 900Mhz speed hack). *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. I thought MacOS 8 needed old world ROM but looks like it can also load it from disk on new world machines. Then what version of the ROM it has? It seems there was some change at ROM 5.2.1 then which solves the problem with usb and older versions may have done something differently and expect it to work unlike it's emulated now. So it seems versions before 10.2 have a problem (except 9,1 and 9.2 which may have a newer usb driver maybe? also 9.0.4 with ROM 5.2.1 and I assume later 9.x versions have at least this or newer Toolbox ROM) I think it's esasier to debug with OS X because it's easier to get logs and the drivers may also be open source so easier to check what's happening so let's just forget about MacOS9 for now and try to find out what changed between 10.1 and 10.2 in usb handling. It seems via=pmu provides usb mouse first, usb kbd second. With Mac OS 9.0.4 the second device will not work. With 10.0 / 10.1 both usb mouse and kbd do not work. These are added here: https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L435 you could change the order but it does not matter if both needs to work. If it makes the first one work then maybe the older USB drivers only handle one port per bus? But then the problem in OS X may be different. Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I only see one bus: USB 0 into which both mouse and kdb are plugged. On the real G4 the mouse and kbd are each plugged into another bus, so I see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is the Apple USB controller). Then add mouse and kbd to different buses with: -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) -device usb-kbd,bus=usb1.0 (attaches to second bus). This then mimics what I see on real hardware. Should qemu-system-ppc by default provide the same? Does this solve the problem you have? (You talk about via=cude above but I think it should be via=pmu. Is that a typo?) If this helps mac_newworld.c could add another usb bus or do somerthing different to match real hardware but you have to convince Mark about that first... Also Mac keyboards have a hub where the mouse is usially connected. Does modeling that setup with QEMU help? Other idea you could try is to boot 10.1 and 10.2 and compare the ioteg outputs for the USB devices to see if there are some differences or get the USB driver versions and try to find out what changed in them. or even better updating the main docs in https://www.qemu.org/docs/master/system/ppc/powermac.html That would have to be taken up by someone else. That page is generated from this file in QEMU source: https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/ppc/powermac.rst you can submit a patch to that like I did: https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg6.html Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due > to > > the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be > > that these suffer the same usb issue) > > The real powermac3,1 AGP has no adb. > > And do these OSes run on real PowerMac3,1? If so then we likely have a bug > in USB emulation so maybe that could be fixed? In any case my patch does > not change mac99 and this should continue to work. > > > via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only > > needed for Mac OS X 10.5 guest (for which the speed reported was hacked > to > > 900Mhz to fool the installer), but should support all Mac OS/OS X that > are > > now supported. > > Since via=pmu is what should be a real machine does it run OS X >=10.2 > already? > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 qemu-system-ppc status: 8.6 will not boot from CD or HD. 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 usb device problem 9.1 and 9.2 with via=pmu 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with an usb problem) 10.2 with via=pmu (but has serious graphics speed problem, also with via=cuda) 10.3 and 10.4 with via=pmu 10.5 only with via=pmu (but needs the 900Mhz speed hack). *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. It seems via=pmu provides usb mouse first, usb kbd second. With Mac OS 9.0.4 the second device will not work. With 10.0 / 10.1 both usb mouse and kbd do not work. Real hardware provides two USB buses: USB 0 and USB 1. In Qemu by default I only see one bus: USB 0 into which both mouse and kdb are plugged. On the real G4 the mouse and kbd are each plugged into another bus, so I see the kbd on e.g. USB 0 and the mouse on e.g. USB 1. With -M mac99,via=cuda one USB bus is always created. It has id "usb-bus" We can add a second USB bus with e.g. -device pci-ohci,id=usb1 (this is the Apple USB controller). Then add mouse and kbd to different buses with: -device usb-mouse,bus=usb-bus.0(attaches to first and default bus) -device usb-kbd,bus=usb1.0 (attaches to second bus). This then mimics what I see on real hardware. Should qemu-system-ppc by default provide the same? > > via=pmu-adb seems only needed to trick mac os server installations that > > would later run on the g3beige. > > > > To my knowledge 32 bit Linux guests all require via=pmu > > See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC > > That doc might need some updating. It seems to be from before pegasos2 was > added. Maybe we would be better off linking from this page to others that > are more actively maintained such as: > https://www.emaculation.com/doku.php/qemu > and > http://zero.eik.bme.hu/~balaton/qemu/amiga/ > > I "maintain" that page with only general information. I can link to the specific sites you mention. > or even better updating the main docs in > > https://www.qemu.org/docs/master/system/ppc/powermac.html > > That would have to be taken up by someone else. Best, Howard
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, 24 Jan 2023, Howard Spoelstra wrote: From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due to the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be that these suffer the same usb issue) The real powermac3,1 AGP has no adb. And do these OSes run on real PowerMac3,1? If so then we likely have a bug in USB emulation so maybe that could be fixed? In any case my patch does not change mac99 and this should continue to work. via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only needed for Mac OS X 10.5 guest (for which the speed reported was hacked to 900Mhz to fool the installer), but should support all Mac OS/OS X that are now supported. Since via=pmu is what should be a real machine does it run OS X >=10.2 already? via=pmu-adb seems only needed to trick mac os server installations that would later run on the g3beige. To my knowledge 32 bit Linux guests all require via=pmu See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC That doc might need some updating. It seems to be from before pegasos2 was added. Maybe we would be better off linking from this page to others that are more actively maintained such as: https://www.emaculation.com/doku.php/qemu and http://zero.eik.bme.hu/~balaton/qemu/amiga/ or even better updating the main docs in https://www.qemu.org/docs/master/system/ppc/powermac.html or somehow link these sources together. Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Mon, 23 Jan 2023, Mark Cave-Ayland wrote: On 22/01/2023 22:07, BALATON Zoltan wrote: On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: On 12/01/2023 23:51, BALATON Zoltan wrote: On Thu, 12 Jan 2023, Howard Spoelstra wrote: On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote: On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: On 04/01/2023 21:59, BALATON Zoltan wrote: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 FWIW this information would be useful in the cover letter once we decide the way forward. Also as a reviewer, it is hard to keep track of all the changes if the series are constantly changing and with no changelog on the cover letter, which is why it takes me a while to review them. As a maintainer you could help reducing the size of the series and patches under review by queuing the patches that are already reviewed then hopefully there are only a few left to discuss. One reason for changing the series was to omit patches you've dismissed right away and move the ones reviewed or those you were less resistant about to the front so you could easily merge them and reduce the size of the remaining series that I'll have to roll and respin later. So queueing those you're already OK with could help making this clearer. The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Ultimately the issue you are trying to solve is this, which is that -M mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start is to create a new "g5niagara" machine type (including OpenBIOS) and make it a clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99. I don't get what you mean. Patch 4 introduces a new machine type called powermac7_3 (or g5niagara if you want) which is a clone of mac99 and then issues the warning to deprecate qemu-system-ppc64 -M mac99 in patch 5. Did you actually test these patches at all? More specifically, what I'm suggesting as well as creating a new machine name is that we clone mac_newworld.c into a separate file for the 64-bit Mac machine, declare it as compiled for PPC64 only, and put the deprecation there. By creating a separate file and separate machine type for OpenBIOS, it gives you the freedom to make changes to mac99 to move it towards a G4 AGP without having to worry about affecting any existing 64-bit users. This would create a lot of duplicated code and increase the nunber of machines to maintain so I don't think this is a good idea at this point. I also don't want to change any of these machines now. The mac99.via=pmu is sufficiently close to PowerMac3,1 already. All I want is to have separate machine names for the machines we emulate. This is to 1. resolve the confusion this causes to usesrs 2. allow deprecating old ways of specifying these so we can eventually get rid of those 3. and this will also allow later to split the implementation if we need to or add new machines from scratch that will fit in the new naming So what you propose is not
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Mon, Jan 23, 2023 at 11:06 PM Mark Cave-Ayland < mark.cave-ayl...@ilande.co.uk> wrote: > On 22/01/2023 22:07, BALATON Zoltan wrote: > > > On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: > >> On 12/01/2023 23:51, BALATON Zoltan wrote: > >>> On Thu, 12 Jan 2023, Howard Spoelstra wrote: > On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan > wrote: > > On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>> Setting emulated machine type with a property called "via" is > >>> confusing users so deprecate the "via" option in favour of newly > added > >>> explicit machine types. The default via=cuda option is not a valid > >>> config (no real Mac has this combination of hardware) so no machine > >>> type could be defined for that therefore it is kept for backwards > >>> compatibility with older QEMU versions for now but other options > >>> resembling real machines are deprecated. > >>> > >>> Signed-off-by: BALATON Zoltan > >> > >> I believe that people do use -M mac99,via=cuda to run some rare > versions > > of > >> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so > we > > would > >> want to keep this option somewhere. > > > > The idea is that after previous patches we now have machine types > for all > > other via option values (that also match real Mac machines) other > than > > via=cude but that is the default for mac99 so after the reprecation > period > > when the via option is removed mac99 (which is the same as > mac99,via=cuda) > > can remain for this use case (and for backward compatibility) until > the > > other machines are fixed to not need this any more. So all via > options are > > still available but as different machine types. > > > My 2 cents about naming: > It seems less important how the machines are named when their name is > not > covering their definition. F.i. the powermac3,1 never had adb, could > not be > equipped with a G3 cpu, did not run at 900Mhz. The closest possible > qemu-options based definition of a powermac3,1 (via=pmu) will not run > Mac > OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > already needed. > >>> > >>> What does that mean? Should we aim to emulate real Macs or are we > happy with the > >>> Franken-Mac we have now? The names also show what we intend to emulate > even though > >>> the emulation may not be complete or have bugs (this is also true for > other > >>> machines in QEMU where a lot of them are not fully emulated, only well > enough to > >>> boot guest OSes). > >>> > >>> Looks like everybody has forgotten the previous discussion and not > read the docs > >>> and deprecation patches where this is explained so I summarise the > proposed change > >>> here again: > >>> > >>> - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for > >>> the via option and when using it in qemu-system-ppc64 suggesting using > new > >>> machines instead so these could evetually be removed next year. > mac99,via=cuda is > >>> just mac99 so you can continue to use that, mac99 is not deprecated > and don't want > >>> to remove it. > >>> > >>> - qemu-system-ppc64 -M mac99 -> powermac7_3 > >>> > >>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > >>> > >>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > FWIW this information would be useful in the cover letter once we decide > the way > forward. Also as a reviewer, it is hard to keep track of all the changes > if the > series are constantly changing and with no changelog on the cover letter, > which is > why it takes me a while to review them. > > >>> The last one is one of the rare Macs that had adb and pmu, all others > with pmu > >>> usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 > hardware > >>> but more similar to g3beige and no ADB ports according to > >>> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > >>> > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > >>> > >>> The PowerMac7,3 seems to be matching the PCI device listing in the > comment at the > >>> beginning of mac_newworld.c and also this article: > >>> https://www.informit.com/articles/article.aspx?p=606582 > >>> > >>> What is the 2 USB devices problem? Is it the one we've debugged before > and found > >>> that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? > That could be > >>> fixed if there was somebody interested enough to provide a patch. > >>> > >>> But this series does not remove the mac99 and does not even deprecate > it. What it > >>> deprecates are the via option to select different machine types and > the automatic > >>> detection of ppc64 to emulate something different which are hard to > understand for > >>> users and caused several misunderstandings. It's much more clear to > have a > >>> separate machine
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On 22/01/2023 22:07, BALATON Zoltan wrote: On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: On 12/01/2023 23:51, BALATON Zoltan wrote: On Thu, 12 Jan 2023, Howard Spoelstra wrote: On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote: On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: On 04/01/2023 21:59, BALATON Zoltan wrote: Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this option somewhere. The idea is that after previous patches we now have machine types for all other via option values (that also match real Mac machines) other than via=cude but that is the default for mac99 so after the reprecation period when the via option is removed mac99 (which is the same as mac99,via=cuda) can remain for this use case (and for backward compatibility) until the other machines are fixed to not need this any more. So all via options are still available but as different machine types. My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. The closest possible qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is already needed. What does that mean? Should we aim to emulate real Macs or are we happy with the Franken-Mac we have now? The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 FWIW this information would be useful in the cover letter once we decide the way forward. Also as a reviewer, it is hard to keep track of all the changes if the series are constantly changing and with no changelog on the cover letter, which is why it takes me a while to review them. The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Ultimately the issue you are trying to solve is this, which is that -M mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start is to create a new "g5niagara" machine type
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: On 12/01/2023 23:51, BALATON Zoltan wrote: On Thu, 12 Jan 2023, Howard Spoelstra wrote: On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote: On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: On 04/01/2023 21:59, BALATON Zoltan wrote: Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this option somewhere. The idea is that after previous patches we now have machine types for all other via option values (that also match real Mac machines) other than via=cude but that is the default for mac99 so after the reprecation period when the via option is removed mac99 (which is the same as mac99,via=cuda) can remain for this use case (and for backward compatibility) until the other machines are fixed to not need this any more. So all via options are still available but as different machine types. My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. The closest possible qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is already needed. What does that mean? Should we aim to emulate real Macs or are we happy with the Franken-Mac we have now? The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Ultimately the issue you are trying to solve is this, which is that -M mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start is to create a new "g5niagara" machine type (including OpenBIOS) and make it a clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99. I don't get what you mean. Patch 4 introduces a new machine type called powermac7_3 (or g5niagara if you want) which is a clone of mac99 and then issues the warning to deprecate qemu-system-ppc64 -M
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On 12/01/2023 23:51, BALATON Zoltan wrote: On Thu, 12 Jan 2023, Howard Spoelstra wrote: On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote: On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: On 04/01/2023 21:59, BALATON Zoltan wrote: Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this option somewhere. The idea is that after previous patches we now have machine types for all other via option values (that also match real Mac machines) other than via=cude but that is the default for mac99 so after the reprecation period when the via option is removed mac99 (which is the same as mac99,via=cuda) can remain for this use case (and for backward compatibility) until the other machines are fixed to not need this any more. So all via options are still available but as different machine types. My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. The closest possible qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is already needed. What does that mean? Should we aim to emulate real Macs or are we happy with the Franken-Mac we have now? The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Ultimately the issue you are trying to solve is this, which is that -M mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start is to create a new "g5niagara" machine type (including OpenBIOS) and make it a clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99. The reason for suggesting this is that the number of users of qemu-system-ppc64 -M mac99 will be much smaller than those using qemu-system-ppc, which means there will be a lot less breakage for users. In the meantime we don't need to make a final decision
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, 13 Jan 2023, Howard Spoelstra wrote: On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan wrote: The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I personally do not oppose a name change, the new names seem more descriptive. I tested your patches and they behave as they should. The functionality does not change. However, my simple point was what's in a name when the underlying machine does not reflect what the name implies. In case of powermac3_1 (currently mac99,via=pmu) it does resemble the PowerMac3,1 G4 AGP machine. It's also what the device tree says and the emulated hardware corresponds to that machine, apart from some missing pieces (like I2C) and known bugs in some (like USB) it aims to emulate that machine but it's currently hidden in the obscure via option of mac99 which ny default is some non-existent Mac like machine with cuda. It's much easier for users not having inside knowledge of QEMU to get a machine type which clearly says what it emulates. If we ever want to run firmware ROM from the real machine we also want to make sure we emulate a real machine. I've done some steps in that direction before and submitted RFC patches that could get to an OF prompt with some debugger tweaking and could eventually made to work but it needs Mark's screamer series to get finished and some rewrite of the macio emulation to add I2C cleanly so it's stalled currently but maybe one day we'll get there. For powermac7,3 it is what qemu-system-ppc64 -M mac99 currently aims to emulate evidenced by the comment at the beginning and that it adds U3 chipset instead of Uninorth but currently only Linux boots on this machine. It may need some more fixes to get other OSes running starting with the device tree. I think the way for that is to move device tree creation to QEMU similar to what other PPC machines do. I have plans for that but it's blocked by not being able to contribute to OpenBIOS as most of my patches are disliked by Mark but I'll keep trying. The powerboot3,2 is one hardware I could find info on having PMU and ADB and it's the same era as the PowerMac3,1 so has similar hardware but not sure why this combination is even there. What guest needs this that cannot run with either mac99 or powermac3,1? It is not my place to comment on a possible development agenda. I can only tell you what I'd like and point out issues. - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. It is not about passing through USB devices and active packets per endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting Mac OS 9.0.4 with via=pmu it will support only one (the kbd). When started with via=cuda -usb -device usb-kbd -device usb-mouse it will support the first-mentioned usb-kbd. When kbd and mouse arguments are reversed it supports the other device ;-) Is this something that happens on real hardware as well or is it some bug in emulation somewhere? If the drivers on this OS keep active packets on different endpoints then it's the same issue we've discovered with USB pass through of audio devices that also need this feature. If it's something else it may be fixable but we need to understand first what causes the issue. Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan wrote: > On Thu, 12 Jan 2023, Howard Spoelstra wrote: > > On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan > wrote: > > > >> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >>> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>> > Setting emulated machine type with a property called "via" is > confusing users so deprecate the "via" option in favour of newly added > explicit machine types. The default via=cuda option is not a valid > config (no real Mac has this combination of hardware) so no machine > type could be defined for that therefore it is kept for backwards > compatibility with older QEMU versions for now but other options > resembling real machines are deprecated. > > Signed-off-by: BALATON Zoltan > >>> > >>> I believe that people do use -M mac99,via=cuda to run some rare > versions > >> of > >>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we > >> would > >>> want to keep this option somewhere. > >> > >> The idea is that after previous patches we now have machine types for > all > >> other via option values (that also match real Mac machines) other than > >> via=cude but that is the default for mac99 so after the reprecation > period > >> when the via option is removed mac99 (which is the same as > mac99,via=cuda) > >> can remain for this use case (and for backward compatibility) until the > >> other machines are fixed to not need this any more. So all via options > are > >> still available but as different machine types. > >> > > My 2 cents about naming: > > It seems less important how the machines are named when their name is not > > covering their definition. F.i. the powermac3,1 never had adb, could not > be > > equipped with a G3 cpu, did not run at 900Mhz. The closest possible > > qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac > > OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > > already needed. > > What does that mean? Should we aim to emulate real Macs or are we happy > with the Franken-Mac we have now? > The names also show what we intend to > emulate even though the emulation may not be complete or have bugs (this > is also true for other machines in QEMU where a lot of them are not fully > emulated, only well enough to boot guest OSes). > > Looks like everybody has forgotten the previous discussion and not read > the docs and deprecation patches where this is explained so I summarise > the proposed change here again: > > No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I personally do not oppose a name change, the new names seem more descriptive. I tested your patches and they behave as they should. The functionality does not change. However, my simple point was what's in a name when the underlying machine does not reflect what the name implies. It is not my place to comment on a possible development agenda. I can only tell you what I'd like and point out issues. > - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for the via option and when using it in qemu-system-ppc64 suggesting > using new machines instead so these could evetually be removed next year. > mac99,via=cuda is just mac99 so you can continue to use that, mac99 is > not deprecated and don't want to remove it. > > - qemu-system-ppc64 -M mac99 -> powermac7_3 > > - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > > - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > The last one is one of the rare Macs that had adb and pmu, all others with > pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 > hardware but more similar to g3beige and no ADB ports according to > https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > > The PowerMac7,3 seems to be matching the PCI device listing in the comment > at the beginning of mac_newworld.c and also this article: > https://www.informit.com/articles/article.aspx?p=606582 > > What is the 2 USB devices problem? Is it the one we've debugged before and > found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? > That could be fixed if there was somebody interested enough to provide a > patch. > It is not about passing through USB devices and active packets per endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting Mac OS 9.0.4 with via=pmu it will support only one (the kbd). When started with via=cuda -usb -device usb-kbd -device usb-mouse it will support the first-mentioned usb-kbd. When kbd and mouse arguments are reversed it supports the other device ;-) > > But this series does not remove the mac99 and does not even deprecate it. > What it deprecates are the via option to select different machine types > and the automatic detection of ppc64 to emulate something different which > are hard to understand for
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Thu, 12 Jan 2023, Howard Spoelstra wrote: On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote: On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: On 04/01/2023 21:59, BALATON Zoltan wrote: Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this option somewhere. The idea is that after previous patches we now have machine types for all other via option values (that also match real Mac machines) other than via=cude but that is the default for mac99 so after the reprecation period when the via option is removed mac99 (which is the same as mac99,via=cuda) can remain for this use case (and for backward compatibility) until the other machines are fixed to not need this any more. So all via options are still available but as different machine types. My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. The closest possible qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is already needed. What does that mean? Should we aim to emulate real Macs or are we happy with the Franken-Mac we have now? The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Regards, BALATON Zoltan
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan wrote:
> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> > On 04/01/2023 21:59, BALATON Zoltan wrote:
> >
> >> Setting emulated machine type with a property called "via" is
> >> confusing users so deprecate the "via" option in favour of newly added
> >> explicit machine types. The default via=cuda option is not a valid
> >> config (no real Mac has this combination of hardware) so no machine
> >> type could be defined for that therefore it is kept for backwards
> >> compatibility with older QEMU versions for now but other options
> >> resembling real machines are deprecated.
> >>
> >> Signed-off-by: BALATON Zoltan
> >
> > I believe that people do use -M mac99,via=cuda to run some rare versions
> of
> > MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we
> would
> > want to keep this option somewhere.
>
> The idea is that after previous patches we now have machine types for all
> other via option values (that also match real Mac machines) other than
> via=cude but that is the default for mac99 so after the reprecation period
> when the via option is removed mac99 (which is the same as mac99,via=cuda)
> can remain for this use case (and for backward compatibility) until the
> other machines are fixed to not need this any more. So all via options are
> still available but as different machine types.
>
>
My 2 cents about naming:
It seems less important how the machines are named when their name is not
covering their definition. F.i. the powermac3,1 never had adb, could not be
equipped with a G3 cpu, did not run at 900Mhz. The closest possible
qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac
OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is
already needed.
>
> >> ---
> >> hw/ppc/mac_newworld.c | 9 +
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> >> index f07c37328b..adf185bd3a 100644
> >> --- a/hw/ppc/mac_newworld.c
> >> +++ b/hw/ppc/mac_newworld.c
> >> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
> >> if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> >> warn_report("mac99 with G5 CPU is deprecated, "
> >> "use powermac7_3 instead");
> >> +} else {
> >> +if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
> >> +warn_report("mac99,via=pmu is deprecated, "
> >> +"use powermac3_1 instead");
> >> +}
> >> +if (core99_machine->via_config ==
> CORE99_VIA_CONFIG_PMU_ADB) {
> >> +warn_report("mac99,via=pmu-adb is deprecated, "
> >> +"use powerbook3_2 instead");
> >> +}
> >> }
> >> }
> >> /* allocate RAM */
> >
> >
> > ATB,
> >
> > Mark.
> >
> >
>
>
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
On 04/01/2023 21:59, BALATON Zoltan wrote:
Setting emulated machine type with a property called "via" is
confusing users so deprecate the "via" option in favour of newly added
explicit machine types. The default via=cuda option is not a valid
config (no real Mac has this combination of hardware) so no machine
type could be defined for that therefore it is kept for backwards
compatibility with older QEMU versions for now but other options
resembling real machines are deprecated.
Signed-off-by: BALATON Zoltan
I believe that people do use -M mac99,via=cuda to run some rare versions of
MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would
want to keep this option somewhere.
The idea is that after previous patches we now have machine types for all
other via option values (that also match real Mac machines) other than
via=cude but that is the default for mac99 so after the reprecation period
when the via option is removed mac99 (which is the same as mac99,via=cuda)
can remain for this use case (and for backward compatibility) until the
other machines are fixed to not need this any more. So all via options are
still available but as different machine types.
Regards,
BALATON Zoltan
---
hw/ppc/mac_newworld.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index f07c37328b..adf185bd3a 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
warn_report("mac99 with G5 CPU is deprecated, "
"use powermac7_3 instead");
+} else {
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
+warn_report("mac99,via=pmu is deprecated, "
+"use powermac3_1 instead");
+}
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
+warn_report("mac99,via=pmu-adb is deprecated, "
+"use powerbook3_2 instead");
+}
}
}
/* allocate RAM */
ATB,
Mark.
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On 04/01/2023 21:59, BALATON Zoltan wrote:
Setting emulated machine type with a property called "via" is
confusing users so deprecate the "via" option in favour of newly added
explicit machine types. The default via=cuda option is not a valid
config (no real Mac has this combination of hardware) so no machine
type could be defined for that therefore it is kept for backwards
compatibility with older QEMU versions for now but other options
resembling real machines are deprecated.
Signed-off-by: BALATON Zoltan
I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in
QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this
option somewhere.
---
hw/ppc/mac_newworld.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index f07c37328b..adf185bd3a 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
warn_report("mac99 with G5 CPU is deprecated, "
"use powermac7_3 instead");
+} else {
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
+warn_report("mac99,via=pmu is deprecated, "
+"use powermac3_1 instead");
+}
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
+warn_report("mac99,via=pmu-adb is deprecated, "
+"use powerbook3_2 instead");
+}
}
}
/* allocate RAM */
ATB,
Mark.
Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
On 4/1/23 22:59, BALATON Zoltan wrote: Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan --- hw/ppc/mac_newworld.c | 9 + 1 file changed, 9 insertions(+) Don't we need to document in the 'System emulator machines' section of docs/about/deprecated.rst? (maybe within a "machine options" subsection)
[PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
Setting emulated machine type with a property called "via" is
confusing users so deprecate the "via" option in favour of newly added
explicit machine types. The default via=cuda option is not a valid
config (no real Mac has this combination of hardware) so no machine
type could be defined for that therefore it is kept for backwards
compatibility with older QEMU versions for now but other options
resembling real machines are deprecated.
Signed-off-by: BALATON Zoltan
---
hw/ppc/mac_newworld.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index f07c37328b..adf185bd3a 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine)
if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
warn_report("mac99 with G5 CPU is deprecated, "
"use powermac7_3 instead");
+} else {
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) {
+warn_report("mac99,via=pmu is deprecated, "
+"use powermac3_1 instead");
+}
+if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
+warn_report("mac99,via=pmu-adb is deprecated, "
+"use powerbook3_2 instead");
+}
}
}
/* allocate RAM */
--
2.30.6
