Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option

[BALATON Zoltan]

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 9.0.4, 9.1
> and 9.2 are available here:
> https://surfdrive.surf.nl/files/index.php/s/1wcC3GGaagqKVpj/download

This ioreg output is truncated. Use ioreg -w 0 -l to get a full output.

Regards,
BALATON Zoltan