On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan <bala...@eik.bme.hu> 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 <bala...@eik.bme.hu>
> 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: 00000000-0000-0000-0000-000000000000
> >>>>> CPU type PowerPC,G4
> >>> milliseconds isn't unique.
> >>>>> switching to new context:
> >>>>> call-method slw_update_keymap failed with error ffffffdf
> >>>>> call-method slw_update_keymap failed with error ffffffdf
> >>> 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 xnu kernel:
>
>
> https://github.com/apple-oss-distributions/xnu/tree/xnu-123.5/iokit/Families/IOHIDSystem
>
> I don't quite know how it works and where it starts running but a large
> part of it looks like it handles key mapping. While booting I see an error
> from OpenBIOS saying:
>
> >> call-method slw_update_keymap failed with error ffffffdf
>
> Could this be related to the problem? What is this error about? This
> PearPC bug has some info on where it may come from:
>
>
This seem to come from here:
https://web.archive.org/web/20150922180615/http://www.opensource.apple.com/source/BootX/BootX-45/bootx.tproj/ci.subproj/sl_words.c


> https://github.com/sebastianbiallas/pearpc/issues/4
>
> but I don't know if any of this is relevant.
>
> Regards,
> BALATON Zoltan
>

Reply via email to