| Message ID | alpine.BSF.2.20.1608090128080.83074@zero.eik.bme.hu |
|---|---|
| State | New |
| Headers | show |
On Tue, 2016-08-09 at 02:11 +0200, BALATON Zoltan wrote: > I don't know much about this but I've read here > > <http://mcosre.sourceforge.net/docs/apple_io.html> that there are three > different kind of chips: CUDA, PMU99 and PMU. Confusingly both PMU-s are > > called via-pmu by Apple. And there's Egret ... ;-) No really we don't care. There's more than 2 kinds in fact, it's just depends whatever microcontroller's in there. But it's the same protocol. It's always connected to the VIA. > I think we want PMU99 which is found on desktop > machines and not PMU found in Powerbooks (unless we want to emulate that) > > because PMU99 has less features and more similar to CUDA. PMU99 doesn't have "less" features, it's the same in the desktop G4 and a PowerBook G4. I will eventually add some of the powerbook'ish features so we can support sleep ... > But it has some > differences such as a different interrupt mentioned in this page and maybe > > others. The different interrupt is just a hack they did with KeyLargo ASIC, instead of using the VIA CB1, it uses a GPIO to signal that the OS needs to fetch interrupt conditions, but that's about it. The basic VIA SR interrupt is still used for the basic shifting. > However, desktop machines have no ADB so I'm not sure why we have > > one still in QEMU. Because PowerBooks do (or rather a PMU-simulation of ADB) and MacOS doesn't care. If ADB is in the device-tree, it will use it. It makes things easier to support multiple combinations especially when "comparing" things for debug. Additionally, USB doesn't work well in OpenBIOS at this point ;-) Also, I have some evil plan to change the way ADB autopoll works in Qemu so that the devices signal the PMU when they want to talk. That will avoid having yet another 30-something HZ timer ticking in qemu, and in that regard will probably be more efficient (read: slows down the emulator less) than OHCI. > If USB is working then we don't need ADB with PMU99 and > > that could resolve all the problems with it. I have solved the ADB problems so there's nothing left to solve here :- ) But see above why I think it's a good idea to keep ADB as an option. > We can keep it to old world > beige G3 with CUDA where it works. I think only some Powerbooks have PMU > > and ADB but we are not targeting that. Why not ? > Here's an (untested) patch for > switching to using USB keyboard and mouse instead of ADB unless USB is > disabled. (The device tree should be changed accordingly in OpenBIOS.) Not > sure if this is helpful. Don't bother just yet, as I said, I am reworking all of that code. I will probably just create various -machine options so you can chose what bits and pieces you want to put togeher, ie, CUDA, PMU, with or without ADB, which machine model string to expose to the OS etc... Cheers, Ben. > > --
On Tue, 9 Aug 2016, Benjamin Herrenschmidt wrote: > On Tue, 2016-08-09 at 02:11 +0200, BALATON Zoltan wrote: >> I don't know much about this but I've read here >>> <http://mcosre.sourceforge.net/docs/apple_io.html> that there are three >> different kind of chips: CUDA, PMU99 and PMU. Confusingly both PMU-s are >>> called via-pmu by Apple. > > And there's Egret ... ;-) Right, for completeness, but that's only in very old machines we don't emulate in QEMU. >> However, desktop machines have no ADB so I'm not sure why we have >>> one still in QEMU. > > Because PowerBooks do (or rather a PMU-simulation of ADB) and MacOS > doesn't care. If ADB is in the device-tree, it will use it. It makes > things easier to support multiple combinations especially when > "comparing" things for debug. > > Additionally, USB doesn't work well in OpenBIOS at this point ;-) In what way? Keyboard works. What else is needed? > Also, I have some evil plan to change the way ADB autopoll works in > Qemu so that the devices signal the PMU when they want to talk. That > will avoid having yet another 30-something HZ timer ticking in qemu, > and in that regard will probably be more efficient (read: slows down > the emulator less) than OHCI. OK, this is a really nice thing and justifies having an ADB bus. (This would also likely fix mouse problems seen by others.) >> If USB is working then we don't need ADB with PMU99 and >>> that could resolve all the problems with it. > > I have solved the ADB problems so there's nothing left to solve here :- > ) But see above why I think it's a good idea to keep ADB as an option. > >> We can keep it to old world >> beige G3 with CUDA where it works. I think only some Powerbooks have PMU >>> and ADB but we are not targeting that. > > Why not ? Just thought emulating all the additional details for Powerbook power management might be difficult. But if you're willing to go there I won't stop you. :-) Obviously you understand this very well so maybe it's not that difficult for you. >> Here's an (untested) patch for >> switching to using USB keyboard and mouse instead of ADB unless USB is >> disabled. (The device tree should be changed accordingly in OpenBIOS.) Not >> sure if this is helpful. > > Don't bother just yet, as I said, I am reworking all of that code. I will > probably just create various -machine options so you can chose what bits > and pieces you want to put togeher, ie, CUDA, PMU, with or without ADB, > which machine model string to expose to the OS etc... Cool, looking forward to it. Thanks for all the great stuff you did for this and keep it up. Regards, BALATON Zoltan
On Tue, 2016-08-09 at 03:31 +0200, BALATON Zoltan wrote: > > > Because PowerBooks do (or rather a PMU-simulation of ADB) and MacOS > > doesn't care. If ADB is in the device-tree, it will use it. It makes > > things easier to support multiple combinations especially when > > "comparing" things for debug. > > > > Additionally, USB doesn't work well in OpenBIOS at this point ;-) > > In what way? Keyboard works. What else is needed? Doesnt' work for me half of the time, I haven't dug into why yet. > > Also, I have some evil plan to change the way ADB autopoll works in > > Qemu so that the devices signal the PMU when they want to talk. That > > will avoid having yet another 30-something HZ timer ticking in qemu, > > and in that regard will probably be more efficient (read: slows down > > the emulator less) than OHCI. > > OK, this is a really nice thing and justifies having an ADB bus. (This > would also likely fix mouse problems seen by others.) Possibly ;-) The tracking in OS 9 at least is still done by a timer inside MacOS itself. With my latest ndrv it's running at 30Hz. I'm looking at maybe doing some kind of paravirt hack to make it adaptative on whether there is actual movement on the cursor, but that's for later. > > Why not ? > > Just thought emulating all the additional details for Powerbook power > management might be difficult. But if you're willing to go there I won't > stop you. :-) Obviously you understand this very well so maybe it's not > that difficult for you. Well, I wrote most of the corresponding Linux code so it's mostly a matter of swapping that knowledge back into my brain from lossy long term storage and finding all the MacOS 9 bugs along the way :-) > > > > > > Here's an (untested) patch for > > > switching to using USB keyboard and mouse instead of ADB unless USB is > > > disabled. (The device tree should be changed accordingly in OpenBIOS.) Not > > > sure if this is helpful. > > > > Don't bother just yet, as I said, I am reworking all of that code. I will > > probably just create various -machine options so you can chose what bits > > and pieces you want to put togeher, ie, CUDA, PMU, with or without ADB, > > which machine model string to expose to the OS etc... > > Cool, looking forward to it. Thanks for all the great stuff you did for > this and keep it up. Cheers, Ben.
On Tue, Aug 9, 2016 at 6:06 AM, Benjamin Herrenschmidt < benh@kernel.crashing.org> wrote: > On Tue, 2016-08-09 at 03:31 +0200, BALATON Zoltan wrote: > > > > > Because PowerBooks do (or rather a PMU-simulation of ADB) and MacOS > > > doesn't care. If ADB is in the device-tree, it will use it. It makes > > > things easier to support multiple combinations especially when > > > "comparing" things for debug. > > > > > > Additionally, USB doesn't work well in OpenBIOS at this point ;-) > > > > In what way? Keyboard works. What else is needed? > > Doesnt' work for me half of the time, I haven't dug into why yet. > > > > Also, I have some evil plan to change the way ADB autopoll works in > > > Qemu so that the devices signal the PMU when they want to talk. That > > > will avoid having yet another 30-something HZ timer ticking in qemu, > > > and in that regard will probably be more efficient (read: slows down > > > the emulator less) than OHCI. > > > > OK, this is a really nice thing and justifies having an ADB bus. (This > > would also likely fix mouse problems seen by others.) > > Possibly ;-) The tracking in OS 9 at least is still done by a timer > inside MacOS itself. With my latest ndrv it's running at 30Hz. I'm > looking at maybe doing some kind of paravirt hack to make it adaptative > on whether there is actual movement on the cursor, but that's for later. > > > > Why not ? > > > > Just thought emulating all the additional details for Powerbook power > > management might be difficult. But if you're willing to go there I won't > > stop you. :-) Obviously you understand this very well so maybe it's not > > that difficult for you. > > Well, I wrote most of the corresponding Linux code so it's mostly a matter > of swapping that knowledge back into my brain from lossy long term storage > and finding all the MacOS 9 bugs along the way :-) > > > > > > > > > Here's an (untested) patch for > > > > switching to using USB keyboard and mouse instead of ADB unless USB > is > > > > disabled. (The device tree should be changed accordingly in > OpenBIOS.) Not > > > > sure if this is helpful. > > > > > > Don't bother just yet, as I said, I am reworking all of that code. I > will > > > probably just create various -machine options so you can chose what > bits > > > and pieces you want to put togeher, ie, CUDA, PMU, with or without ADB, > > > which machine model string to expose to the OS etc... > > > > Cool, looking forward to it. Thanks for all the great stuff you did for > > this and keep it up. > > Cheers, > Ben. > > Openbios has problems with the USB keyboard when one specifically defines e.g., -device ich9-usb-uhci1,id=newusb -device usb-mouse,bus=newusb.0 (which is needed to get mouse/keyboard going in OSX 10.5)
On Tue, 9 Aug 2016, Howard Spoelstra wrote: > Openbios has problems with the USB keyboard when one specifically defines > e.g., -device ich9-usb-uhci1,id=newusb -device usb-mouse,bus=newusb.0 > (which is needed to get mouse/keyboard going in OSX 10.5) I think it does not have a UHCI driver, only minimal HID support on OHCI. I could not reproduce a problem with this command on the master HEAD version, only if I create a usb-kbd explicitely with -device is when it does not work. Creating only a usb-mouse on either pci-ohci or ich9-usb-uhci1 (does that make sense on a PPC Mac?) seems working for me and still have keyboard in OpenBIOS but adding a keyboard this way indeed has a problem. Regards, BALATON Zoltan
On Tue, 2016-08-09 at 12:26 +0200, BALATON Zoltan wrote: > On Tue, 9 Aug 2016, Howard Spoelstra wrote: > > > > Openbios has problems with the USB keyboard when one specifically defines > > e.g., -device ich9-usb-uhci1,id=newusb -device usb-mouse,bus=newusb.0 > > (which is needed to get mouse/keyboard going in OSX 10.5) > > I think it does not have a UHCI driver, only minimal HID support on OHCI. > I could not reproduce a problem with this command on the master HEAD > version, only if I create a usb-kbd explicitely with -device is when it > does not work. Creating only a usb-mouse on either pci-ohci or > ich9-usb-uhci1 (does that make sense on a PPC Mac?) seems working for me > and still have keyboard in OpenBIOS but adding a keyboard this way indeed > has a problem. UHCI definitely doesn't make sense on a ppc mac. OHCI and EHCI do. Cheers, Ben.
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index 7d25106..bf8ad9b 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -418,24 +418,21 @@ static void ppc_core99_init(MachineState *machine) "ide[1]")); macio_ide_init_drives(macio_ide, &hd[MAX_IDE_DEVS]); - dev = DEVICE(object_resolve_path_component(OBJECT(macio), "cuda")); - adb_bus = qdev_get_child_bus(dev, "adb.0"); - dev = qdev_create(adb_bus, TYPE_ADB_KEYBOARD); - qdev_init_nofail(dev); - dev = qdev_create(adb_bus, TYPE_ADB_MOUSE); - qdev_init_nofail(dev); - if (machine->usb) { pci_create_simple(pci_bus, -1, "pci-ohci"); - /* U3 needs to use USB for input because Linux doesn't support via-cuda - on PPC64 */ - if (machine_arch == ARCH_MAC99_U3) { - USBBus *usb_bus = usb_bus_find(-1); + /* New world machines have USB instead of ADB */ + USBBus *usb_bus = usb_bus_find(-1); - usb_create_simple(usb_bus, "usb-kbd"); - usb_create_simple(usb_bus, "usb-mouse"); - } + usb_create_simple(usb_bus, "usb-kbd"); + usb_create_simple(usb_bus, "usb-mouse"); + } else { + dev = DEVICE(object_resolve_path_component(OBJECT(macio), "cuda")); + adb_bus = qdev_get_child_bus(dev, "adb.0"); + dev = qdev_create(adb_bus, TYPE_ADB_KEYBOARD); + qdev_init_nofail(dev); + dev = qdev_create(adb_bus, TYPE_ADB_MOUSE); + qdev_init_nofail(dev); } pci_vga_init(pci_bus);