On Tue, Jan 24, 2023 at 4:33 PM BALATON Zoltan <bala...@eik.bme.hu> wrote:
> On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <bala...@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
