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

[Howard Spoelstra]

On Tue, Jan 24, 2023 at 4:33 PM BALATON Zoltan <balaton@eik.bme.hu> wrote:

On Tue, 24 Jan 2023, Howard Spoelstra wrote:
> On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <balaton@eik.bme.hu> 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 (0xffffffff)
>        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 0x80080000 [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 \
-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.

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

-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

Best,

Howard