| Message ID | 4162db13bd1da9c6ddd77f185cef738e44790467.1672868854.git.balaton@eik.bme.hu |
|---|---|
| State | New |
| Headers | show |
| Series | Misc ppc/mac machines clean up | expand |
On 4/1/23 22:59, BALATON Zoltan wrote: > Setting emulated machine type with a property called "via" is > confusing users so deprecate the "via" option in favour of newly added > explicit machine types. The default via=cuda option is not a valid > config (no real Mac has this combination of hardware) so no machine > type could be defined for that therefore it is kept for backwards > compatibility with older QEMU versions for now but other options > resembling real machines are deprecated. > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > --- > hw/ppc/mac_newworld.c | 9 +++++++++ > 1 file changed, 9 insertions(+) Don't we need to document in the 'System emulator machines' section of docs/about/deprecated.rst? (maybe within a "machine options" subsection)
On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote: > On 4/1/23 22:59, BALATON Zoltan wrote: >> Setting emulated machine type with a property called "via" is >> confusing users so deprecate the "via" option in favour of newly added >> explicit machine types. The default via=cuda option is not a valid >> config (no real Mac has this combination of hardware) so no machine >> type could be defined for that therefore it is kept for backwards >> compatibility with older QEMU versions for now but other options >> resembling real machines are deprecated. >> >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >> --- >> hw/ppc/mac_newworld.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) > > Don't we need to document in the 'System emulator machines' > section of docs/about/deprecated.rst? (maybe within a > "machine options" subsection) That's in patch 7 for now which contains all the docs updates in one patch, I can reorganise these once we decide what should each patch contain. Options could be to make all deprecations a single patch or divide it by machines or options like one patch for ppc64 mac99 another for via option os whatever Matk is ready to accept at the end. Regards, BALATON Zoltan
On 04/01/2023 21:59, BALATON Zoltan wrote: > Setting emulated machine type with a property called "via" is > confusing users so deprecate the "via" option in favour of newly added > explicit machine types. The default via=cuda option is not a valid > config (no real Mac has this combination of hardware) so no machine > type could be defined for that therefore it is kept for backwards > compatibility with older QEMU versions for now but other options > resembling real machines are deprecated. > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> I believe that people do use -M mac99,via=cuda to run some rare versions of MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would want to keep this option somewhere. > --- > hw/ppc/mac_newworld.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > index f07c37328b..adf185bd3a 100644 > --- a/hw/ppc/mac_newworld.c > +++ b/hw/ppc/mac_newworld.c > @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine) > if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) { > warn_report("mac99 with G5 CPU is deprecated, " > "use powermac7_3 instead"); > + } else { > + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) { > + warn_report("mac99,via=pmu is deprecated, " > + "use powermac3_1 instead"); > + } > + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) { > + warn_report("mac99,via=pmu-adb is deprecated, " > + "use powerbook3_2 instead"); > + } > } > } > /* allocate RAM */ ATB, Mark.
On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > On 04/01/2023 21:59, BALATON Zoltan wrote: > >> Setting emulated machine type with a property called "via" is >> confusing users so deprecate the "via" option in favour of newly added >> explicit machine types. The default via=cuda option is not a valid >> config (no real Mac has this combination of hardware) so no machine >> type could be defined for that therefore it is kept for backwards >> compatibility with older QEMU versions for now but other options >> resembling real machines are deprecated. >> >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > > I believe that people do use -M mac99,via=cuda to run some rare versions of > MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we would > want to keep this option somewhere. The idea is that after previous patches we now have machine types for all other via option values (that also match real Mac machines) other than via=cude but that is the default for mac99 so after the reprecation period when the via option is removed mac99 (which is the same as mac99,via=cuda) can remain for this use case (and for backward compatibility) until the other machines are fixed to not need this any more. So all via options are still available but as different machine types. Regards, BALATON Zoltan >> --- >> hw/ppc/mac_newworld.c | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c >> index f07c37328b..adf185bd3a 100644 >> --- a/hw/ppc/mac_newworld.c >> +++ b/hw/ppc/mac_newworld.c >> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine) >> if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) { >> warn_report("mac99 with G5 CPU is deprecated, " >> "use powermac7_3 instead"); >> + } else { >> + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) { >> + warn_report("mac99,via=pmu is deprecated, " >> + "use powermac3_1 instead"); >> + } >> + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) { >> + warn_report("mac99,via=pmu-adb is deprecated, " >> + "use powerbook3_2 instead"); >> + } >> } >> } >> /* allocate RAM */ > > > ATB, > > Mark. > >
On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > > On 04/01/2023 21:59, BALATON Zoltan wrote: > > > >> Setting emulated machine type with a property called "via" is > >> confusing users so deprecate the "via" option in favour of newly added > >> explicit machine types. The default via=cuda option is not a valid > >> config (no real Mac has this combination of hardware) so no machine > >> type could be defined for that therefore it is kept for backwards > >> compatibility with older QEMU versions for now but other options > >> resembling real machines are deprecated. > >> > >> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > > > > I believe that people do use -M mac99,via=cuda to run some rare versions > of > > MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we > would > > want to keep this option somewhere. > > The idea is that after previous patches we now have machine types for all > other via option values (that also match real Mac machines) other than > via=cude but that is the default for mac99 so after the reprecation period > when the via option is removed mac99 (which is the same as mac99,via=cuda) > can remain for this use case (and for backward compatibility) until the > other machines are fixed to not need this any more. So all via options are > still available but as different machine types. > > My 2 cents about naming: It seems less important how the machines are named when their name is not covering their definition. F.i. the powermac3,1 never had adb, could not be equipped with a G3 cpu, did not run at 900Mhz. The closest possible qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is already needed. > > >> --- > >> hw/ppc/mac_newworld.c | 9 +++++++++ > >> 1 file changed, 9 insertions(+) > >> > >> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > >> index f07c37328b..adf185bd3a 100644 > >> --- a/hw/ppc/mac_newworld.c > >> +++ b/hw/ppc/mac_newworld.c > >> @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine) > >> if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) { > >> warn_report("mac99 with G5 CPU is deprecated, " > >> "use powermac7_3 instead"); > >> + } else { > >> + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) { > >> + warn_report("mac99,via=pmu is deprecated, " > >> + "use powermac3_1 instead"); > >> + } > >> + if (core99_machine->via_config == > CORE99_VIA_CONFIG_PMU_ADB) { > >> + warn_report("mac99,via=pmu-adb is deprecated, " > >> + "use powerbook3_2 instead"); > >> + } > >> } > >> } > >> /* allocate RAM */ > > > > > > ATB, > > > > Mark. > > > > > >
On Thu, 12 Jan 2023, Howard Spoelstra wrote: > On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: > >> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: >>> On 04/01/2023 21:59, BALATON Zoltan wrote: >>> >>>> Setting emulated machine type with a property called "via" is >>>> confusing users so deprecate the "via" option in favour of newly added >>>> explicit machine types. The default via=cuda option is not a valid >>>> config (no real Mac has this combination of hardware) so no machine >>>> type could be defined for that therefore it is kept for backwards >>>> compatibility with older QEMU versions for now but other options >>>> resembling real machines are deprecated. >>>> >>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>> >>> I believe that people do use -M mac99,via=cuda to run some rare versions >> of >>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we >> would >>> want to keep this option somewhere. >> >> The idea is that after previous patches we now have machine types for all >> other via option values (that also match real Mac machines) other than >> via=cude but that is the default for mac99 so after the reprecation period >> when the via option is removed mac99 (which is the same as mac99,via=cuda) >> can remain for this use case (and for backward compatibility) until the >> other machines are fixed to not need this any more. So all via options are >> still available but as different machine types. >> > My 2 cents about naming: > It seems less important how the machines are named when their name is not > covering their definition. F.i. the powermac3,1 never had adb, could not be > equipped with a G3 cpu, did not run at 900Mhz. The closest possible > qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac > OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > already needed. What does that mean? Should we aim to emulate real Macs or are we happy with the Franken-Mac we have now? The names also show what we intend to emulate even though the emulation may not be complete or have bugs (this is also true for other machines in QEMU where a lot of them are not fully emulated, only well enough to boot guest OSes). Looks like everybody has forgotten the previous discussion and not read the docs and deprecation patches where this is explained so I summarise the proposed change here again: - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the via option and when using it in qemu-system-ppc64 suggesting using new machines instead so these could evetually be removed next year. mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not deprecated and don't want to remove it. - qemu-system-ppc64 -M mac99 -> powermac7_3 - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 The last one is one of the rare Macs that had adb and pmu, all others with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but more similar to g3beige and no ADB ports according to https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware The PowerMac7,3 seems to be matching the PCI device listing in the comment at the beginning of mac_newworld.c and also this article: https://www.informit.com/articles/article.aspx?p=606582 What is the 2 USB devices problem? Is it the one we've debugged before and found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested enough to provide a patch. But this series does not remove the mac99 and does not even deprecate it. What it deprecates are the via option to select different machine types and the automatic detection of ppc64 to emulate something different which are hard to understand for users and caused several misunderstandings. It's much more clear to have a separate machine type for each machine we emulate even when they aren't yet complete but at least we know which way to go and can compare to real hardware and fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to remove qemu-system-ppc if we wanted and only have one executable for all machines but even without this it's clearer to have separate machnies for G5 and G4 macs than mac99 silently behaving differently. Regards, BALATON Zoltan
On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Thu, 12 Jan 2023, Howard Spoelstra wrote: > > On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> > wrote: > > > >> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >>> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>> > >>>> Setting emulated machine type with a property called "via" is > >>>> confusing users so deprecate the "via" option in favour of newly added > >>>> explicit machine types. The default via=cuda option is not a valid > >>>> config (no real Mac has this combination of hardware) so no machine > >>>> type could be defined for that therefore it is kept for backwards > >>>> compatibility with older QEMU versions for now but other options > >>>> resembling real machines are deprecated. > >>>> > >>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > >>> > >>> I believe that people do use -M mac99,via=cuda to run some rare > versions > >> of > >>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we > >> would > >>> want to keep this option somewhere. > >> > >> The idea is that after previous patches we now have machine types for > all > >> other via option values (that also match real Mac machines) other than > >> via=cude but that is the default for mac99 so after the reprecation > period > >> when the via option is removed mac99 (which is the same as > mac99,via=cuda) > >> can remain for this use case (and for backward compatibility) until the > >> other machines are fixed to not need this any more. So all via options > are > >> still available but as different machine types. > >> > > My 2 cents about naming: > > It seems less important how the machines are named when their name is not > > covering their definition. F.i. the powermac3,1 never had adb, could not > be > > equipped with a G3 cpu, did not run at 900Mhz. The closest possible > > qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac > > OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > > already needed. > > What does that mean? Should we aim to emulate real Macs or are we happy > with the Franken-Mac we have now? > The names also show what we intend to > emulate even though the emulation may not be complete or have bugs (this > is also true for other machines in QEMU where a lot of them are not fully > emulated, only well enough to boot guest OSes). > > Looks like everybody has forgotten the previous discussion and not read > the docs and deprecation patches where this is explained so I summarise > the proposed change here again: > > No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I personally do not oppose a name change, the new names seem more descriptive. I tested your patches and they behave as they should. The functionality does not change. However, my simple point was what's in a name when the underlying machine does not reflect what the name implies. It is not my place to comment on a possible development agenda. I can only tell you what I'd like and point out issues. > - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for the via option and when using it in qemu-system-ppc64 suggesting > using new machines instead so these could evetually be removed next year. > mac99,via=cuda is just mac99 so you can continue to use that, mac99 is > not deprecated and don't want to remove it. > > - qemu-system-ppc64 -M mac99 -> powermac7_3 > > - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > > - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > The last one is one of the rare Macs that had adb and pmu, all others with > pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 > hardware but more similar to g3beige and no ADB ports according to > https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > > The PowerMac7,3 seems to be matching the PCI device listing in the comment > at the beginning of mac_newworld.c and also this article: > https://www.informit.com/articles/article.aspx?p=606582 > > What is the 2 USB devices problem? Is it the one we've debugged before and > found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? > That could be fixed if there was somebody interested enough to provide a > patch. > It is not about passing through USB devices and active packets per endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting Mac OS 9.0.4 with via=pmu it will support only one (the kbd). When started with via=cuda -usb -device usb-kbd -device usb-mouse it will support the first-mentioned usb-kbd. When kbd and mouse arguments are reversed it supports the other device ;-) > > But this series does not remove the mac99 and does not even deprecate it. > What it deprecates are the via option to select different machine types > and the automatic detection of ppc64 to emulate something different which > are hard to understand for users and caused several misunderstandings. > It's much more clear to have a separate machine type for each machine we > emulate even when they aren't yet complete but at least we know which way > to go and can compare to real hardware and fix the missing parts later. > Also introducing powermac7_3 to split the ppc64 mac99 would allow to > remove qemu-system-ppc if we wanted and only have one executable for all > machines but even without this it's clearer to have separate machnies for > G5 and G4 macs than mac99 silently behaving differently. > > Regards, > BALATON Zoltan >
On Fri, 13 Jan 2023, Howard Spoelstra wrote: > On Fri, Jan 13, 2023 at 12:53 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: >> The names also show what we intend to >> emulate even though the emulation may not be complete or have bugs (this >> is also true for other machines in QEMU where a lot of them are not fully >> emulated, only well enough to boot guest OSes). >> > >> Looks like everybody has forgotten the previous discussion and not read >> the docs and deprecation patches where this is explained so I summarise >> the proposed change here again: >> > No, I haven't forgotten that discussion. FWIW (as I cannot contribute): I > personally do not oppose a name change, the new names seem more > descriptive. I tested your patches and they behave as they should. The > functionality does not change. However, my simple point was what's in a > name when the underlying machine does not reflect what the name implies. In case of powermac3_1 (currently mac99,via=pmu) it does resemble the PowerMac3,1 G4 AGP machine. It's also what the device tree says and the emulated hardware corresponds to that machine, apart from some missing pieces (like I2C) and known bugs in some (like USB) it aims to emulate that machine but it's currently hidden in the obscure via option of mac99 which ny default is some non-existent Mac like machine with cuda. It's much easier for users not having inside knowledge of QEMU to get a machine type which clearly says what it emulates. If we ever want to run firmware ROM from the real machine we also want to make sure we emulate a real machine. I've done some steps in that direction before and submitted RFC patches that could get to an OF prompt with some debugger tweaking and could eventually made to work but it needs Mark's screamer series to get finished and some rewrite of the macio emulation to add I2C cleanly so it's stalled currently but maybe one day we'll get there. For powermac7,3 it is what qemu-system-ppc64 -M mac99 currently aims to emulate evidenced by the comment at the beginning and that it adds U3 chipset instead of Uninorth but currently only Linux boots on this machine. It may need some more fixes to get other OSes running starting with the device tree. I think the way for that is to move device tree creation to QEMU similar to what other PPC machines do. I have plans for that but it's blocked by not being able to contribute to OpenBIOS as most of my patches are disliked by Mark but I'll keep trying. The powerboot3,2 is one hardware I could find info on having PMU and ADB and it's the same era as the PowerMac3,1 so has similar hardware but not sure why this combination is even there. What guest needs this that cannot run with either mac99 or powermac3,1? > It is not my place to comment on a possible development agenda. I can only > tell you what I'd like and point out issues. > >> - qemu-system-ppc -M mac99 is unchanged and works like before it just >> warns for the via option and when using it in qemu-system-ppc64 suggesting >> using new machines instead so these could evetually be removed next year. >> mac99,via=cuda is just mac99 so you can continue to use that, mac99 is >> not deprecated and don't want to remove it. >> >> - qemu-system-ppc64 -M mac99 -> powermac7_3 >> >> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 >> >> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 >> >> The last one is one of the rare Macs that had adb and pmu, all others with >> pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 >> hardware but more similar to g3beige and no ADB ports according to >> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite >> https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware >> >> The PowerMac7,3 seems to be matching the PCI device listing in the comment >> at the beginning of mac_newworld.c and also this article: >> https://www.informit.com/articles/article.aspx?p=606582 >> >> What is the 2 USB devices problem? Is it the one we've debugged before and >> found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? >> That could be fixed if there was somebody interested enough to provide a >> patch. >> > > It is not about passing through USB devices and active packets per > endpoint. The powermac3,1 has two 2 USB 1.1 ports. However, when booting > Mac OS 9.0.4 with via=pmu it will support only one (the kbd). When started > with via=cuda -usb -device usb-kbd -device usb-mouse it will support the > first-mentioned usb-kbd. When kbd and mouse arguments are reversed it > supports the other device ;-) Is this something that happens on real hardware as well or is it some bug in emulation somewhere? If the drivers on this OS keep active packets on different endpoints then it's the same issue we've discovered with USB pass through of audio devices that also need this feature. If it's something else it may be fixable but we need to understand first what causes the issue. Regards, BALATON Zoltan
On 12/01/2023 23:51, BALATON Zoltan wrote: > On Thu, 12 Jan 2023, Howard Spoelstra wrote: >> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: >> >>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: >>>> On 04/01/2023 21:59, BALATON Zoltan wrote: >>>> >>>>> Setting emulated machine type with a property called "via" is >>>>> confusing users so deprecate the "via" option in favour of newly added >>>>> explicit machine types. The default via=cuda option is not a valid >>>>> config (no real Mac has this combination of hardware) so no machine >>>>> type could be defined for that therefore it is kept for backwards >>>>> compatibility with older QEMU versions for now but other options >>>>> resembling real machines are deprecated. >>>>> >>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>> >>>> I believe that people do use -M mac99,via=cuda to run some rare versions >>> of >>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we >>> would >>>> want to keep this option somewhere. >>> >>> The idea is that after previous patches we now have machine types for all >>> other via option values (that also match real Mac machines) other than >>> via=cude but that is the default for mac99 so after the reprecation period >>> when the via option is removed mac99 (which is the same as mac99,via=cuda) >>> can remain for this use case (and for backward compatibility) until the >>> other machines are fixed to not need this any more. So all via options are >>> still available but as different machine types. >>> >> My 2 cents about naming: >> It seems less important how the machines are named when their name is not >> covering their definition. F.i. the powermac3,1 never had adb, could not be >> equipped with a G3 cpu, did not run at 900Mhz. The closest possible >> qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac >> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is >> already needed. > > What does that mean? Should we aim to emulate real Macs or are we happy with the > Franken-Mac we have now? The names also show what we intend to emulate even though > the emulation may not be complete or have bugs (this is also true for other machines > in QEMU where a lot of them are not fully emulated, only well enough to boot guest > OSes). > > Looks like everybody has forgotten the previous discussion and not read the docs and > deprecation patches where this is explained so I summarise the proposed change here > again: > > - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for the > via option and when using it in qemu-system-ppc64 suggesting using new machines > instead so these could evetually be removed next year. mac99,via=cuda is just mac99 > so you can continue to use that, mac99 is not deprecated and don't want to remove it. > > - qemu-system-ppc64 -M mac99 -> powermac7_3 > > - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > > - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > The last one is one of the rare Macs that had adb and pmu, all others with pmu > usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware but > more similar to g3beige and no ADB ports according to > https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > > The PowerMac7,3 seems to be matching the PCI device listing in the comment at the > beginning of mac_newworld.c and also this article: > https://www.informit.com/articles/article.aspx?p=606582 > > What is the 2 USB devices problem? Is it the one we've debugged before and found that > it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be fixed if > there was somebody interested enough to provide a patch. > > But this series does not remove the mac99 and does not even deprecate it. What it > deprecates are the via option to select different machine types and the automatic > detection of ppc64 to emulate something different which are hard to understand for > users and caused several misunderstandings. It's much more clear to have a separate > machine type for each machine we emulate even when they aren't yet complete but at > least we know which way to go and can compare to real hardware and fix the missing > parts later. Also introducing powermac7_3 to split the ppc64 mac99 would allow to > remove qemu-system-ppc if we wanted and only have one executable for all machines but > even without this it's clearer to have separate machnies for G5 and G4 macs than > mac99 silently behaving differently. Ultimately the issue you are trying to solve is this, which is that -M mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start is to create a new "g5niagara" machine type (including OpenBIOS) and make it a clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99. The reason for suggesting this is that the number of users of qemu-system-ppc64 -M mac99 will be much smaller than those using qemu-system-ppc, which means there will be a lot less breakage for users. In the meantime we don't need to make a final decision re: machine names, yet it still gives you the freedom to work on -M mac99 for 32-bit Macs and move it closer towards the G4 AGP model. ATB, Mark.
On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: > On 12/01/2023 23:51, BALATON Zoltan wrote: >> On Thu, 12 Jan 2023, Howard Spoelstra wrote: >>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: >>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: >>>>> On 04/01/2023 21:59, BALATON Zoltan wrote: >>>>>> Setting emulated machine type with a property called "via" is >>>>>> confusing users so deprecate the "via" option in favour of newly added >>>>>> explicit machine types. The default via=cuda option is not a valid >>>>>> config (no real Mac has this combination of hardware) so no machine >>>>>> type could be defined for that therefore it is kept for backwards >>>>>> compatibility with older QEMU versions for now but other options >>>>>> resembling real machines are deprecated. >>>>>> >>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>>> >>>>> I believe that people do use -M mac99,via=cuda to run some rare versions >>>> of >>>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we >>>> would >>>>> want to keep this option somewhere. >>>> >>>> The idea is that after previous patches we now have machine types for all >>>> other via option values (that also match real Mac machines) other than >>>> via=cude but that is the default for mac99 so after the reprecation >>>> period >>>> when the via option is removed mac99 (which is the same as >>>> mac99,via=cuda) >>>> can remain for this use case (and for backward compatibility) until the >>>> other machines are fixed to not need this any more. So all via options >>>> are >>>> still available but as different machine types. >>>> >>> My 2 cents about naming: >>> It seems less important how the machines are named when their name is not >>> covering their definition. F.i. the powermac3,1 never had adb, could not >>> be >>> equipped with a G3 cpu, did not run at 900Mhz. The closest possible >>> qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac >>> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is >>> already needed. >> >> What does that mean? Should we aim to emulate real Macs or are we happy >> with the Franken-Mac we have now? The names also show what we intend to >> emulate even though the emulation may not be complete or have bugs (this is >> also true for other machines in QEMU where a lot of them are not fully >> emulated, only well enough to boot guest OSes). >> >> Looks like everybody has forgotten the previous discussion and not read the >> docs and deprecation patches where this is explained so I summarise the >> proposed change here again: >> >> - qemu-system-ppc -M mac99 is unchanged and works like before it just warns >> for the via option and when using it in qemu-system-ppc64 suggesting using >> new machines instead so these could evetually be removed next year. >> mac99,via=cuda is just mac99 so you can continue to use that, mac99 is not >> deprecated and don't want to remove it. >> >> - qemu-system-ppc64 -M mac99 -> powermac7_3 >> >> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 >> >> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 >> >> The last one is one of the rare Macs that had adb and pmu, all others with >> pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 >> hardware but more similar to g3beige and no ADB ports according to >> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite >> https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware >> >> The PowerMac7,3 seems to be matching the PCI device listing in the comment >> at the beginning of mac_newworld.c and also this article: >> https://www.informit.com/articles/article.aspx?p=606582 >> >> What is the 2 USB devices problem? Is it the one we've debugged before and >> found that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? >> That could be fixed if there was somebody interested enough to provide a >> patch. >> >> But this series does not remove the mac99 and does not even deprecate it. >> What it deprecates are the via option to select different machine types and >> the automatic detection of ppc64 to emulate something different which are >> hard to understand for users and caused several misunderstandings. It's >> much more clear to have a separate machine type for each machine we emulate >> even when they aren't yet complete but at least we know which way to go and >> can compare to real hardware and fix the missing parts later. Also >> introducing powermac7_3 to split the ppc64 mac99 would allow to remove >> qemu-system-ppc if we wanted and only have one executable for all machines >> but even without this it's clearer to have separate machnies for G5 and G4 >> macs than mac99 silently behaving differently. > > Ultimately the issue you are trying to solve is this, which is that -M mac99 > is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way > to start is to create a new "g5niagara" machine type (including OpenBIOS) and > make it a clone of mac_newworld.c, and then issue a warning on > qemu-system-ppc64 for -M mac99. I don't get what you mean. Patch 4 introduces a new machine type called powermac7_3 (or g5niagara if you want) which is a clone of mac99 and then issues the warning to deprecate qemu-system-ppc64 -M mac99 in patch 5. Did you actually test these patches at all? > The reason for suggesting this is that the number of users of > qemu-system-ppc64 -M mac99 will be much smaller than those using > qemu-system-ppc, which means there will be a lot less breakage for users. In Except those who mean to use ppc mac99 but think that they should use qemu-system-ppc64 on 64 bit Windows which is probably the highest number of users currently. I've cc'd you on the last instance of this but can dig up some more from last year and look at the emaculation.com forum or ask Howard how many times that happens. So after these patches users can still use qemu-system-ppc -M mac99 as before without a warning but will get warned for qemu-system-ppc64 -M mac99 to use powernac7_3 instead. > the meantime we don't need to make a final decision re: machine names, yet it > still gives you the freedom to work on -M mac99 for 32-bit Macs and move it > closer towards the G4 AGP model. That's a different issue you're mixing in here. One issue is mac99 emulating different machines with ppc and pcc64, this is solved as above. Another issue is that ppc mac99 is not a real mac, to get the hardware to match the device tree OpenBIOS tells the guest it is you have to use mac99,via=pmu which no user can guess. I want to rename this to simply powermac3_1 and get rid of the via option eventually and make these separate machines which is much more clear to the user. The implementation remains the same, but we're free to change that later once the naming is resolved. So I think we should decide on naming now and start deprecating old names (which are ppc64 mac99 and macc99 with via option so we only leave mac99 as before and all other variants will become -machine options). What part of this is not clear to you. I feel like despite trying to explain it for the third time we're still not on the same page. Regards, BALATON Zoltan
On 22/01/2023 22:07, BALATON Zoltan wrote: > On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: >> On 12/01/2023 23:51, BALATON Zoltan wrote: >>> On Thu, 12 Jan 2023, Howard Spoelstra wrote: >>>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: >>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: >>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote: >>>>>>> Setting emulated machine type with a property called "via" is >>>>>>> confusing users so deprecate the "via" option in favour of newly added >>>>>>> explicit machine types. The default via=cuda option is not a valid >>>>>>> config (no real Mac has this combination of hardware) so no machine >>>>>>> type could be defined for that therefore it is kept for backwards >>>>>>> compatibility with older QEMU versions for now but other options >>>>>>> resembling real machines are deprecated. >>>>>>> >>>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> >>>>>> >>>>>> I believe that people do use -M mac99,via=cuda to run some rare versions >>>>> of >>>>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so we >>>>> would >>>>>> want to keep this option somewhere. >>>>> >>>>> The idea is that after previous patches we now have machine types for all >>>>> other via option values (that also match real Mac machines) other than >>>>> via=cude but that is the default for mac99 so after the reprecation period >>>>> when the via option is removed mac99 (which is the same as mac99,via=cuda) >>>>> can remain for this use case (and for backward compatibility) until the >>>>> other machines are fixed to not need this any more. So all via options are >>>>> still available but as different machine types. >>>>> >>>> My 2 cents about naming: >>>> It seems less important how the machines are named when their name is not >>>> covering their definition. F.i. the powermac3,1 never had adb, could not be >>>> equipped with a G3 cpu, did not run at 900Mhz. The closest possible >>>> qemu-options based definition of a powermac3,1 (via=pmu) will not run Mac >>>> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is >>>> already needed. >>> >>> What does that mean? Should we aim to emulate real Macs or are we happy with the >>> Franken-Mac we have now? The names also show what we intend to emulate even though >>> the emulation may not be complete or have bugs (this is also true for other >>> machines in QEMU where a lot of them are not fully emulated, only well enough to >>> boot guest OSes). >>> >>> Looks like everybody has forgotten the previous discussion and not read the docs >>> and deprecation patches where this is explained so I summarise the proposed change >>> here again: >>> >>> - qemu-system-ppc -M mac99 is unchanged and works like before it just warns for >>> the via option and when using it in qemu-system-ppc64 suggesting using new >>> machines instead so these could evetually be removed next year. mac99,via=cuda is >>> just mac99 so you can continue to use that, mac99 is not deprecated and don't want >>> to remove it. >>> >>> - qemu-system-ppc64 -M mac99 -> powermac7_3 >>> >>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 >>> >>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 FWIW this information would be useful in the cover letter once we decide the way forward. Also as a reviewer, it is hard to keep track of all the changes if the series are constantly changing and with no changelog on the cover letter, which is why it takes me a while to review them. >>> The last one is one of the rare Macs that had adb and pmu, all others with pmu >>> usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 hardware >>> but more similar to g3beige and no ADB ports according to >>> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite >>> https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware >>> >>> The PowerMac7,3 seems to be matching the PCI device listing in the comment at the >>> beginning of mac_newworld.c and also this article: >>> https://www.informit.com/articles/article.aspx?p=606582 >>> >>> What is the 2 USB devices problem? Is it the one we've debugged before and found >>> that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? That could be >>> fixed if there was somebody interested enough to provide a patch. >>> >>> But this series does not remove the mac99 and does not even deprecate it. What it >>> deprecates are the via option to select different machine types and the automatic >>> detection of ppc64 to emulate something different which are hard to understand for >>> users and caused several misunderstandings. It's much more clear to have a >>> separate machine type for each machine we emulate even when they aren't yet >>> complete but at least we know which way to go and can compare to real hardware and >>> fix the missing parts later. Also introducing powermac7_3 to split the ppc64 mac99 >>> would allow to remove qemu-system-ppc if we wanted and only have one executable >>> for all machines but even without this it's clearer to have separate machnies for >>> G5 and G4 macs than mac99 silently behaving differently. >> >> Ultimately the issue you are trying to solve is this, which is that -M mac99 is >> different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best way to start >> is to create a new "g5niagara" machine type (including OpenBIOS) and make it a >> clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 for -M mac99. > > I don't get what you mean. Patch 4 introduces a new machine type called powermac7_3 > (or g5niagara if you want) which is a clone of mac99 and then issues the warning to > deprecate qemu-system-ppc64 -M mac99 in patch 5. Did you actually test these patches > at all? More specifically, what I'm suggesting as well as creating a new machine name is that we clone mac_newworld.c into a separate file for the 64-bit Mac machine, declare it as compiled for PPC64 only, and put the deprecation there. By creating a separate file and separate machine type for OpenBIOS, it gives you the freedom to make changes to mac99 to move it towards a G4 AGP without having to worry about affecting any existing 64-bit users. >> The reason for suggesting this is that the number of users of qemu-system-ppc64 -M >> mac99 will be much smaller than those using qemu-system-ppc, which means there will >> be a lot less breakage for users. In > > Except those who mean to use ppc mac99 but think that they should use > qemu-system-ppc64 on 64 bit Windows which is probably the highest number of users > currently. I've cc'd you on the last instance of this but can dig up some more from > last year and look at the emaculation.com forum or ask Howard how many times that > happens. So after these patches users can still use qemu-system-ppc -M mac99 as > before without a warning but will get warned for qemu-system-ppc64 -M mac99 to use > powernac7_3 instead. We're saying the same thing here, no? >> the meantime we don't need to make a final decision re: machine names, yet it still >> gives you the freedom to work on -M mac99 for 32-bit Macs and move it closer >> towards the G4 AGP model. > > That's a different issue you're mixing in here. One issue is mac99 emulating > different machines with ppc and pcc64, this is solved as above. Another issue is that > ppc mac99 is not a real mac, to get the hardware to match the device tree OpenBIOS > tells the guest it is you have to use mac99,via=pmu which no user can guess. I want > to rename this to simply powermac3_1 and get rid of the via option eventually and > make these separate machines which is much more clear to the user. The implementation > remains the same, but we're free to change that later once the naming is resolved. So > I think we should decide on naming now and start deprecating old names (which are > ppc64 mac99 and macc99 with via option so we only leave mac99 as before and all other > variants will become -machine options). What part of this is not clear to you. I feel > like despite trying to explain it for the third time we're still not on the same page. The default was set to mac99,via=cuda since that was the original implementation and via=pmu broke booting some images (unfortunately I can't remember the detail right now). Ultimately my aim was to fix the remaining bugs and switch the mac99 default to via=pmu, but due to various changes in the past couple of years my available time to work on QEMU is considerably reduced. What I see you are effectively asking for is a new machine which is currently equivalent to -M mac99,via=pmu that you wish to diverge towards a real G4 AGP machine, right? ATB, Mark.
On Mon, Jan 23, 2023 at 11:06 PM Mark Cave-Ayland < mark.cave-ayland@ilande.co.uk> wrote: > On 22/01/2023 22:07, BALATON Zoltan wrote: > > > On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: > >> On 12/01/2023 23:51, BALATON Zoltan wrote: > >>> On Thu, 12 Jan 2023, Howard Spoelstra wrote: > >>>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> > wrote: > >>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: > >>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote: > >>>>>>> Setting emulated machine type with a property called "via" is > >>>>>>> confusing users so deprecate the "via" option in favour of newly > added > >>>>>>> explicit machine types. The default via=cuda option is not a valid > >>>>>>> config (no real Mac has this combination of hardware) so no machine > >>>>>>> type could be defined for that therefore it is kept for backwards > >>>>>>> compatibility with older QEMU versions for now but other options > >>>>>>> resembling real machines are deprecated. > >>>>>>> > >>>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > >>>>>> > >>>>>> I believe that people do use -M mac99,via=cuda to run some rare > versions > >>>>> of > >>>>>> MacOS in QEMU (I think possibly OS X DP and Workgroup Server?), so > we > >>>>> would > >>>>>> want to keep this option somewhere. > >>>>> > >>>>> The idea is that after previous patches we now have machine types > for all > >>>>> other via option values (that also match real Mac machines) other > than > >>>>> via=cude but that is the default for mac99 so after the reprecation > period > >>>>> when the via option is removed mac99 (which is the same as > mac99,via=cuda) > >>>>> can remain for this use case (and for backward compatibility) until > the > >>>>> other machines are fixed to not need this any more. So all via > options are > >>>>> still available but as different machine types. > >>>>> > >>>> My 2 cents about naming: > >>>> It seems less important how the machines are named when their name is > not > >>>> covering their definition. F.i. the powermac3,1 never had adb, could > not be > >>>> equipped with a G3 cpu, did not run at 900Mhz. The closest possible > >>>> qemu-options based definition of a powermac3,1 (via=pmu) will not run > Mac > >>>> OS 9.0.4 ;-) due to the 2 USB devices problem. To run that via=cuda is > >>>> already needed. > >>> > >>> What does that mean? Should we aim to emulate real Macs or are we > happy with the > >>> Franken-Mac we have now? The names also show what we intend to emulate > even though > >>> the emulation may not be complete or have bugs (this is also true for > other > >>> machines in QEMU where a lot of them are not fully emulated, only well > enough to > >>> boot guest OSes). > >>> > >>> Looks like everybody has forgotten the previous discussion and not > read the docs > >>> and deprecation patches where this is explained so I summarise the > proposed change > >>> here again: > >>> > >>> - qemu-system-ppc -M mac99 is unchanged and works like before it just > warns for > >>> the via option and when using it in qemu-system-ppc64 suggesting using > new > >>> machines instead so these could evetually be removed next year. > mac99,via=cuda is > >>> just mac99 so you can continue to use that, mac99 is not deprecated > and don't want > >>> to remove it. > >>> > >>> - qemu-system-ppc64 -M mac99 -> powermac7_3 > >>> > >>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 > >>> > >>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > FWIW this information would be useful in the cover letter once we decide > the way > forward. Also as a reviewer, it is hard to keep track of all the changes > if the > series are constantly changing and with no changelog on the cover letter, > which is > why it takes me a while to review them. > > >>> The last one is one of the rare Macs that had adb and pmu, all others > with pmu > >>> usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with mac99 > hardware > >>> but more similar to g3beige and no ADB ports according to > >>> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite > >>> > https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware > >>> > >>> The PowerMac7,3 seems to be matching the PCI device listing in the > comment at the > >>> beginning of mac_newworld.c and also this article: > >>> https://www.informit.com/articles/article.aspx?p=606582 > >>> > >>> What is the 2 USB devices problem? Is it the one we've debugged before > and found > >>> that it's noted in a comment marked with ??? in hw/usb/hcd-ohci.c? > That could be > >>> fixed if there was somebody interested enough to provide a patch. > >>> > >>> But this series does not remove the mac99 and does not even deprecate > it. What it > >>> deprecates are the via option to select different machine types and > the automatic > >>> detection of ppc64 to emulate something different which are hard to > understand for > >>> users and caused several misunderstandings. It's much more clear to > have a > >>> separate machine type for each machine we emulate even when they > aren't yet > >>> complete but at least we know which way to go and can compare to real > hardware and > >>> fix the missing parts later. Also introducing powermac7_3 to split the > ppc64 mac99 > >>> would allow to remove qemu-system-ppc if we wanted and only have one > executable > >>> for all machines but even without this it's clearer to have separate > machnies for > >>> G5 and G4 macs than mac99 silently behaving differently. > >> > >> Ultimately the issue you are trying to solve is this, which is that -M > mac99 is > >> different for qemu-system-ppc and qemu-system-ppc64. Perhaps the best > way to start > >> is to create a new "g5niagara" machine type (including OpenBIOS) and > make it a > >> clone of mac_newworld.c, and then issue a warning on qemu-system-ppc64 > for -M mac99. > > > > I don't get what you mean. Patch 4 introduces a new machine type called > powermac7_3 > > (or g5niagara if you want) which is a clone of mac99 and then issues the > warning to > > deprecate qemu-system-ppc64 -M mac99 in patch 5. Did you actually test > these patches > > at all? > > More specifically, what I'm suggesting as well as creating a new machine > name is that > we clone mac_newworld.c into a separate file for the 64-bit Mac machine, > declare it > as compiled for PPC64 only, and put the deprecation there. By creating a > separate > file and separate machine type for OpenBIOS, it gives you the freedom to > make changes > to mac99 to move it towards a G4 AGP without having to worry about > affecting any > existing 64-bit users. > > >> The reason for suggesting this is that the number of users of > qemu-system-ppc64 -M > >> mac99 will be much smaller than those using qemu-system-ppc, which > means there will > >> be a lot less breakage for users. In > > > > Except those who mean to use ppc mac99 but think that they should use > > qemu-system-ppc64 on 64 bit Windows which is probably the highest number > of users > > currently. I've cc'd you on the last instance of this but can dig up > some more from > > last year and look at the emaculation.com forum or ask Howard how many > times that > > happens. So after these patches users can still use qemu-system-ppc -M > mac99 as > > before without a warning but will get warned for qemu-system-ppc64 -M > mac99 to use > > powernac7_3 instead. > > We're saying the same thing here, no? > > >> the meantime we don't need to make a final decision re: machine names, > yet it still > >> gives you the freedom to work on -M mac99 for 32-bit Macs and move it > closer > >> towards the G4 AGP model. > > > > That's a different issue you're mixing in here. One issue is mac99 > emulating > > different machines with ppc and pcc64, this is solved as above. Another > issue is that > > ppc mac99 is not a real mac, to get the hardware to match the device > tree OpenBIOS > > tells the guest it is you have to use mac99,via=pmu which no user can > guess. I want > > to rename this to simply powermac3_1 and get rid of the via option > eventually and > > make these separate machines which is much more clear to the user. The > implementation > > remains the same, but we're free to change that later once the naming is > resolved. So > > I think we should decide on naming now and start deprecating old names > (which are > > ppc64 mac99 and macc99 with via option so we only leave mac99 as before > and all other > > variants will become -machine options). What part of this is not clear > to you. I feel > > like despite trying to explain it for the third time we're still not on > the same page. > > The default was set to mac99,via=cuda since that was the original > implementation and > via=pmu broke booting some images (unfortunately I can't remember the > detail right > now). Ultimately my aim was to fix the remaining bugs and switch the mac99 > default to > via=pmu, but due to various changes in the past couple of years my > available time to > work on QEMU is considerably reduced. > > From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due to the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be that these suffer the same usb issue) The real powermac3,1 AGP has no adb. via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only needed for Mac OS X 10.5 guest (for which the speed reported was hacked to 900Mhz to fool the installer), but should support all Mac OS/OS X that are now supported. via=pmu-adb seems only needed to trick mac os server installations that would later run on the g3beige. To my knowledge 32 bit Linux guests all require via=pmu See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC Best, Howard > What I see you are effectively asking for is a new machine which is > currently > equivalent to -M mac99,via=pmu that you wish to diverge towards a real G4 > AGP > machine, right? > > > ATB, > > Mark. >
On Mon, 23 Jan 2023, Mark Cave-Ayland wrote: > On 22/01/2023 22:07, BALATON Zoltan wrote: >> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote: >>> On 12/01/2023 23:51, BALATON Zoltan wrote: >>>> On Thu, 12 Jan 2023, Howard Spoelstra wrote: >>>>> On Wed, Jan 11, 2023 at 1:15 AM BALATON Zoltan <balaton@eik.bme.hu> >>>>> wrote: >>>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote: >>>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote: >>>> - qemu-system-ppc -M mac99 is unchanged and works like before it just >>>> warns for the via option and when using it in qemu-system-ppc64 >>>> suggesting using new machines instead so these could evetually be removed >>>> next year. mac99,via=cuda is just mac99 so you can continue to use that, >>>> mac99 is not deprecated and don't want to remove it. >>>> >>>> - qemu-system-ppc64 -M mac99 -> powermac7_3 >>>> >>>> - qemu-system-ppc -M mac99,via=pmu -> powermac3,1 >>>> >>>> - qemu-system-ppc64 -M mac99,via=pmu-adb -> powerbook3_2 > > FWIW this information would be useful in the cover letter once we decide the > way forward. Also as a reviewer, it is hard to keep track of all the changes > if the series are constantly changing and with no changelog on the cover > letter, which is why it takes me a while to review them. As a maintainer you could help reducing the size of the series and patches under review by queuing the patches that are already reviewed then hopefully there are only a few left to discuss. One reason for changing the series was to omit patches you've dismissed right away and move the ones reviewed or those you were less resistant about to the front so you could easily merge them and reduce the size of the remaining series that I'll have to roll and respin later. So queueing those you're already OK with could help making this clearer. >>>> The last one is one of the rare Macs that had adb and pmu, all others >>>> with pmu usually have USB. The PowerMac1,2 (G4 PCI) had CUDA but not with >>>> mac99 hardware but more similar to g3beige and no ADB ports according to >>>> https://en.wikipedia.org/wiki/Power_Mac_G4#1st_generation:_Graphite >>>> https://en.wikipedia.org/wiki/Power_Macintosh_G3_(Blue_and_White)#Hardware >>>> >>>> The PowerMac7,3 seems to be matching the PCI device listing in the >>>> comment at the beginning of mac_newworld.c and also this article: >>>> https://www.informit.com/articles/article.aspx?p=606582 >>>> >>>> What is the 2 USB devices problem? Is it the one we've debugged before >>>> and found that it's noted in a comment marked with ??? in >>>> hw/usb/hcd-ohci.c? That could be fixed if there was somebody interested >>>> enough to provide a patch. >>>> >>>> But this series does not remove the mac99 and does not even deprecate it. >>>> What it deprecates are the via option to select different machine types >>>> and the automatic detection of ppc64 to emulate something different which >>>> are hard to understand for users and caused several misunderstandings. >>>> It's much more clear to have a separate machine type for each machine we >>>> emulate even when they aren't yet complete but at least we know which way >>>> to go and can compare to real hardware and fix the missing parts later. >>>> Also introducing powermac7_3 to split the ppc64 mac99 would allow to >>>> remove qemu-system-ppc if we wanted and only have one executable for all >>>> machines but even without this it's clearer to have separate machnies for >>>> G5 and G4 macs than mac99 silently behaving differently. >>> >>> Ultimately the issue you are trying to solve is this, which is that -M >>> mac99 is different for qemu-system-ppc and qemu-system-ppc64. Perhaps the >>> best way to start is to create a new "g5niagara" machine type (including >>> OpenBIOS) and make it a clone of mac_newworld.c, and then issue a warning >>> on qemu-system-ppc64 for -M mac99. >> >> I don't get what you mean. Patch 4 introduces a new machine type called >> powermac7_3 (or g5niagara if you want) which is a clone of mac99 and then >> issues the warning to deprecate qemu-system-ppc64 -M mac99 in patch 5. Did >> you actually test these patches at all? > > More specifically, what I'm suggesting as well as creating a new machine name > is that we clone mac_newworld.c into a separate file for the 64-bit Mac > machine, declare it as compiled for PPC64 only, and put the deprecation > there. By creating a separate file and separate machine type for OpenBIOS, it > gives you the freedom to make changes to mac99 to move it towards a G4 AGP > without having to worry about affecting any existing 64-bit users. This would create a lot of duplicated code and increase the nunber of machines to maintain so I don't think this is a good idea at this point. I also don't want to change any of these machines now. The mac99.via=pmu is sufficiently close to PowerMac3,1 already. All I want is to have separate machine names for the machines we emulate. This is to 1. resolve the confusion this causes to usesrs 2. allow deprecating old ways of specifying these so we can eventually get rid of those 3. and this will also allow later to split the implementation if we need to or add new machines from scratch that will fit in the new naming So what you propose is not needed now and don't see why you think it would be needed just to resolve the names now. >>> The reason for suggesting this is that the number of users of >>> qemu-system-ppc64 -M mac99 will be much smaller than those using >>> qemu-system-ppc, which means there will be a lot less breakage for users. >>> In >> >> Except those who mean to use ppc mac99 but think that they should use >> qemu-system-ppc64 on 64 bit Windows which is probably the highest number of >> users currently. I've cc'd you on the last instance of this but can dig up >> some more from last year and look at the emaculation.com forum or ask >> Howard how many times that happens. So after these patches users can still >> use qemu-system-ppc -M mac99 as before without a warning but will get >> warned for qemu-system-ppc64 -M mac99 to use powernac7_3 instead. > > We're saying the same thing here, no? I don't know. If we were saying the same why are you not happy with the patch? I probably don't get what your concern is. To me it looks like you just resist any change without a clear reason and try to come up with excuses why not to merge these patches. My point was that this patch should not break any command lines for anybody, it will just issue warnings for the via option and ppc64 mac99 telling users to use new -machine options instead. They can keep using ppc mac99 without a warning and it can be either kept as it is for backwards compatibility or deprecated later once the other machines are better. If your concern was that it might break something for somebody then it's not likely as this does not change the machines' implementation just adds explicit names for those which are currently only accessible by options and defaults. Spliting the ppc and ppc64 mac99 as you say would increase the chance of it breaking in the future because you'll then need to make every change in two places and if you forget it's easier to break. So this patch leaves the implementation shared but adds separate names so they can be split as at a later point without addecting users but no need to do that change now. Just separating the name is enough and it has less chance to break anything. >>> the meantime we don't need to make a final decision re: machine names, yet >>> it still gives you the freedom to work on -M mac99 for 32-bit Macs and >>> move it closer towards the G4 AGP model. >> >> That's a different issue you're mixing in here. One issue is mac99 >> emulating different machines with ppc and pcc64, this is solved as above. >> Another issue is that ppc mac99 is not a real mac, to get the hardware to >> match the device tree OpenBIOS tells the guest it is you have to use >> mac99,via=pmu which no user can guess. I want to rename this to simply >> powermac3_1 and get rid of the via option eventually and make these >> separate machines which is much more clear to the user. The implementation >> remains the same, but we're free to change that later once the naming is >> resolved. So I think we should decide on naming now and start deprecating >> old names (which are ppc64 mac99 and macc99 with via option so we only >> leave mac99 as before and all other variants will become -machine options). >> What part of this is not clear to you. I feel like despite trying to >> explain it for the third time we're still not on the same page. > > The default was set to mac99,via=cuda since that was the original > implementation and via=pmu broke booting some images (unfortunately I can't > remember the detail right now). Ultimately my aim was to fix the remaining > bugs and switch the mac99 default to via=pmu, but due to various changes in > the past couple of years my available time to work on QEMU is considerably > reduced. > > What I see you are effectively asking for is a new machine which is currently > equivalent to -M mac99,via=pmu that you wish to diverge towards a real G4 AGP > machine, right? No I don't want it to diverge just to be available as a machine option instead of a cryptic option that nobody can find out without being told. If you now do qemu-system-ppc64 -machine help you'll see: $ qemu-system-ppc64 -machine help Supported machines are: 40p IBM RS/6000 7020 (40p) bamboo bamboo g3beige Heathrow based PowerMAC mac99 Mac99 based PowerMAC mpc8544ds mpc8544ds none empty machine pegasos2 Genesi/bPlan Pegasos II powernv10 IBM PowerNV (Non-Virtualized) POWER10 powernv8 IBM PowerNV (Non-Virtualized) POWER8 [...] How do you know how to emulate a G5 Mac and a G4 Mac? You don't without reading docs (which nobody does) or asking (which nobody does either). Instead they try mac99 and find it does not work and abandon it. After this patch you'll get: $ qemu-system-ppc64 -machine help Supported machines are: 40p IBM RS/6000 7020 (40p) bamboo bamboo g3beige Heathrow based PowerMAC mac99 Mac99 based PowerMAC mpc8544ds mpc8544ds none empty machine pegasos2 Genesi/bPlan Pegasos II powerbook3_2 Apple PowerBook G4 Titanium (Mercury) powermac3_1 Apple Power Mac G4 AGP (Sawtooth) powermac7_3 Apple Power Mac G5 (Niagara) powernv10 IBM PowerNV (Non-Virtualized) POWER10 powernv8 IBM PowerNV (Non-Virtualized) POWER8 and specifying the -machine option will give you the right machine right away. I really don't know what is so hard to get about this that I have to ecplain it all over again for 3 months now since I've first submitted these. Regards, BALATON Zoltan
On Tue, 24 Jan 2023, Howard Spoelstra wrote: > From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due to > the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be > that these suffer the same usb issue) > The real powermac3,1 AGP has no adb. And do these OSes run on real PowerMac3,1? If so then we likely have a bug in USB emulation so maybe that could be fixed? In any case my patch does not change mac99 and this should continue to work. > via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only > needed for Mac OS X 10.5 guest (for which the speed reported was hacked to > 900Mhz to fool the installer), but should support all Mac OS/OS X that are > now supported. Since via=pmu is what should be a real machine does it run OS X >=10.2 already? > via=pmu-adb seems only needed to trick mac os server installations that > would later run on the g3beige. > > To my knowledge 32 bit Linux guests all require via=pmu > See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC That doc might need some updating. It seems to be from before pegasos2 was added. Maybe we would be better off linking from this page to others that are more actively maintained such as: https://www.emaculation.com/doku.php/qemu and http://zero.eik.bme.hu/~balaton/qemu/amiga/ or even better updating the main docs in https://www.qemu.org/docs/master/system/ppc/powermac.html or somehow link these sources together. Regards, BALATON Zoltan
On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due > to > > the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be > > that these suffer the same usb issue) > > The real powermac3,1 AGP has no adb. > > And do these OSes run on real PowerMac3,1? If so then we likely have a bug > in USB emulation so maybe that could be fixed? In any case my patch does > not change mac99 and this should continue to work. > > > via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only > > needed for Mac OS X 10.5 guest (for which the speed reported was hacked > to > > 900Mhz to fool the installer), but should support all Mac OS/OS X that > are > > now supported. > > Since via=pmu is what should be a real machine does it run OS X >=10.2 > already? > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 qemu-system-ppc status: 8.6 will not boot from CD or HD. 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 usb device problem 9.1 and 9.2 with via=pmu 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with an usb problem) 10.2 with via=pmu (but has serious graphics speed problem, also with via=cuda) 10.3 and 10.4 with via=pmu 10.5 only with via=pmu (but needs the 900Mhz speed hack). *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. 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. 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? > > via=pmu-adb seems only needed to trick mac os server installations that > > would later run on the g3beige. > > > > To my knowledge 32 bit Linux guests all require via=pmu > > See here: https://wiki.qemu.org/Documentation/Platforms/PowerPC > > That doc might need some updating. It seems to be from before pegasos2 was > added. Maybe we would be better off linking from this page to others that > are more actively maintained such as: > https://www.emaculation.com/doku.php/qemu > and > http://zero.eik.bme.hu/~balaton/qemu/amiga/ > > I "maintain" that page with only general information. I can link to the specific sites you mention. > or even better updating the main docs in > > https://www.qemu.org/docs/master/system/ppc/powermac.html > > That would have to be taken up by someone else. Best, Howard
On Tue, 24 Jan 2023, Howard Spoelstra wrote: > On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu> wrote: >> On Tue, 24 Jan 2023, Howard Spoelstra wrote: >>> From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 due >> to >>> the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would be >>> that these suffer the same usb issue) >>> The real powermac3,1 AGP has no adb. >> >> And do these OSes run on real PowerMac3,1? If so then we likely have a bug >> in USB emulation so maybe that could be fixed? In any case my patch does >> not change mac99 and this should continue to work. >> >>> via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly only >>> needed for Mac OS X 10.5 guest (for which the speed reported was hacked >> to >>> 900Mhz to fool the installer), but should support all Mac OS/OS X that >> are >>> now supported. >> >> Since via=pmu is what should be a real machine does it run OS X >=10.2 >> already? >> > > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 > > qemu-system-ppc status: > 8.6 will not boot from CD or HD. > 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 > usb device problem > 9.1 and 9.2 with via=pmu > 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also with > an usb problem) > 10.2 with via=pmu (but has serious graphics speed problem, also with > via=cuda) > 10.3 and 10.4 with via=pmu > 10.5 only with via=pmu (but needs the 900Mhz speed hack). > > *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. 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. 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? (You talk about via=cude above but I think it should be via=pmu. Is that a typo?) 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? Other idea you could try is to boot 10.1 and 10.2 and compare the ioteg 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. >> or even better updating the main docs in >> >> https://www.qemu.org/docs/master/system/ppc/powermac.html >> > That would have to be taken up by someone else. That page is generated from this file in QEMU source: https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/ppc/powermac.rst you can submit a patch to that like I did: https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg00006.html Regards, BALATON Zoltan
On Tue, Jan 24, 2023 at 3:15 PM BALATON Zoltan <balaton@eik.bme.hu> wrote: > On Tue, 24 Jan 2023, Howard Spoelstra wrote: > > On Tue, Jan 24, 2023 at 2:49 AM BALATON Zoltan <balaton@eik.bme.hu> > wrote: > >> On Tue, 24 Jan 2023, Howard Spoelstra wrote: > >>> From a Mac OS guest perspective, via=cuda is needed for Mac OS 9.0.4 > due > >> to > >>> the 2 usb devices (mouse/kbd) issue. And for 10.0/10.1 (my guess would > be > >>> that these suffer the same usb issue) > >>> The real powermac3,1 AGP has no adb. > >> > >> And do these OSes run on real PowerMac3,1? If so then we likely have a > bug > >> in USB emulation so maybe that could be fixed? In any case my patch does > >> not change mac99 and this should continue to work. > >> > >>> via=cuda supports Mac OS 9.0.4 up to OS X 10.4. via=pmu is strictly > only > >>> needed for Mac OS X 10.5 guest (for which the speed reported was hacked > >> to > >>> 900Mhz to fool the installer), but should support all Mac OS/OS X that > >> are > >>> now supported. > >> > >> Since via=pmu is what should be a real machine does it run OS X >=10.2 > >> already? > >> > > > > A real powermac3,1 (G4 400Mhz/AGP) runs 8.6 up to10.4.11 > > > > qemu-system-ppc status: > > 8.6 will not boot from CD or HD. > > 9.0.4* with via=pmu only supports mouse, not kbd. Needs via=cuda due to 2 > > usb device problem > > 9.1 and 9.2 with via=pmu > > 10.0 and 10.1 with via=pmu: no mouse and kdb. Needs via=cuda. (so also > with > > an usb problem) > > 10.2 with via=pmu (but has serious graphics speed problem, also with > > via=cuda) > > 10.3 and 10.4 with via=pmu > > 10.5 only with via=pmu (but needs the 900Mhz speed hack). > > > > *9.0.4 will only run with Mac OS Rom version 5.2.1 and above. > > 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) > 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. > (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? 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. > 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 ;-) > >> or even better updating the main docs in > >> > >> https://www.qemu.org/docs/master/system/ppc/powermac.html > >> > > That would have to be taken up by someone else. > > That page is generated from this file in QEMU source: > > > https://gitlab.com/qemu-project/qemu/-/blob/master/docs/system/ppc/powermac.rst > > you can submit a patch to that like I did: > > https://lists.nongnu.org/archive/html/qemu-ppc/2023-01/msg00006.html > > Regards, > BALATON Zoltan >
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 ;-) You can set up tap or vmnet network, boot it with cuda, enable ssh then you can access it from there after booting usb config. (It may even work with user network somehow, I think there's an option to forward a port from the guest to host then you could access ssh that way without having to set up bridged networking but you'll need to find that option as I don't remember what it was but I think I've seen it somewhere. Maybe in qemu-system-ppc -help or some docs on QEMU networking somewhere.) Regards, BALATON Zoltan
On Thu, 12 Jan 2023, Howard Spoelstra wrote: > My 2 cents about naming: > It seems less important how the machines are named when their name is not > covering their definition. F.i. the powermac3,1 never had adb, could not be > equipped with a G3 cpu, did not run at 900Mhz. True it never had ADB and makes not much sense to run it with a G3 (although you probably could, just nobody wanted to; but the other way around, i.e. according to https://en.wikipedia.org/wiki/Power_Mac_G4 the first PCI only G4 PowerMac1,2 had a motherboard from a G3 Mac just with a G4 CPU). But the G4 AGP could have a 900 MHz or faster CPU via a CPU upgrade: https://lowendmac.com/newsrev/07/0330.html#b https://lowendmac.com/newsrev/mnr07/1029.html https://lowendmac.com/ppc/power-mac-g4-upgrade-guide.html These links are from this page: https://lowendmac.com/1999/power-mac-g4-sawtooth/ also may be of interest: https://lowendmac.com/1998/beige-power-mac-g3-1998/ https://lowendmac.com/1997/beige-power-mac-g3-1997/ Regards, BALATON Zoltan
> On Jan 4, 2023, at 2:59 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote: > > Setting emulated machine type with a property called "via" is > confusing users so deprecate the "via" option in favour of newly added > explicit machine types. The default via=cuda option is not a valid > config (no real Mac has this combination of hardware) so no machine > type could be defined for that therefore it is kept for backwards > compatibility with older QEMU versions for now but other options > resembling real machines are deprecated. > > Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> > --- > hw/ppc/mac_newworld.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c > index f07c37328b..adf185bd3a 100644 > --- a/hw/ppc/mac_newworld.c > +++ b/hw/ppc/mac_newworld.c > @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine) > if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) { > warn_report("mac99 with G5 CPU is deprecated, " > "use powermac7_3 instead"); > + } else { > + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) { > + warn_report("mac99,via=pmu is deprecated, " > + "use powermac3_1 instead"); so use ‘-m mac99,via=powermac3_1’ or ‘-m powermac3_1’ or ‘-m mac99,powerpmac3_1’ I have no clue which one I’m supposed to use. It would be better to tell the user which of these three possibilities they should really use. From the other patches in the series, I’m guessing it’s the middle one, but even after looking at the code, I’m unsure. > + } > + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) { > + warn_report("mac99,via=pmu-adb is deprecated, " > + "use powerbook3_2 instead"); Same basic comment here. I’m thinking adding '-m’ or ‘machine type’ before powerbook… in both of these would resolve it.. Warner > + } > } > } > /* allocate RAM */ > -- > 2.30.6 > >
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
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
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. Regards, BALATON Zoltan
On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@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 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. Best, Howard
On Thu, 26 Jan 2023, Howard Spoelstra wrote: > On Thu, Jan 26, 2023 at 9:57 PM BALATON Zoltan <balaton@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). Regards, BALATON Zoltan
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 <balaton@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: https://github.com/sebastianbiallas/pearpc/issues/4 but I don't know if any of this is relevant. Regards, BALATON Zoltan
On Fri, Jan 27, 2023 at 3:29 AM BALATON Zoltan <balaton@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 <balaton@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 >
Hi all,
I'm getting a error while compiling on macOS (Intel). It seems linker
detection is passed an unknown argument "--version", whereas "-v" works OK?
See log below.
Thanks for looking into this,
Howard
Build started at 2023-11-06T07:29:19.181487
Main binary: /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11
Build Options: -Db_pie=false -Ddocs=disabled -Dplugins=true '--native-file
config-meson.cross'
Python system: Darwin
The Meson build system
Version: 0.63.3
Source dir: /Users/hsp/src/qemu-ppc
Build dir: /Users/hsp/src/qemu-ppc/build
Build type: native build
Project name: qemu
Project version: 8.1.50
-----
Detecting compiler via: cc -m64 -mcx16 --version
compiler returned <Popen: returncode: 0 args: ['cc', '-m64', '-mcx16',
'--version']>
compiler stdout:
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
compiler stderr:
Running command: cc -m64 -mcx16 -E -dM -
-----
Detecting linker via: cc -m64 -mcx16 -Wl,--version
linker returned <Popen: returncode: 1 args: ['cc', '-m64', '-mcx16',
'-Wl,--version']>
linker stdout:
linker stderr:
ld: unknown options: --version
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
-----
Detecting Apple linker via: cc -m64 -mcx16 -Wl,-v
linker stdout:
linker stderr:
@(#)PROGRAM:ld PROJECT:dyld-1015.7
BUILD 18:48:43 Aug 22 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386
x86_64 x86_64h armv6m armv7k armv7m armv7em
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k
armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is
29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3)
Library search paths:
/usr/local/lib
Framework search paths:
ld: Undefined symbols:
_main, referenced from:
<initial-undefines>
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64
-mcx16 -Wl,--version`
stdout:
stderr: ld: unknown options: --version
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
Hello, On Mon, 6 Nov 2023, Howard Spoelstra wrote: > Hi all, > > I'm getting a error while compiling on macOS (Intel). It seems linker > detection is passed an unknown argument "--version", whereas "-v" works OK? > See log below. See also https://lists.nongnu.org/archive/html/qemu-devel/2023-10/msg10375.html and the tickets listed in there. It should work with meson 1.2.x according to Rene's ticket to Meson and you can install that from homebrew but it seems it's not picked up. Why is it using /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11 ? How many pythons do you8 have on macOS? What does which python tell you and does it work better when you add --python=/path/to/python/that/homebrew/meson/uses ? Regards, BALATON Zoltan > Thanks for looking into this, > Howard > > Build started at 2023-11-06T07:29:19.181487 > Main binary: /Users/hsp/src/qemu-ppc/build/pyvenv/bin/python3.11 > Build Options: -Db_pie=false -Ddocs=disabled -Dplugins=true '--native-file > config-meson.cross' > Python system: Darwin > The Meson build system > Version: 0.63.3 > Source dir: /Users/hsp/src/qemu-ppc > Build dir: /Users/hsp/src/qemu-ppc/build > Build type: native build > Project name: qemu > Project version: 8.1.50 > ----- > Detecting compiler via: cc -m64 -mcx16 --version > compiler returned <Popen: returncode: 0 args: ['cc', '-m64', '-mcx16', > '--version']> > compiler stdout: > Apple clang version 15.0.0 (clang-1500.0.40.1) > Target: x86_64-apple-darwin22.6.0 > Thread model: posix > InstalledDir: /Library/Developer/CommandLineTools/usr/bin > > compiler stderr: > > Running command: cc -m64 -mcx16 -E -dM - > ----- > Detecting linker via: cc -m64 -mcx16 -Wl,--version > linker returned <Popen: returncode: 1 args: ['cc', '-m64', '-mcx16', > '-Wl,--version']> > linker stdout: > > linker stderr: > ld: unknown options: --version > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > ----- > Detecting Apple linker via: cc -m64 -mcx16 -Wl,-v > linker stdout: > > linker stderr: > @(#)PROGRAM:ld PROJECT:dyld-1015.7 > BUILD 18:48:43 Aug 22 2023 > configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 > x86_64 x86_64h armv6m armv7k armv7m armv7em > will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k > armv7m armv7em > LTO support using: LLVM version 15.0.0 (static support for 29, runtime is > 29) > TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.3) > Library search paths: > /usr/local/lib > Framework search paths: > ld: Undefined symbols: > _main, referenced from: > <initial-undefines> > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > ../meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -m64 > -mcx16 -Wl,--version` > stdout: > stderr: ld: unknown options: --version > clang: error: linker command failed with exit code 1 (use -v to see > invocation) >
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c index f07c37328b..adf185bd3a 100644 --- a/hw/ppc/mac_newworld.c +++ b/hw/ppc/mac_newworld.c @@ -169,6 +169,15 @@ static void ppc_core99_init(MachineState *machine) if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) { warn_report("mac99 with G5 CPU is deprecated, " "use powermac7_3 instead"); + } else { + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU) { + warn_report("mac99,via=pmu is deprecated, " + "use powermac3_1 instead"); + } + if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) { + warn_report("mac99,via=pmu-adb is deprecated, " + "use powerbook3_2 instead"); + } } } /* allocate RAM */
Setting emulated machine type with a property called "via" is confusing users so deprecate the "via" option in favour of newly added explicit machine types. The default via=cuda option is not a valid config (no real Mac has this combination of hardware) so no machine type could be defined for that therefore it is kept for backwards compatibility with older QEMU versions for now but other options resembling real machines are deprecated. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> --- hw/ppc/mac_newworld.c | 9 +++++++++ 1 file changed, 9 insertions(+)