* [PATCH v7 0/7] Misc ppc/mac machines clean up
@ 2023-01-04 21:59 BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
` (7 more replies)
0 siblings, 8 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
This is the remainder of the series that were postponed to after the
freeze the last time I've tried to submit them with some new patches
I did meanwhile.
BALATON Zoltan (7):
input/adb: Only include header where needed
mac_{old,new}world: Use local variable instead of qdev_get_machine()
mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
mac_newworld: Add machine types for different mac99 configs
mac_newworld: Deprecate mac99 with G5 CPU
mac_newworld: Deprecate mac99 "via" option
mac_newworld: Document deprecation
docs/about/deprecated.rst | 7 ++
docs/system/ppc/powermac.rst | 12 ++--
hw/misc/macio/cuda.c | 2 -
hw/misc/macio/pmu.c | 3 -
hw/misc/mos6522.c | 1 -
hw/ppc/mac_newworld.c | 130 +++++++++++++++++++++++++++++++----
hw/ppc/mac_oldworld.c | 21 ++----
include/hw/misc/mac_via.h | 1 +
include/hw/misc/macio/cuda.h | 1 +
include/hw/misc/macio/pmu.h | 1 +
include/hw/misc/mos6522.h | 3 +-
11 files changed, 142 insertions(+), 40 deletions(-)
--
2.30.6
^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH v7 1/7] input/adb: Only include header where needed
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-05 13:45 ` Philippe Mathieu-Daudé
2023-01-10 22:12 ` Mark Cave-Ayland
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
` (6 subsequent siblings)
7 siblings, 2 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
The header hw/input/adb.h is included by some files that don't need
it. Clean it up and include only where necessary.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
hw/misc/macio/cuda.c | 2 --
hw/misc/macio/pmu.c | 3 ---
hw/misc/mos6522.c | 1 -
include/hw/misc/mac_via.h | 1 +
include/hw/misc/macio/cuda.h | 1 +
include/hw/misc/macio/pmu.h | 1 +
include/hw/misc/mos6522.h | 3 +--
7 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
index 853e88bfed..7208b90e12 100644
--- a/hw/misc/macio/cuda.c
+++ b/hw/misc/macio/cuda.c
@@ -27,8 +27,6 @@
#include "hw/irq.h"
#include "hw/qdev-properties.h"
#include "migration/vmstate.h"
-#include "hw/input/adb.h"
-#include "hw/misc/mos6522.h"
#include "hw/misc/macio/cuda.h"
#include "qapi/error.h"
#include "qemu/timer.h"
diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
index 97ef8c771b..8575bc1264 100644
--- a/hw/misc/macio/pmu.c
+++ b/hw/misc/macio/pmu.c
@@ -31,10 +31,7 @@
#include "qemu/osdep.h"
#include "hw/qdev-properties.h"
#include "migration/vmstate.h"
-#include "hw/input/adb.h"
#include "hw/irq.h"
-#include "hw/misc/mos6522.h"
-#include "hw/misc/macio/gpio.h"
#include "hw/misc/macio/pmu.h"
#include "qapi/error.h"
#include "qemu/timer.h"
diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
index 0ed631186c..d6ba47bde9 100644
--- a/hw/misc/mos6522.c
+++ b/hw/misc/mos6522.c
@@ -25,7 +25,6 @@
*/
#include "qemu/osdep.h"
-#include "hw/input/adb.h"
#include "hw/irq.h"
#include "hw/misc/mos6522.h"
#include "hw/qdev-properties.h"
diff --git a/include/hw/misc/mac_via.h b/include/hw/misc/mac_via.h
index 5fe7a7f592..422da43bf9 100644
--- a/include/hw/misc/mac_via.h
+++ b/include/hw/misc/mac_via.h
@@ -12,6 +12,7 @@
#include "exec/memory.h"
#include "hw/sysbus.h"
#include "hw/misc/mos6522.h"
+#include "hw/input/adb.h"
#include "qom/object.h"
diff --git a/include/hw/misc/macio/cuda.h b/include/hw/misc/macio/cuda.h
index a71deec968..8a6678c749 100644
--- a/include/hw/misc/macio/cuda.h
+++ b/include/hw/misc/macio/cuda.h
@@ -26,6 +26,7 @@
#ifndef CUDA_H
#define CUDA_H
+#include "hw/input/adb.h"
#include "hw/misc/mos6522.h"
#include "qom/object.h"
diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
index 00fcdd23f5..ba76afb52a 100644
--- a/include/hw/misc/macio/pmu.h
+++ b/include/hw/misc/macio/pmu.h
@@ -10,6 +10,7 @@
#ifndef PMU_H
#define PMU_H
+#include "hw/input/adb.h"
#include "hw/misc/mos6522.h"
#include "hw/misc/macio/gpio.h"
#include "qom/object.h"
diff --git a/include/hw/misc/mos6522.h b/include/hw/misc/mos6522.h
index 05872fffc9..fba45668ab 100644
--- a/include/hw/misc/mos6522.h
+++ b/include/hw/misc/mos6522.h
@@ -27,9 +27,8 @@
#ifndef MOS6522_H
#define MOS6522_H
-#include "exec/memory.h"
+#include "exec/hwaddr.h"
#include "hw/sysbus.h"
-#include "hw/input/adb.h"
#include "qom/object.h"
#define MOS6522_NUM_REGS 16
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine()
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-05 7:23 ` [PATCH v7 2/7] mac_{old, new}world: " Philippe Mathieu-Daudé
` (2 more replies)
2023-01-04 21:59 ` [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg BALATON Zoltan
` (5 subsequent siblings)
7 siblings, 3 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
We already have machine in a local variable so no need to use
qdev_get_machine(), also remove now unneded line break.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
hw/ppc/mac_newworld.c | 3 +--
hw/ppc/mac_oldworld.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 601ea518f8..460c14b5e3 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
fw_cfg = FW_CFG(dev);
qdev_prop_set_uint32(dev, "data_width", 1);
qdev_prop_set_bit(dev, "dma_enabled", false);
- object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
- OBJECT(fw_cfg));
+ object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
s = SYS_BUS_DEVICE(dev);
sysbus_realize_and_unref(s, &error_fatal);
sysbus_mmio_map(s, 0, CFG_ADDR);
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 558c639202..5a7b25a4a8 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
fw_cfg = FW_CFG(dev);
qdev_prop_set_uint32(dev, "data_width", 1);
qdev_prop_set_bit(dev, "dma_enabled", false);
- object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
- OBJECT(fw_cfg));
+ object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
s = SYS_BUS_DEVICE(dev);
sysbus_realize_and_unref(s, &error_fatal);
sysbus_mmio_map(s, 0, CFG_ADDR);
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-10 22:25 ` Mark Cave-Ayland
2023-01-04 21:59 ` [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs BALATON Zoltan
` (4 subsequent siblings)
7 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
ROM and add it to the device tree for MacOS. Pass the NDRV this way
instead of via fw_cfg. This solves the problem with OpenBIOS also
adding the NDRV to ati-vga which it does not work with. This does not
need any changes to OpenBIOS as this NDRV ROM handling is already
there but this patch also allows simplifying OpenBIOS later to remove
the fw_cfg ndrv handling from the vga FCode and also drop the
vga-ndrv? option which is not needed any more as users can disable the
ndrv with -device VGA,romfile="" (or override it with their own NDRV
or ROM). Once FCode support is implemented in OpenBIOS, the proper
FCode ROM can be set the same way so this paves the way to remove some
hacks.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
hw/ppc/mac_newworld.c | 18 ++++++------------
hw/ppc/mac_oldworld.c | 18 ++++++------------
2 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 460c14b5e3..60c9c27986 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
- /* MacOS NDRV VGA driver */
- filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
- if (filename) {
- gchar *ndrv_file;
- gsize ndrv_size;
-
- if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
- fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
- }
- g_free(filename);
- }
-
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
@@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const char *arg)
return 2;
}
+static GlobalProperty props[] = {
+ /* MacOS NDRV VGA driver */
+ { "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
static void core99_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
#endif
mc->default_ram_id = "ppc_core99.ram";
mc->ignore_boot_device_suffixes = true;
+ compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
fwc->get_dev_path = core99_fw_dev_path;
}
diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
index 5a7b25a4a8..6a1b1ad47a 100644
--- a/hw/ppc/mac_oldworld.c
+++ b/hw/ppc/mac_oldworld.c
@@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
- /* MacOS NDRV VGA driver */
- filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
- if (filename) {
- gchar *ndrv_file;
- gsize ndrv_size;
-
- if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
- fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
- }
- g_free(filename);
- }
-
qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
}
@@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const char *arg)
return 2;
}
+static GlobalProperty props[] = {
+ /* MacOS NDRV VGA driver */
+ { "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
static void heathrow_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
mc->default_display = "std";
mc->ignore_boot_device_suffixes = true;
mc->default_ram_id = "ppc_heathrow.ram";
+ compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
fwc->get_dev_path = heathrow_fw_dev_path;
}
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
` (2 preceding siblings ...)
2023-01-04 21:59 ` [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-10 22:46 ` Mark Cave-Ayland
2023-01-04 21:59 ` [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU BALATON Zoltan
` (3 subsequent siblings)
7 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
The mac99 machine emulates different machines depending on machine
properties or even if it is run as qemu-system-ppc64 or
qemu-system-ppc. This is very confusing for users and many hours were
lost trying to explain it or finding out why commands users came up
with are not working as expected. (E.g. Windows users might think
qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
then fail to boot a 32 bit OS with -M mac99 trying to follow an
example that had qemu-system-ppc.) To avoid such confusion, add
explicit machine types for the different configs which will work the
same with both qemu-system-ppc and qemu-system-ppc64 and also make the
command line clearer for new users.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 60c9c27986..3f5d1ec097 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
},
};
+static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+
+ core99_machine_class_init(oc, data);
+ mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
+ mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
+}
+
+static void powermac3_1_instance_init(Object *obj)
+{
+ Core99MachineState *cms = CORE99_MACHINE(obj);
+
+ cms->via_config = CORE99_VIA_CONFIG_PMU;
+ return;
+}
+
+static const TypeInfo powermac3_1_machine_info = {
+ .name = MACHINE_TYPE_NAME("powermac3_1"),
+ .parent = TYPE_MACHINE,
+ .class_init = powermac3_1_machine_class_init,
+ .instance_init = powermac3_1_instance_init,
+ .instance_size = sizeof(Core99MachineState),
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_FW_PATH_PROVIDER },
+ { }
+ },
+};
+
+static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+
+ core99_machine_class_init(oc, data);
+ mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
+ mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
+}
+
+static void powerbook3_2_instance_init(Object *obj)
+{
+ Core99MachineState *cms = CORE99_MACHINE(obj);
+
+ cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
+ return;
+}
+
+static const TypeInfo powerbook3_2_machine_info = {
+ .name = MACHINE_TYPE_NAME("powerbook3_2"),
+ .parent = TYPE_MACHINE,
+ .class_init = powerbook3_2_machine_class_init,
+ .instance_init = powerbook3_2_instance_init,
+ .instance_size = sizeof(Core99MachineState),
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_FW_PATH_PROVIDER },
+ { }
+ },
+};
+
+#ifdef TARGET_PPC64
+static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
+{
+ MachineClass *mc = MACHINE_CLASS(oc);
+
+ core99_machine_class_init(oc, data);
+ mc->desc = "Apple Power Mac G5 (Niagara)";
+ mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
+}
+
+static void powermac7_3_instance_init(Object *obj)
+{
+ Core99MachineState *cms = CORE99_MACHINE(obj);
+
+ cms->via_config = CORE99_VIA_CONFIG_PMU;
+ return;
+}
+
+static const TypeInfo powermac7_3_machine_info = {
+ .name = MACHINE_TYPE_NAME("powermac7_3"),
+ .parent = TYPE_MACHINE,
+ .class_init = powermac7_3_machine_class_init,
+ .instance_init = powermac7_3_instance_init,
+ .instance_size = sizeof(Core99MachineState),
+ .interfaces = (InterfaceInfo[]) {
+ { TYPE_FW_PATH_PROVIDER },
+ { }
+ },
+};
+#endif
+
static void mac_machine_register_types(void)
{
type_register_static(&core99_machine_info);
+ type_register_static(&powermac3_1_machine_info);
+ type_register_static(&powerbook3_2_machine_info);
+#ifdef TARGET_PPC64
+ type_register_static(&powermac7_3_machine_info);
+#endif
}
type_init(mac_machine_register_types)
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
` (3 preceding siblings ...)
2023-01-04 21:59 ` [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-05 7:28 ` Philippe Mathieu-Daudé
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
` (2 subsequent siblings)
7 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
Besides resolving the confusing behaviour mentioned in previous commit
this might also allow unifying qemu-system-ppc and qemu-system-ppc64
in the future.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
hw/ppc/mac_newworld.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index 3f5d1ec097..f07c37328b 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
qemu_register_reset(ppc_core99_reset, cpu);
}
+ if (object_property_find(OBJECT(machine), "via")) {
+ if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
+ warn_report("mac99 with G5 CPU is deprecated, "
+ "use powermac7_3 instead");
+ }
+ }
/* allocate RAM */
if (machine->ram_size > 2 * GiB) {
error_report("RAM size more than 2 GiB is not supported");
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
` (4 preceding siblings ...)
2023-01-04 21:59 ` [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-05 14:28 ` Philippe Mathieu-Daudé
` (2 more replies)
2023-01-04 21:59 ` [PATCH v7 7/7] mac_newworld: Document deprecation BALATON Zoltan
2023-02-01 23:31 ` [PATCH v7 0/7] Misc ppc/mac machines clean up Mark Cave-Ayland
7 siblings, 3 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
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");
+ }
+ if (core99_machine->via_config == CORE99_VIA_CONFIG_PMU_ADB) {
+ warn_report("mac99,via=pmu-adb is deprecated, "
+ "use powerbook3_2 instead");
+ }
}
}
/* allocate RAM */
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH v7 7/7] mac_newworld: Document deprecation
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
` (5 preceding siblings ...)
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
@ 2023-01-04 21:59 ` BALATON Zoltan
2023-01-05 7:31 ` Philippe Mathieu-Daudé
2023-02-01 23:31 ` [PATCH v7 0/7] Misc ppc/mac machines clean up Mark Cave-Ayland
7 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-04 21:59 UTC (permalink / raw)
To: qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
Also update PowerMac family docs with some more recent info.
Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
---
docs/about/deprecated.rst | 7 +++++++
docs/system/ppc/powermac.rst | 12 ++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index 93affe3669..07661af7fe 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays and thus might have
various pitfalls with regards to live migration. Use a newer machine type
instead.
+``mac99`` variants other than the default qemu-system-ppc version (since 7.2)
+'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
+
+The ``mac99`` machine emulates different hardware depending on using
+qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
+types has been added for these variants which are now preferred over
+``mac99``.
Backend options
---------------
diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
index 04334ba210..d4a47a6881 100644
--- a/docs/system/ppc/powermac.rst
+++ b/docs/system/ppc/powermac.rst
@@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
PowerPC system.
-- ``g3beige`` Heathrow based PowerMAC
-- ``mac99`` Mac99 based PowerMAC
+- ``g3beige`` Heathrow based old world Power Macintosh G3
+- ``mac99`` Core99 based generic PowerMac
+- ``powermac3_1`` Power Mac G4 AGP (Sawtooth)
+- ``powerbook3_2`` PowerBook G4 Titanium (Mercury)
+- ``powermac7_3`` Power Mac G5 (Niagara) (only in ``qemu-system-ppc64``)
+
Supported devices
-----------------
@@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
* UniNorth or Grackle PCI Bridge
* PCI VGA compatible card with VESA Bochs Extensions
* 2 PMAC IDE interfaces with hard disk and CD-ROM support
- * NE2000 PCI adapters
+ * Sungem PCI network adapter
* Non Volatile RAM
- * VIA-CUDA with ADB keyboard and mouse.
+ * VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
Missing devices
--
2.30.6
^ permalink raw reply related [flat|nested] 64+ messages in thread
* Re: [PATCH v7 2/7] mac_{old, new}world: Use local variable instead of qdev_get_machine()
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
@ 2023-01-05 7:23 ` Philippe Mathieu-Daudé
2023-01-05 17:15 ` [PATCH v7 2/7] mac_{old,new}world: " Bernhard Beschow
2023-01-10 22:13 ` [PATCH v7 2/7] mac_{old, new}world: " Mark Cave-Ayland
2 siblings, 0 replies; 64+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-01-05 7:23 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
On 4/1/23 22:59, BALATON Zoltan wrote:
> We already have machine in a local variable so no need to use
> qdev_get_machine(), also remove now unneded line break.
Typo "unneeded".
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc/mac_oldworld.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU
2023-01-04 21:59 ` [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU BALATON Zoltan
@ 2023-01-05 7:28 ` Philippe Mathieu-Daudé
2023-01-05 11:58 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-01-05 7:28 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
On 4/1/23 22:59, BALATON Zoltan wrote:
> Besides resolving the confusing behaviour mentioned in previous commit
> this might also allow unifying qemu-system-ppc and qemu-system-ppc64
> in the future.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/ppc/mac_newworld.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 3f5d1ec097..f07c37328b 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
> qemu_register_reset(ppc_core99_reset, cpu);
> }
>
> + if (object_property_find(OBJECT(machine), "via")) {
> + if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
> + warn_report("mac99 with G5 CPU is deprecated, "
> + "use powermac7_3 instead");
"mac99 machine with G5 CPU is deprecated, prefer the powermac7_3 machine
instead"?
> + }
> + }
> /* allocate RAM */
> if (machine->ram_size > 2 * GiB) {
> error_report("RAM size more than 2 GiB is not supported");
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 7/7] mac_newworld: Document deprecation
2023-01-04 21:59 ` [PATCH v7 7/7] mac_newworld: Document deprecation BALATON Zoltan
@ 2023-01-05 7:31 ` Philippe Mathieu-Daudé
2023-01-05 12:02 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-01-05 7:31 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
On 4/1/23 22:59, BALATON Zoltan wrote:
> Also update PowerMac family docs with some more recent info.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> docs/about/deprecated.rst | 7 +++++++
> docs/system/ppc/powermac.rst | 12 ++++++++----
> 2 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 93affe3669..07661af7fe 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays and thus might have
> various pitfalls with regards to live migration. Use a newer machine type
> instead.
>
> +``mac99`` variants other than the default qemu-system-ppc version (since 7.2)
> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> +
> +The ``mac99`` machine emulates different hardware depending on using
> +qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
> +types has been added for these variants which are now preferred over
> +``mac99``.
^ this part is OK,
but below is part of patch 4/7 "Add different mac99 machine types".
> diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
> index 04334ba210..d4a47a6881 100644
> --- a/docs/system/ppc/powermac.rst
> +++ b/docs/system/ppc/powermac.rst
> @@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
> Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
> PowerPC system.
>
> -- ``g3beige`` Heathrow based PowerMAC
> -- ``mac99`` Mac99 based PowerMAC
> +- ``g3beige`` Heathrow based old world Power Macintosh G3
> +- ``mac99`` Core99 based generic PowerMac
> +- ``powermac3_1`` Power Mac G4 AGP (Sawtooth)
> +- ``powerbook3_2`` PowerBook G4 Titanium (Mercury)
> +- ``powermac7_3`` Power Mac G5 (Niagara) (only in ``qemu-system-ppc64``)
> +
>
> Supported devices
> -----------------
> @@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
> * UniNorth or Grackle PCI Bridge
> * PCI VGA compatible card with VESA Bochs Extensions
> * 2 PMAC IDE interfaces with hard disk and CD-ROM support
> - * NE2000 PCI adapters
> + * Sungem PCI network adapter
> * Non Volatile RAM
> - * VIA-CUDA with ADB keyboard and mouse.
> + * VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
>
>
> Missing devices
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU
2023-01-05 7:28 ` Philippe Mathieu-Daudé
@ 2023-01-05 11:58 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-05 11:58 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: qemu-devel, qemu-ppc, Mark Cave-Ayland
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote:
> On 4/1/23 22:59, BALATON Zoltan wrote:
>> Besides resolving the confusing behaviour mentioned in previous commit
>> this might also allow unifying qemu-system-ppc and qemu-system-ppc64
>> in the future.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>> hw/ppc/mac_newworld.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 3f5d1ec097..f07c37328b 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -165,6 +165,12 @@ static void ppc_core99_init(MachineState *machine)
>> qemu_register_reset(ppc_core99_reset, cpu);
>> }
>> + if (object_property_find(OBJECT(machine), "via")) {
>> + if (PPC_INPUT(env) == PPC_FLAGS_INPUT_970) {
>> + warn_report("mac99 with G5 CPU is deprecated, "
>> + "use powermac7_3 instead");
>
> "mac99 machine with G5 CPU is deprecated, prefer the powermac7_3 machine
> instead"?
I don't mind what the text is but this seems unnecessarily long where my
version conveys the message in a more concise way. But if others prefer
something else I'm OK to change it as you like. I expect these last
patches may need to be repartitioned so I'm waiting for review to see
what's preferred.
Regards,
BALATON Zoltan
>> + }
>> + }
>> /* allocate RAM */
>> if (machine->ram_size > 2 * GiB) {
>> error_report("RAM size more than 2 GiB is not supported");
>
>
>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 7/7] mac_newworld: Document deprecation
2023-01-05 7:31 ` Philippe Mathieu-Daudé
@ 2023-01-05 12:02 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-05 12:02 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: qemu-devel, qemu-ppc, Mark Cave-Ayland
[-- Attachment #1: Type: text/plain, Size: 3080 bytes --]
On Thu, 5 Jan 2023, Philippe Mathieu-Daudé wrote:
> On 4/1/23 22:59, BALATON Zoltan wrote:
>> Also update PowerMac family docs with some more recent info.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>> docs/about/deprecated.rst | 7 +++++++
>> docs/system/ppc/powermac.rst | 12 ++++++++----
>> 2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
>> index 93affe3669..07661af7fe 100644
>> --- a/docs/about/deprecated.rst
>> +++ b/docs/about/deprecated.rst
>> @@ -248,6 +248,13 @@ These old machine types are quite neglected nowadays
>> and thus might have
>> various pitfalls with regards to live migration. Use a newer machine type
>> instead.
>> +``mac99`` variants other than the default qemu-system-ppc version (since
>> 7.2)
>> +'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>> +
>> +The ``mac99`` machine emulates different hardware depending on using
>> +qemu-system-ppc64 or ``via`` property. To avoid confusion new machine
>> +types has been added for these variants which are now preferred over
>> +``mac99``.
>
> ^ this part is OK,
>
> but below is part of patch 4/7 "Add different mac99 machine types".
Not really, as that patch does not add these. It's already the current
state which this patch just documents so this is just updating docs. If
anything then the above part about deprecating mac99 may be squashed with
patch 5 and 6 to make a single deprecation patch but I'll see what the
maintainer prefers because whatever I come up with is usually not what he
likes so to avoid wasted effort I'd rather wait for clear instructions
before making more changes.
Regards,
BALATON Zoltan
>> diff --git a/docs/system/ppc/powermac.rst b/docs/system/ppc/powermac.rst
>> index 04334ba210..d4a47a6881 100644
>> --- a/docs/system/ppc/powermac.rst
>> +++ b/docs/system/ppc/powermac.rst
>> @@ -4,8 +4,12 @@ PowerMac family boards (``g3beige``, ``mac99``)
>> Use the executable ``qemu-system-ppc`` to simulate a complete PowerMac
>> PowerPC system.
>> -- ``g3beige`` Heathrow based PowerMAC
>> -- ``mac99`` Mac99 based PowerMAC
>> +- ``g3beige`` Heathrow based old world Power Macintosh G3
>> +- ``mac99`` Core99 based generic PowerMac
>> +- ``powermac3_1`` Power Mac G4 AGP (Sawtooth)
>> +- ``powerbook3_2`` PowerBook G4 Titanium (Mercury)
>> +- ``powermac7_3`` Power Mac G5 (Niagara) (only in
>> ``qemu-system-ppc64``)
>> +
>> Supported devices
>> -----------------
>> @@ -15,9 +19,9 @@ QEMU emulates the following PowerMac peripherals:
>> * UniNorth or Grackle PCI Bridge
>> * PCI VGA compatible card with VESA Bochs Extensions
>> * 2 PMAC IDE interfaces with hard disk and CD-ROM support
>> - * NE2000 PCI adapters
>> + * Sungem PCI network adapter
>> * Non Volatile RAM
>> - * VIA-CUDA with ADB keyboard and mouse.
>> + * VIA-CUDA or VIA-PMU99 with or without ADB or USB keyboard and mouse.
>> Missing devices
>
>
>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 1/7] input/adb: Only include header where needed
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
@ 2023-01-05 13:45 ` Philippe Mathieu-Daudé
2023-01-10 22:12 ` Mark Cave-Ayland
1 sibling, 0 replies; 64+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-01-05 13:45 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
On 4/1/23 22:59, BALATON Zoltan wrote:
> The header hw/input/adb.h is included by some files that don't need
> it. Clean it up and include only where necessary.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/misc/macio/cuda.c | 2 --
> hw/misc/macio/pmu.c | 3 ---
> hw/misc/mos6522.c | 1 -
> include/hw/misc/mac_via.h | 1 +
> include/hw/misc/macio/cuda.h | 1 +
> include/hw/misc/macio/pmu.h | 1 +
> include/hw/misc/mos6522.h | 3 +--
> 7 files changed, 4 insertions(+), 8 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
@ 2023-01-05 14:28 ` Philippe Mathieu-Daudé
2023-01-05 16:06 ` BALATON Zoltan
2023-01-10 22:52 ` Mark Cave-Ayland
2023-01-24 21:05 ` Warner Losh
2 siblings, 1 reply; 64+ messages in thread
From: Philippe Mathieu-Daudé @ 2023-01-05 14:28 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc; +Cc: Mark Cave-Ayland
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)
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-05 14:28 ` Philippe Mathieu-Daudé
@ 2023-01-05 16:06 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-05 16:06 UTC (permalink / raw)
To: Philippe Mathieu-Daudé; +Cc: qemu-devel, qemu-ppc, Mark Cave-Ayland
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine()
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
2023-01-05 7:23 ` [PATCH v7 2/7] mac_{old, new}world: " Philippe Mathieu-Daudé
@ 2023-01-05 17:15 ` Bernhard Beschow
2023-01-10 22:13 ` [PATCH v7 2/7] mac_{old, new}world: " Mark Cave-Ayland
2 siblings, 0 replies; 64+ messages in thread
From: Bernhard Beschow @ 2023-01-05 17:15 UTC (permalink / raw)
To: qemu-devel, BALATON Zoltan, qemu-ppc; +Cc: Mark Cave-Ayland
Am 4. Januar 2023 21:59:37 UTC schrieb BALATON Zoltan <balaton@eik.bme.hu>:
>We already have machine in a local variable so no need to use
>qdev_get_machine(), also remove now unneded line break.
>
>Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc/mac_oldworld.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
>diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>index 601ea518f8..460c14b5e3 100644
>--- a/hw/ppc/mac_newworld.c
>+++ b/hw/ppc/mac_newworld.c
>@@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
> fw_cfg = FW_CFG(dev);
> qdev_prop_set_uint32(dev, "data_width", 1);
> qdev_prop_set_bit(dev, "dma_enabled", false);
>- object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
>- OBJECT(fw_cfg));
>+ object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
> s = SYS_BUS_DEVICE(dev);
> sysbus_realize_and_unref(s, &error_fatal);
> sysbus_mmio_map(s, 0, CFG_ADDR);
>diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>index 558c639202..5a7b25a4a8 100644
>--- a/hw/ppc/mac_oldworld.c
>+++ b/hw/ppc/mac_oldworld.c
>@@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
> fw_cfg = FW_CFG(dev);
> qdev_prop_set_uint32(dev, "data_width", 1);
> qdev_prop_set_bit(dev, "dma_enabled", false);
>- object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
>- OBJECT(fw_cfg));
>+ object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
> s = SYS_BUS_DEVICE(dev);
> sysbus_realize_and_unref(s, &error_fatal);
> sysbus_mmio_map(s, 0, CFG_ADDR);
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 1/7] input/adb: Only include header where needed
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
2023-01-05 13:45 ` Philippe Mathieu-Daudé
@ 2023-01-10 22:12 ` Mark Cave-Ayland
1 sibling, 0 replies; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-10 22:12 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
On 04/01/2023 21:59, BALATON Zoltan wrote:
> The header hw/input/adb.h is included by some files that don't need
> it. Clean it up and include only where necessary.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/misc/macio/cuda.c | 2 --
> hw/misc/macio/pmu.c | 3 ---
> hw/misc/mos6522.c | 1 -
> include/hw/misc/mac_via.h | 1 +
> include/hw/misc/macio/cuda.h | 1 +
> include/hw/misc/macio/pmu.h | 1 +
> include/hw/misc/mos6522.h | 3 +--
> 7 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/hw/misc/macio/cuda.c b/hw/misc/macio/cuda.c
> index 853e88bfed..7208b90e12 100644
> --- a/hw/misc/macio/cuda.c
> +++ b/hw/misc/macio/cuda.c
> @@ -27,8 +27,6 @@
> #include "hw/irq.h"
> #include "hw/qdev-properties.h"
> #include "migration/vmstate.h"
> -#include "hw/input/adb.h"
> -#include "hw/misc/mos6522.h"
> #include "hw/misc/macio/cuda.h"
> #include "qapi/error.h"
> #include "qemu/timer.h"
> diff --git a/hw/misc/macio/pmu.c b/hw/misc/macio/pmu.c
> index 97ef8c771b..8575bc1264 100644
> --- a/hw/misc/macio/pmu.c
> +++ b/hw/misc/macio/pmu.c
> @@ -31,10 +31,7 @@
> #include "qemu/osdep.h"
> #include "hw/qdev-properties.h"
> #include "migration/vmstate.h"
> -#include "hw/input/adb.h"
> #include "hw/irq.h"
> -#include "hw/misc/mos6522.h"
> -#include "hw/misc/macio/gpio.h"
> #include "hw/misc/macio/pmu.h"
> #include "qapi/error.h"
> #include "qemu/timer.h"
> diff --git a/hw/misc/mos6522.c b/hw/misc/mos6522.c
> index 0ed631186c..d6ba47bde9 100644
> --- a/hw/misc/mos6522.c
> +++ b/hw/misc/mos6522.c
> @@ -25,7 +25,6 @@
> */
>
> #include "qemu/osdep.h"
> -#include "hw/input/adb.h"
> #include "hw/irq.h"
> #include "hw/misc/mos6522.h"
> #include "hw/qdev-properties.h"
> diff --git a/include/hw/misc/mac_via.h b/include/hw/misc/mac_via.h
> index 5fe7a7f592..422da43bf9 100644
> --- a/include/hw/misc/mac_via.h
> +++ b/include/hw/misc/mac_via.h
> @@ -12,6 +12,7 @@
> #include "exec/memory.h"
> #include "hw/sysbus.h"
> #include "hw/misc/mos6522.h"
> +#include "hw/input/adb.h"
> #include "qom/object.h"
>
>
> diff --git a/include/hw/misc/macio/cuda.h b/include/hw/misc/macio/cuda.h
> index a71deec968..8a6678c749 100644
> --- a/include/hw/misc/macio/cuda.h
> +++ b/include/hw/misc/macio/cuda.h
> @@ -26,6 +26,7 @@
> #ifndef CUDA_H
> #define CUDA_H
>
> +#include "hw/input/adb.h"
> #include "hw/misc/mos6522.h"
> #include "qom/object.h"
>
> diff --git a/include/hw/misc/macio/pmu.h b/include/hw/misc/macio/pmu.h
> index 00fcdd23f5..ba76afb52a 100644
> --- a/include/hw/misc/macio/pmu.h
> +++ b/include/hw/misc/macio/pmu.h
> @@ -10,6 +10,7 @@
> #ifndef PMU_H
> #define PMU_H
>
> +#include "hw/input/adb.h"
> #include "hw/misc/mos6522.h"
> #include "hw/misc/macio/gpio.h"
> #include "qom/object.h"
> diff --git a/include/hw/misc/mos6522.h b/include/hw/misc/mos6522.h
> index 05872fffc9..fba45668ab 100644
> --- a/include/hw/misc/mos6522.h
> +++ b/include/hw/misc/mos6522.h
> @@ -27,9 +27,8 @@
> #ifndef MOS6522_H
> #define MOS6522_H
>
> -#include "exec/memory.h"
> +#include "exec/hwaddr.h"
> #include "hw/sysbus.h"
> -#include "hw/input/adb.h"
> #include "qom/object.h"
>
> #define MOS6522_NUM_REGS 16
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 2/7] mac_{old, new}world: Use local variable instead of qdev_get_machine()
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
2023-01-05 7:23 ` [PATCH v7 2/7] mac_{old, new}world: " Philippe Mathieu-Daudé
2023-01-05 17:15 ` [PATCH v7 2/7] mac_{old,new}world: " Bernhard Beschow
@ 2023-01-10 22:13 ` Mark Cave-Ayland
2 siblings, 0 replies; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-10 22:13 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
On 04/01/2023 21:59, BALATON Zoltan wrote:
> We already have machine in a local variable so no need to use
> qdev_get_machine(), also remove now unneded line break.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/ppc/mac_newworld.c | 3 +--
> hw/ppc/mac_oldworld.c | 3 +--
> 2 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 601ea518f8..460c14b5e3 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -466,8 +466,7 @@ static void ppc_core99_init(MachineState *machine)
> fw_cfg = FW_CFG(dev);
> qdev_prop_set_uint32(dev, "data_width", 1);
> qdev_prop_set_bit(dev, "dma_enabled", false);
> - object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
> - OBJECT(fw_cfg));
> + object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
> s = SYS_BUS_DEVICE(dev);
> sysbus_realize_and_unref(s, &error_fatal);
> sysbus_mmio_map(s, 0, CFG_ADDR);
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 558c639202..5a7b25a4a8 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -303,8 +303,7 @@ static void ppc_heathrow_init(MachineState *machine)
> fw_cfg = FW_CFG(dev);
> qdev_prop_set_uint32(dev, "data_width", 1);
> qdev_prop_set_bit(dev, "dma_enabled", false);
> - object_property_add_child(OBJECT(qdev_get_machine()), TYPE_FW_CFG,
> - OBJECT(fw_cfg));
> + object_property_add_child(OBJECT(machine), TYPE_FW_CFG, OBJECT(fw_cfg));
> s = SYS_BUS_DEVICE(dev);
> sysbus_realize_and_unref(s, &error_fatal);
> sysbus_mmio_map(s, 0, CFG_ADDR);
Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-04 21:59 ` [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg BALATON Zoltan
@ 2023-01-10 22:25 ` Mark Cave-Ayland
2023-01-11 0:54 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-10 22:25 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
On 04/01/2023 21:59, BALATON Zoltan wrote:
> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
> ROM and add it to the device tree for MacOS. Pass the NDRV this way
> instead of via fw_cfg. This solves the problem with OpenBIOS also
> adding the NDRV to ati-vga which it does not work with. This does not
> need any changes to OpenBIOS as this NDRV ROM handling is already
> there but this patch also allows simplifying OpenBIOS later to remove
> the fw_cfg ndrv handling from the vga FCode and also drop the
> vga-ndrv? option which is not needed any more as users can disable the
> ndrv with -device VGA,romfile="" (or override it with their own NDRV
> or ROM). Once FCode support is implemented in OpenBIOS, the proper
> FCode ROM can be set the same way so this paves the way to remove some
> hacks.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
> ---
> hw/ppc/mac_newworld.c | 18 ++++++------------
> hw/ppc/mac_oldworld.c | 18 ++++++------------
> 2 files changed, 12 insertions(+), 24 deletions(-)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 460c14b5e3..60c9c27986 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>
> - /* MacOS NDRV VGA driver */
> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
> - if (filename) {
> - gchar *ndrv_file;
> - gsize ndrv_size;
> -
> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
> - }
> - g_free(filename);
> - }
> -
> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
> }
>
> @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const char *arg)
> return 2;
> }
>
> +static GlobalProperty props[] = {
> + /* MacOS NDRV VGA driver */
> + { "VGA", "romfile", NDRV_VGA_FILENAME },
> +};
> +
> static void core99_machine_class_init(ObjectClass *oc, void *data)
> {
> MachineClass *mc = MACHINE_CLASS(oc);
> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void *data)
> #endif
> mc->default_ram_id = "ppc_core99.ram";
> mc->ignore_boot_device_suffixes = true;
> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
> fwc->get_dev_path = core99_fw_dev_path;
> }
>
> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
> index 5a7b25a4a8..6a1b1ad47a 100644
> --- a/hw/ppc/mac_oldworld.c
> +++ b/hw/ppc/mac_oldworld.c
> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>
> - /* MacOS NDRV VGA driver */
> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
> - if (filename) {
> - gchar *ndrv_file;
> - gsize ndrv_size;
> -
> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
> - }
> - g_free(filename);
> - }
> -
> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
> }
>
> @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const char *arg)
> return 2;
> }
>
> +static GlobalProperty props[] = {
> + /* MacOS NDRV VGA driver */
> + { "VGA", "romfile", NDRV_VGA_FILENAME },
> +};
> +
> static void heathrow_class_init(ObjectClass *oc, void *data)
> {
> MachineClass *mc = MACHINE_CLASS(oc);
> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
> mc->default_display = "std";
> mc->ignore_boot_device_suffixes = true;
> mc->default_ram_id = "ppc_heathrow.ram";
> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
> fwc->get_dev_path = heathrow_fw_dev_path;
> }
The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM because it is
a binary generated by a separate project: otherwise you'd end up creating a
dependency between OpenBIOS and QemuMacDrivers, which is almost impossible to achieve
since qemu_vga.ndrv can only (currently) be built in an emulated MacOS 9 guest.
The best way to do this would be to extract the PCI config words from your ATI
OpenBIOS patches and the alter drivers/vga.fs so that it only generates the
driver,AAPL,MacOS,PowerPC property if the device id and vendor id match that of the
QEMU VGA device.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-04 21:59 ` [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs BALATON Zoltan
@ 2023-01-10 22:46 ` Mark Cave-Ayland
2023-01-11 0:36 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-10 22:46 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
On 04/01/2023 21:59, BALATON Zoltan wrote:
> The mac99 machine emulates different machines depending on machine
> properties or even if it is run as qemu-system-ppc64 or
> qemu-system-ppc. This is very confusing for users and many hours were
> lost trying to explain it or finding out why commands users came up
> with are not working as expected. (E.g. Windows users might think
> qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
> then fail to boot a 32 bit OS with -M mac99 trying to follow an
> example that had qemu-system-ppc.) To avoid such confusion, add
> explicit machine types for the different configs which will work the
> same with both qemu-system-ppc and qemu-system-ppc64 and also make the
> command line clearer for new users.
>
> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
Some thoughts on this: the first is that not everyone agrees that for qemu-system-X
that X represents the target. There were previous discussion where some KVM people
assumed X represented the host, i.e. ppc64 was the binary that ran all PPC guests but
with hardware acceleration for ppc64 guests on ppc64 hosts. This was a while ago, so
it may be worth starting a thread on qemu-devel to see what the current consensus is.
Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead of
"g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For QEMU it
is always best to emulate real machines, and whilst I understand you want to separate
out the two versions of the mac99 machine, having "powermac_X_Y" seems less clear to me.
Finally can you post links to the device trees that you are using for each of the new
machine types so that we have a clear reference point for future changes to the QEMU
Mac machines? Even better include the links in the comments for each machine so that
the information is easily visible for developers.
> ---
> hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
>
> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
> index 60c9c27986..3f5d1ec097 100644
> --- a/hw/ppc/mac_newworld.c
> +++ b/hw/ppc/mac_newworld.c
> @@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
> },
> };
>
> +static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
> +{
> + MachineClass *mc = MACHINE_CLASS(oc);
> +
> + core99_machine_class_init(oc, data);
> + mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
> +}
> +
> +static void powermac3_1_instance_init(Object *obj)
> +{
> + Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> + cms->via_config = CORE99_VIA_CONFIG_PMU;
> + return;
> +}
> +
> +static const TypeInfo powermac3_1_machine_info = {
> + .name = MACHINE_TYPE_NAME("powermac3_1"),
> + .parent = TYPE_MACHINE,
> + .class_init = powermac3_1_machine_class_init,
> + .instance_init = powermac3_1_instance_init,
> + .instance_size = sizeof(Core99MachineState),
> + .interfaces = (InterfaceInfo[]) {
> + { TYPE_FW_PATH_PROVIDER },
> + { }
> + },
> +};
> +
> +static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
> +{
> + MachineClass *mc = MACHINE_CLASS(oc);
> +
> + core99_machine_class_init(oc, data);
> + mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
> +}
> +
> +static void powerbook3_2_instance_init(Object *obj)
> +{
> + Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> + cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
> + return;
> +}
> +
> +static const TypeInfo powerbook3_2_machine_info = {
> + .name = MACHINE_TYPE_NAME("powerbook3_2"),
> + .parent = TYPE_MACHINE,
> + .class_init = powerbook3_2_machine_class_init,
> + .instance_init = powerbook3_2_instance_init,
> + .instance_size = sizeof(Core99MachineState),
> + .interfaces = (InterfaceInfo[]) {
> + { TYPE_FW_PATH_PROVIDER },
> + { }
> + },
> +};
> +
> +#ifdef TARGET_PPC64
> +static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
> +{
> + MachineClass *mc = MACHINE_CLASS(oc);
> +
> + core99_machine_class_init(oc, data);
> + mc->desc = "Apple Power Mac G5 (Niagara)";
> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
> +}
> +
> +static void powermac7_3_instance_init(Object *obj)
> +{
> + Core99MachineState *cms = CORE99_MACHINE(obj);
> +
> + cms->via_config = CORE99_VIA_CONFIG_PMU;
> + return;
> +}
> +
> +static const TypeInfo powermac7_3_machine_info = {
> + .name = MACHINE_TYPE_NAME("powermac7_3"),
> + .parent = TYPE_MACHINE,
> + .class_init = powermac7_3_machine_class_init,
> + .instance_init = powermac7_3_instance_init,
> + .instance_size = sizeof(Core99MachineState),
> + .interfaces = (InterfaceInfo[]) {
> + { TYPE_FW_PATH_PROVIDER },
> + { }
> + },
> +};
> +#endif
> +
> static void mac_machine_register_types(void)
> {
> type_register_static(&core99_machine_info);
> + type_register_static(&powermac3_1_machine_info);
> + type_register_static(&powerbook3_2_machine_info);
> +#ifdef TARGET_PPC64
> + type_register_static(&powermac7_3_machine_info);
> +#endif
> }
>
> type_init(mac_machine_register_types)
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
2023-01-05 14:28 ` Philippe Mathieu-Daudé
@ 2023-01-10 22:52 ` Mark Cave-Ayland
2023-01-11 0:12 ` BALATON Zoltan
2023-01-24 21:05 ` Warner Losh
2 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-10 22:52 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-10 22:52 ` Mark Cave-Ayland
@ 2023-01-11 0:12 ` BALATON Zoltan
2023-01-12 20:22 ` Howard Spoelstra
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-11 0:12 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
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.
>
>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-10 22:46 ` Mark Cave-Ayland
@ 2023-01-11 0:36 ` BALATON Zoltan
2023-01-22 17:39 ` Mark Cave-Ayland
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-11 0:36 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, BALATON Zoltan wrote:
>> The mac99 machine emulates different machines depending on machine
>> properties or even if it is run as qemu-system-ppc64 or
>> qemu-system-ppc. This is very confusing for users and many hours were
>> lost trying to explain it or finding out why commands users came up
>> with are not working as expected. (E.g. Windows users might think
>> qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
>> then fail to boot a 32 bit OS with -M mac99 trying to follow an
>> example that had qemu-system-ppc.) To avoid such confusion, add
>> explicit machine types for the different configs which will work the
>> same with both qemu-system-ppc and qemu-system-ppc64 and also make the
>> command line clearer for new users.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>
> Some thoughts on this: the first is that not everyone agrees that for
> qemu-system-X that X represents the target. There were previous discussion
> where some KVM people assumed X represented the host, i.e. ppc64 was the
> binary that ran all PPC guests but with hardware acceleration for ppc64
> guests on ppc64 hosts. This was a while ago, so it may be worth starting a
> thread on qemu-devel to see what the current consensus is.
I don't see how this is relevant to this series, Also likely not the case
any more as qemu-system-ppc and qemu-system-ppc64 share most of the code
since a while with ppc64 including the config of ppc and adding more
machines.
> Secondly it's not clear to me why you've chosen names like "powermac_3_1"
> instead of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth
> model? For QEMU it is always best to emulate real machines, and whilst I
> understand you want to separate out the two versions of the mac99 machine,
> having "powermac_X_Y" seems less clear to me.
These machine model identifiers are used by Apple to uniquely identify
(all of) their machines since new-world Macs (even modern iPads and Macs
have them) so for Mac people this should be clearer than the informal
names that could get a bit long and confusing as there may be slight
differences within a family. In any case, qemu-system-ppc -M mac99 is not
corresponding to any real Mac so I'd like the options which do emulate
real Macs to be called in a name that show which Mac is that. For the PPC
Macs there's some info here for example:
https://en.wikipedia.org/wiki/Power_Mac_G4
And everymac.com also has info on all Macs. There were actually more than
one G4 PowerMac with AGP but the other one was informally called gigabit
ethernet. So the model ID is a shorter and better way to clearly identify
which hardware is it (and it's also referenced in the device-tree of these
Macs).
> Finally can you post links to the device trees that you are using for each of
> the new machine types so that we have a clear reference point for future
> changes to the QEMU Mac machines? Even better include the links in the
> comments for each machine so that the information is easily visible for
> developers.
I still have those I've posted over the past 8 years when I made changes
to OpenBIOS to make the device-tree closer to real machine. I've
downloaded it back then, don't know where to find it now but searching for
e.g. "PowerMac3,1" "device-tree" should get some results.
Regards,
BALATON Zoltan
>> ---
>> hw/ppc/mac_newworld.c | 94 +++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 94 insertions(+)
>>
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 60c9c27986..3f5d1ec097 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -642,9 +642,103 @@ static const TypeInfo core99_machine_info = {
>> },
>> };
>> +static void powermac3_1_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> + MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> + core99_machine_class_init(oc, data);
>> + mc->desc = "Apple Power Mac G4 AGP (Sawtooth)";
>> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
>> +}
>> +
>> +static void powermac3_1_instance_init(Object *obj)
>> +{
>> + Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> + cms->via_config = CORE99_VIA_CONFIG_PMU;
>> + return;
>> +}
>> +
>> +static const TypeInfo powermac3_1_machine_info = {
>> + .name = MACHINE_TYPE_NAME("powermac3_1"),
>> + .parent = TYPE_MACHINE,
>> + .class_init = powermac3_1_machine_class_init,
>> + .instance_init = powermac3_1_instance_init,
>> + .instance_size = sizeof(Core99MachineState),
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_FW_PATH_PROVIDER },
>> + { }
>> + },
>> +};
>> +
>> +static void powerbook3_2_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> + MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> + core99_machine_class_init(oc, data);
>> + mc->desc = "Apple PowerBook G4 Titanium (Mercury)";
>> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
>> +}
>> +
>> +static void powerbook3_2_instance_init(Object *obj)
>> +{
>> + Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> + cms->via_config = CORE99_VIA_CONFIG_PMU_ADB;
>> + return;
>> +}
>> +
>> +static const TypeInfo powerbook3_2_machine_info = {
>> + .name = MACHINE_TYPE_NAME("powerbook3_2"),
>> + .parent = TYPE_MACHINE,
>> + .class_init = powerbook3_2_machine_class_init,
>> + .instance_init = powerbook3_2_instance_init,
>> + .instance_size = sizeof(Core99MachineState),
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_FW_PATH_PROVIDER },
>> + { }
>> + },
>> +};
>> +
>> +#ifdef TARGET_PPC64
>> +static void powermac7_3_machine_class_init(ObjectClass *oc, void *data)
>> +{
>> + MachineClass *mc = MACHINE_CLASS(oc);
>> +
>> + core99_machine_class_init(oc, data);
>> + mc->desc = "Apple Power Mac G5 (Niagara)";
>> + mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("970fx_v3.1");
>> +}
>> +
>> +static void powermac7_3_instance_init(Object *obj)
>> +{
>> + Core99MachineState *cms = CORE99_MACHINE(obj);
>> +
>> + cms->via_config = CORE99_VIA_CONFIG_PMU;
>> + return;
>> +}
>> +
>> +static const TypeInfo powermac7_3_machine_info = {
>> + .name = MACHINE_TYPE_NAME("powermac7_3"),
>> + .parent = TYPE_MACHINE,
>> + .class_init = powermac7_3_machine_class_init,
>> + .instance_init = powermac7_3_instance_init,
>> + .instance_size = sizeof(Core99MachineState),
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_FW_PATH_PROVIDER },
>> + { }
>> + },
>> +};
>> +#endif
>> +
>> static void mac_machine_register_types(void)
>> {
>> type_register_static(&core99_machine_info);
>> + type_register_static(&powermac3_1_machine_info);
>> + type_register_static(&powerbook3_2_machine_info);
>> +#ifdef TARGET_PPC64
>> + type_register_static(&powermac7_3_machine_info);
>> +#endif
>> }
>> type_init(mac_machine_register_types)
>
>
> ATB,
>
> Mark.
>
>
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-10 22:25 ` Mark Cave-Ayland
@ 2023-01-11 0:54 ` BALATON Zoltan
2023-01-22 17:54 ` Mark Cave-Ayland
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-11 0:54 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, BALATON Zoltan wrote:
>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>> adding the NDRV to ati-vga which it does not work with. This does not
>> need any changes to OpenBIOS as this NDRV ROM handling is already
>> there but this patch also allows simplifying OpenBIOS later to remove
>> the fw_cfg ndrv handling from the vga FCode and also drop the
>> vga-ndrv? option which is not needed any more as users can disable the
>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>> FCode ROM can be set the same way so this paves the way to remove some
>> hacks.
>>
>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>> ---
>> hw/ppc/mac_newworld.c | 18 ++++++------------
>> hw/ppc/mac_oldworld.c | 18 ++++++------------
>> 2 files changed, 12 insertions(+), 24 deletions(-)
>>
>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>> index 460c14b5e3..60c9c27986 100644
>> --- a/hw/ppc/mac_newworld.c
>> +++ b/hw/ppc/mac_newworld.c
>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>> - /* MacOS NDRV VGA driver */
>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>> - if (filename) {
>> - gchar *ndrv_file;
>> - gsize ndrv_size;
>> -
>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file,
>> ndrv_size);
>> - }
>> - g_free(filename);
>> - }
>> -
>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>> }
>> @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine,
>> const char *arg)
>> return 2;
>> }
>> +static GlobalProperty props[] = {
>> + /* MacOS NDRV VGA driver */
>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>> +};
>> +
>> static void core99_machine_class_init(ObjectClass *oc, void *data)
>> {
>> MachineClass *mc = MACHINE_CLASS(oc);
>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc,
>> void *data)
>> #endif
>> mc->default_ram_id = "ppc_core99.ram";
>> mc->ignore_boot_device_suffixes = true;
>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>> fwc->get_dev_path = core99_fw_dev_path;
>> }
>> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>> index 5a7b25a4a8..6a1b1ad47a 100644
>> --- a/hw/ppc/mac_oldworld.c
>> +++ b/hw/ppc/mac_oldworld.c
>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>> - /* MacOS NDRV VGA driver */
>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>> - if (filename) {
>> - gchar *ndrv_file;
>> - gsize ndrv_size;
>> -
>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file,
>> ndrv_size);
>> - }
>> - g_free(filename);
>> - }
>> -
>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>> }
>> @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine,
>> const char *arg)
>> return 2;
>> }
>> +static GlobalProperty props[] = {
>> + /* MacOS NDRV VGA driver */
>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>> +};
>> +
>> static void heathrow_class_init(ObjectClass *oc, void *data)
>> {
>> MachineClass *mc = MACHINE_CLASS(oc);
>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void
>> *data)
>> mc->default_display = "std";
>> mc->ignore_boot_device_suffixes = true;
>> mc->default_ram_id = "ppc_heathrow.ram";
>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>> fwc->get_dev_path = heathrow_fw_dev_path;
>> }
>
> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM
> because it is a binary generated by a separate project: otherwise you'd end
> up creating a dependency between OpenBIOS and QemuMacDrivers, which is almost
> impossible to achieve since qemu_vga.ndrv can only (currently) be built in an
> emulated MacOS 9 guest.
I don't get this. The dependency is already there as qemu_vga.ndrv ships
with QEMU such as all the vgabios-*.bin and SeaBIOS binaries which are
also built from different projects. The qemu_vga.ndrv would also still be
part of an FCode ROM together with vga.fs if OpenBIOS could run that so
this patch solely changes the way of passing the ROM binary to OpenBIOS
from fw_cfg to the card ROM which is closer to how it should be and can
direcly be replaced with the FCode ROM later after OpenBIOS will be
advanced to that point.
> The best way to do this would be to extract the PCI config words from your
> ATI OpenBIOS patches and the alter drivers/vga.fs so that it only generates
> the driver,AAPL,MacOS,PowerPC property if the device id and vendor id match
> that of the QEMU VGA device.
This is further down the road and does not block this patch. The config
access words should be provided by OpenBIOS not vga.fs. If we want to do
it like on the real machine then vga.fs and qemu_vga,ndrv should be
together the FCode ROM that the card has and OpenBIOS would run that. This
is also how the ATI and NVIDIA ROMs do it which contain some Forth to init
the card and add the embedded ndrv to the device tree for MacOS. But
that's independent of this patch and needs OpenBIOS changes, while this
patch does not need any change in OpenBIOS just moves to that direction to
be able to attach a proper FCode ROM sometimes later and simpify fw_cfg
handling in OpenBIOS. For now adding the ndrv in the ROM is enough for
OpenBIOS as it has additional code to handle it already.
So this patch neither adds new dependency to QEMU nor repends on any
change in OpenBIOS. It just gets rid of passing files via fw_cfg.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-11 0:12 ` BALATON Zoltan
@ 2023-01-12 20:22 ` Howard Spoelstra
2023-01-12 23:51 ` BALATON Zoltan
2023-01-24 16:37 ` BALATON Zoltan
0 siblings, 2 replies; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-12 20:22 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 2954 bytes --]
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.
> >
> >
>
>
[-- Attachment #2: Type: text/html, Size: 4141 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-12 20:22 ` Howard Spoelstra
@ 2023-01-12 23:51 ` BALATON Zoltan
2023-01-13 7:26 ` Howard Spoelstra
2023-01-22 18:06 ` Mark Cave-Ayland
2023-01-24 16:37 ` BALATON Zoltan
1 sibling, 2 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-12 23:51 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-12 23:51 ` BALATON Zoltan
@ 2023-01-13 7:26 ` Howard Spoelstra
2023-01-13 13:32 ` BALATON Zoltan
2023-01-22 18:06 ` Mark Cave-Ayland
1 sibling, 1 reply; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-13 7:26 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 5636 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 7666 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-13 7:26 ` Howard Spoelstra
@ 2023-01-13 13:32 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-13 13:32 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-11 0:36 ` BALATON Zoltan
@ 2023-01-22 17:39 ` Mark Cave-Ayland
2023-01-22 21:48 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-22 17:39 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc
On 11/01/2023 00:36, BALATON Zoltan wrote:
> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>> The mac99 machine emulates different machines depending on machine
>>> properties or even if it is run as qemu-system-ppc64 or
>>> qemu-system-ppc. This is very confusing for users and many hours were
>>> lost trying to explain it or finding out why commands users came up
>>> with are not working as expected. (E.g. Windows users might think
>>> qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
>>> then fail to boot a 32 bit OS with -M mac99 trying to follow an
>>> example that had qemu-system-ppc.) To avoid such confusion, add
>>> explicit machine types for the different configs which will work the
>>> same with both qemu-system-ppc and qemu-system-ppc64 and also make the
>>> command line clearer for new users.
>>>
>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>
>> Some thoughts on this: the first is that not everyone agrees that for qemu-system-X
>> that X represents the target. There were previous discussion where some KVM people
>> assumed X represented the host, i.e. ppc64 was the binary that ran all PPC guests
>> but with hardware acceleration for ppc64 guests on ppc64 hosts. This was a while
>> ago, so it may be worth starting a thread on qemu-devel to see what the current
>> consensus is.
>
> I don't see how this is relevant to this series, Also likely not the case any more as
> qemu-system-ppc and qemu-system-ppc64 share most of the code since a while with ppc64
> including the config of ppc and adding more machines.
Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So you're
making the assumption qemu-system-ppc64 represents a 64-bit target rather than a
64-bit host.
>> Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead
>> of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For QEMU
>> it is always best to emulate real machines, and whilst I understand you want to
>> separate out the two versions of the mac99 machine, having "powermac_X_Y" seems
>> less clear to me.
>
> These machine model identifiers are used by Apple to uniquely identify (all of) their
> machines since new-world Macs (even modern iPads and Macs have them) so for Mac
> people this should be clearer than the informal names that could get a bit long and
> confusing as there may be slight differences within a family. In any case,
> qemu-system-ppc -M mac99 is not corresponding to any real Mac so I'd like the options
> which do emulate real Macs to be called in a name that show which Mac is that. For
> the PPC Macs there's some info here for example:
>
> https://en.wikipedia.org/wiki/Power_Mac_G4
>
> And everymac.com also has info on all Macs. There were actually more than one G4
> PowerMac with AGP but the other one was informally called gigabit ethernet. So the
> model ID is a shorter and better way to clearly identify which hardware is it (and
> it's also referenced in the device-tree of these Macs).
Are you planning to work on different types of G4 Mac where this could be confusing?
Even to me "PowerMac 3.1" doesn't really tell me what model of Mac is being emulated,
whereas "g4agp" (much in the same way as g3beige) is much more friendlier to people
interested in using QEMU for Mac emulation.
>> Finally can you post links to the device trees that you are using for each of the
>> new machine types so that we have a clear reference point for future changes to the
>> QEMU Mac machines? Even better include the links in the comments for each machine
>> so that the information is easily visible for developers.
>
> I still have those I've posted over the past 8 years when I made changes to OpenBIOS
> to make the device-tree closer to real machine. I've downloaded it back then, don't
> know where to find it now but searching for e.g. "PowerMac3,1" "device-tree" should
> get some results.
Nothing shows up for me, I'm afraid (remember that Google searches are unique to each
user). If you want argue for changing the QEMU machines, then we should agree on the
reference device model for future changes.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-11 0:54 ` BALATON Zoltan
@ 2023-01-22 17:54 ` Mark Cave-Ayland
2023-01-22 22:16 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-22 17:54 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc
On 11/01/2023 00:54, BALATON Zoltan wrote:
> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>>> adding the NDRV to ati-vga which it does not work with. This does not
>>> need any changes to OpenBIOS as this NDRV ROM handling is already
>>> there but this patch also allows simplifying OpenBIOS later to remove
>>> the fw_cfg ndrv handling from the vga FCode and also drop the
>>> vga-ndrv? option which is not needed any more as users can disable the
>>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>>> FCode ROM can be set the same way so this paves the way to remove some
>>> hacks.
>>>
>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>> ---
>>> hw/ppc/mac_newworld.c | 18 ++++++------------
>>> hw/ppc/mac_oldworld.c | 18 ++++++------------
>>> 2 files changed, 12 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>>> index 460c14b5e3..60c9c27986 100644
>>> --- a/hw/ppc/mac_newworld.c
>>> +++ b/hw/ppc/mac_newworld.c
>>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>>> - /* MacOS NDRV VGA driver */
>>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>> - if (filename) {
>>> - gchar *ndrv_file;
>>> - gsize ndrv_size;
>>> -
>>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
>>> - }
>>> - g_free(filename);
>>> - }
>>> -
>>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>> }
>>> @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine, const
>>> char *arg)
>>> return 2;
>>> }
>>> +static GlobalProperty props[] = {
>>> + /* MacOS NDRV VGA driver */
>>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>>> +};
>>> +
>>> static void core99_machine_class_init(ObjectClass *oc, void *data)
>>> {
>>> MachineClass *mc = MACHINE_CLASS(oc);
>>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass *oc, void
>>> *data)
>>> #endif
>>> mc->default_ram_id = "ppc_core99.ram";
>>> mc->ignore_boot_device_suffixes = true;
>>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>> fwc->get_dev_path = core99_fw_dev_path;
>>> }
>>> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>>> index 5a7b25a4a8..6a1b1ad47a 100644
>>> --- a/hw/ppc/mac_oldworld.c
>>> +++ b/hw/ppc/mac_oldworld.c
>>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>> - /* MacOS NDRV VGA driver */
>>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>> - if (filename) {
>>> - gchar *ndrv_file;
>>> - gsize ndrv_size;
>>> -
>>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL)) {
>>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file, ndrv_size);
>>> - }
>>> - g_free(filename);
>>> - }
>>> -
>>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>> }
>>> @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState *machine, const
>>> char *arg)
>>> return 2;
>>> }
>>> +static GlobalProperty props[] = {
>>> + /* MacOS NDRV VGA driver */
>>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>>> +};
>>> +
>>> static void heathrow_class_init(ObjectClass *oc, void *data)
>>> {
>>> MachineClass *mc = MACHINE_CLASS(oc);
>>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void *data)
>>> mc->default_display = "std";
>>> mc->ignore_boot_device_suffixes = true;
>>> mc->default_ram_id = "ppc_heathrow.ram";
>>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>> fwc->get_dev_path = heathrow_fw_dev_path;
>>> }
>>
>> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM because it
>> is a binary generated by a separate project: otherwise you'd end up creating a
>> dependency between OpenBIOS and QemuMacDrivers, which is almost impossible to
>> achieve since qemu_vga.ndrv can only (currently) be built in an emulated MacOS 9
>> guest.
>
> I don't get this. The dependency is already there as qemu_vga.ndrv ships with QEMU
> such as all the vgabios-*.bin and SeaBIOS binaries which are also built from
> different projects. The qemu_vga.ndrv would also still be part of an FCode ROM
> together with vga.fs if OpenBIOS could run that so this patch solely changes the way
> of passing the ROM binary to OpenBIOS from fw_cfg to the card ROM which is closer to
> how it should be and can direcly be replaced with the FCode ROM later after OpenBIOS
> will be advanced to that point.
Even if OpenBIOS were able to execute PCI option ROMs, the problem is that OpenBIOS
cannot generate the qemu_vga.ndrv binary from source and therefore cannot generate
the complete ROM by itself. Hence why the existing mechanism exists to inject
qemu_vga.ndrv via fw_cfg() so the OpenBIOS ROM is self-contained.
>> The best way to do this would be to extract the PCI config words from your ATI
>> OpenBIOS patches and the alter drivers/vga.fs so that it only generates the
>> driver,AAPL,MacOS,PowerPC property if the device id and vendor id match that of the
>> QEMU VGA device.
>
> This is further down the road and does not block this patch. The config access words
> should be provided by OpenBIOS not vga.fs. If we want to do it like on the real
> machine then vga.fs and qemu_vga,ndrv should be together the FCode ROM that the card
> has and OpenBIOS would run that. This is also how the ATI and NVIDIA ROMs do it which
> contain some Forth to init the card and add the embedded ndrv to the device tree for
> MacOS. But that's independent of this patch and needs OpenBIOS changes, while this
> patch does not need any change in OpenBIOS just moves to that direction to be able to
> attach a proper FCode ROM sometimes later and simpify fw_cfg handling in OpenBIOS.
> For now adding the ndrv in the ROM is enough for OpenBIOS as it has additional code
> to handle it already.
The problem you are ultimately trying to solve though is that OpenBIOS is loading the
NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the NDRV is
loaded only for the QEMU VGA device?
> So this patch neither adds new dependency to QEMU nor repends on any change in
> OpenBIOS. It just gets rid of passing files via fw_cfg.
Unfortunately that still doesn't solve the problem of building a self-contained
OpenBIOS ROM, so this patch isn't the right way forward.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-12 23:51 ` BALATON Zoltan
2023-01-13 7:26 ` Howard Spoelstra
@ 2023-01-22 18:06 ` Mark Cave-Ayland
2023-01-22 22:07 ` BALATON Zoltan
1 sibling, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-22 18:06 UTC (permalink / raw)
To: BALATON Zoltan, Howard Spoelstra; +Cc: qemu-devel, qemu-ppc
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-22 17:39 ` Mark Cave-Ayland
@ 2023-01-22 21:48 ` BALATON Zoltan
2023-01-22 22:18 ` Josh Juran
2023-01-23 21:36 ` Mark Cave-Ayland
0 siblings, 2 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-22 21:48 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
> On 11/01/2023 00:36, BALATON Zoltan wrote:
>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>> The mac99 machine emulates different machines depending on machine
>>>> properties or even if it is run as qemu-system-ppc64 or
>>>> qemu-system-ppc. This is very confusing for users and many hours were
>>>> lost trying to explain it or finding out why commands users came up
>>>> with are not working as expected. (E.g. Windows users might think
>>>> qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
>>>> then fail to boot a 32 bit OS with -M mac99 trying to follow an
>>>> example that had qemu-system-ppc.) To avoid such confusion, add
>>>> explicit machine types for the different configs which will work the
>>>> same with both qemu-system-ppc and qemu-system-ppc64 and also make the
>>>> command line clearer for new users.
>>>>
>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>
>>> Some thoughts on this: the first is that not everyone agrees that for
>>> qemu-system-X that X represents the target. There were previous discussion
>>> where some KVM people assumed X represented the host, i.e. ppc64 was the
>>> binary that ran all PPC guests but with hardware acceleration for ppc64
>>> guests on ppc64 hosts. This was a while ago, so it may be worth starting a
>>> thread on qemu-devel to see what the current consensus is.
>>
>> I don't see how this is relevant to this series, Also likely not the case
>> any more as qemu-system-ppc and qemu-system-ppc64 share most of the code
>> since a while with ppc64 including the config of ppc and adding more
>> machines.
>
> Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So
> you're making the assumption qemu-system-ppc64 represents a 64-bit target
> rather than a 64-bit host.
I'm not making that assumption, it's already there:
$ qemu-system-ppc -machine help
Supported machines are:
40p IBM RS/6000 7020 (40p)
bamboo bamboo
g3beige Heathrow based PowerMAC (default)
mac99 Mac99 based PowerMAC
mpc8544ds mpc8544ds
none empty machine
pegasos2 Genesi/bPlan Pegasos II
ppce500 generic paravirt e500 platform
ref405ep ref405ep
sam460ex aCube Sam460ex
virtex-ml507 Xilinx Virtex ML507 reference design
$ 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
powernv IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9)
powernv9 IBM PowerNV (Non-Virtualized) POWER9
ppce500 generic paravirt e500 platform
pseries-2.1 pSeries Logical Partition (PAPR compliant)
[lots of different pseries versions omitted here]
pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-8.0)
pseries-8.0 pSeries Logical Partition (PAPR compliant) (default)
ref405ep ref405ep
sam460ex aCube Sam460ex
virtex-ml507 Xilinx Virtex ML507 reference design
It makes no sense to define it for qemu-system-ppc as that version does
not have G5 and 64 bit CPUs compiled in. Cf. qemu-system-ppc -cpu help and
qemu-system-ppc64 -cpu help or target/ppc/cpu-models.c so I don't know
what you're talking about.
>>> Secondly it's not clear to me why you've chosen names like "powermac_3_1"
>>> instead of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP
>>> Sawtooth model? For QEMU it is always best to emulate real machines, and
>>> whilst I understand you want to separate out the two versions of the mac99
>>> machine, having "powermac_X_Y" seems less clear to me.
>>
>> These machine model identifiers are used by Apple to uniquely identify (all
>> of) their machines since new-world Macs (even modern iPads and Macs have
>> them) so for Mac people this should be clearer than the informal names that
>> could get a bit long and confusing as there may be slight differences
>> within a family. In any case, qemu-system-ppc -M mac99 is not corresponding
>> to any real Mac so I'd like the options which do emulate real Macs to be
>> called in a name that show which Mac is that. For the PPC Macs there's some
>> info here for example:
>>
>> https://en.wikipedia.org/wiki/Power_Mac_G4
>>
>> And everymac.com also has info on all Macs. There were actually more than
>> one G4 PowerMac with AGP but the other one was informally called gigabit
>> ethernet. So the model ID is a shorter and better way to clearly identify
>> which hardware is it (and it's also referenced in the device-tree of these
>> Macs).
>
> Are you planning to work on different types of G4 Mac where this could be
> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of Mac
> is being emulated, whereas "g4agp" (much in the same way as g3beige) is much
> more friendlier to people interested in using QEMU for Mac emulation.
This is similar problem as some people like to call Mac OS X versions by
number and some by big cats names. Personally I prefer version numbers
because it's easy to tell which is newer or older that way without
remembering a nomenclature or having to look it up every time. It would be
good if others interested in this also shared their preference because if
it's only us two with different views then it's hard to make a decision. I
still think machine ID is better also because then these machines would be
grouped in the -machine help output like the others but as long as we
don't have other machines that start with a g or other Macs that have some
other name it might work so I could change the naming if that's all needed
for this to get in.
>>> Finally can you post links to the device trees that you are using for each
>>> of the new machine types so that we have a clear reference point for
>>> future changes to the QEMU Mac machines? Even better include the links in
>>> the comments for each machine so that the information is easily visible
>>> for developers.
>>
>> I still have those I've posted over the past 8 years when I made changes to
>> OpenBIOS to make the device-tree closer to real machine. I've downloaded it
>> back then, don't know where to find it now but searching for e.g.
>> "PowerMac3,1" "device-tree" should get some results.
>
> Nothing shows up for me, I'm afraid (remember that Google searches are unique
> to each user). If you want argue for changing the QEMU machines, then we
> should agree on the reference device model for future changes.
Sigh, maybe search your list archives instead of Googls. Also it's
"PowerMac3,1" where I've converted the comma to underscre for qemu command
line parsing so became powermac3_1 not powermac_3_1. Try searching with
quotes to reduce the number of false results.
- mac99 (via=cuda) does not exist so no real device tree for this needed
- powermac3_1 (currently mac99,via=pmu) I've sent links years ago e.g.:
https://mail.coreboot.org/pipermail/openbios/2016-February/009145.html
but you still keep asking
- powermac7_3 (ppc64 mac99) The expected hardware is listed in a comment
in mac_newworld.c also it adds a 970fx CPU and according to
https://en.wikipedia.org/wiki/Power_Mac_G5 PowerMac7,3 was the first
version with 970fx so I think that was the target for whoever started it
back then. These G5 Macs are probably still around so you should be able
to ask someone to get a device tree dump, I've only seen Linux hardware
listings:
https://gist.github.com/tomari/3689297
https://forum.ubuntu-fr.org/viewtopic.php?id=2026003 (last post)
-powerbook3_2 (mac99,via=pmi-adb) this is rare as Macs with PMU usually
have USB and not ADB; only the first PowerBooks had an ADB trackpad (but
no outside ports AFAIK). All other Macs with ADB had CUDA so I'm not even
sure we need this option but if we want it then the first PowerBooks are
candidates, I've picked the lowest number for 1st gen Titanium PowerBook
from here:
https://en.wikipedia.org/wiki/PowerBook_G4
and e.g. these links confirm it had ADB:
https://forums.freebsd.org/threads/12-powerbook-g4-867mhz-xorg-doesnt-work.37815/
http://macos9lives.com/smforum/index.php/topic,4781.msg41380.html?PHPSESSID=75b23dcb4c042b51c6dddd311cff2341#msg41380
It would be tough to come up with a name for the powerbook3_2 though as
these were called Early 2001 Titanium PowerBook G4 or code name Mercury
but even Mac fanatics probably couldn't tell that was a powerbook if you
call it g4mercury so I'm open to votes on naming but hard to be convinced
there's anything simpler and more straightforward than using machine id
which is usually also listed everywhere for these.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-22 18:06 ` Mark Cave-Ayland
@ 2023-01-22 22:07 ` BALATON Zoltan
2023-01-23 22:06 ` Mark Cave-Ayland
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-22 22:07 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Howard Spoelstra, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-22 17:54 ` Mark Cave-Ayland
@ 2023-01-22 22:16 ` BALATON Zoltan
2023-01-23 22:12 ` Mark Cave-Ayland
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-22 22:16 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 8829 bytes --]
On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
> On 11/01/2023 00:54, BALATON Zoltan wrote:
>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>> OpenBIOS cannot run FCode ROMs yet but it can detect NDRV in VGA card
>>>> ROM and add it to the device tree for MacOS. Pass the NDRV this way
>>>> instead of via fw_cfg. This solves the problem with OpenBIOS also
>>>> adding the NDRV to ati-vga which it does not work with. This does not
>>>> need any changes to OpenBIOS as this NDRV ROM handling is already
>>>> there but this patch also allows simplifying OpenBIOS later to remove
>>>> the fw_cfg ndrv handling from the vga FCode and also drop the
>>>> vga-ndrv? option which is not needed any more as users can disable the
>>>> ndrv with -device VGA,romfile="" (or override it with their own NDRV
>>>> or ROM). Once FCode support is implemented in OpenBIOS, the proper
>>>> FCode ROM can be set the same way so this paves the way to remove some
>>>> hacks.
>>>>
>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>> ---
>>>> hw/ppc/mac_newworld.c | 18 ++++++------------
>>>> hw/ppc/mac_oldworld.c | 18 ++++++------------
>>>> 2 files changed, 12 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
>>>> index 460c14b5e3..60c9c27986 100644
>>>> --- a/hw/ppc/mac_newworld.c
>>>> +++ b/hw/ppc/mac_newworld.c
>>>> @@ -510,18 +510,6 @@ static void ppc_core99_init(MachineState *machine)
>>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_NVRAM_ADDR, nvram_addr);
>>>> - /* MacOS NDRV VGA driver */
>>>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>>> - if (filename) {
>>>> - gchar *ndrv_file;
>>>> - gsize ndrv_size;
>>>> -
>>>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL))
>>>> {
>>>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file,
>>>> ndrv_size);
>>>> - }
>>>> - g_free(filename);
>>>> - }
>>>> -
>>>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>> }
>>>> @@ -565,6 +553,11 @@ static int core99_kvm_type(MachineState *machine,
>>>> const char *arg)
>>>> return 2;
>>>> }
>>>> +static GlobalProperty props[] = {
>>>> + /* MacOS NDRV VGA driver */
>>>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>>>> +};
>>>> +
>>>> static void core99_machine_class_init(ObjectClass *oc, void *data)
>>>> {
>>>> MachineClass *mc = MACHINE_CLASS(oc);
>>>> @@ -585,6 +578,7 @@ static void core99_machine_class_init(ObjectClass
>>>> *oc, void *data)
>>>> #endif
>>>> mc->default_ram_id = "ppc_core99.ram";
>>>> mc->ignore_boot_device_suffixes = true;
>>>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>> fwc->get_dev_path = core99_fw_dev_path;
>>>> }
>>>> diff --git a/hw/ppc/mac_oldworld.c b/hw/ppc/mac_oldworld.c
>>>> index 5a7b25a4a8..6a1b1ad47a 100644
>>>> --- a/hw/ppc/mac_oldworld.c
>>>> +++ b/hw/ppc/mac_oldworld.c
>>>> @@ -344,18 +344,6 @@ static void ppc_heathrow_init(MachineState *machine)
>>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_CLOCKFREQ, CLOCKFREQ);
>>>> fw_cfg_add_i32(fw_cfg, FW_CFG_PPC_BUSFREQ, BUSFREQ);
>>>> - /* MacOS NDRV VGA driver */
>>>> - filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, NDRV_VGA_FILENAME);
>>>> - if (filename) {
>>>> - gchar *ndrv_file;
>>>> - gsize ndrv_size;
>>>> -
>>>> - if (g_file_get_contents(filename, &ndrv_file, &ndrv_size, NULL))
>>>> {
>>>> - fw_cfg_add_file(fw_cfg, "ndrv/qemu_vga.ndrv", ndrv_file,
>>>> ndrv_size);
>>>> - }
>>>> - g_free(filename);
>>>> - }
>>>> -
>>>> qemu_register_boot_set(fw_cfg_boot_set, fw_cfg);
>>>> }
>>>> @@ -400,6 +388,11 @@ static int heathrow_kvm_type(MachineState
>>>> *machine, const char *arg)
>>>> return 2;
>>>> }
>>>> +static GlobalProperty props[] = {
>>>> + /* MacOS NDRV VGA driver */
>>>> + { "VGA", "romfile", NDRV_VGA_FILENAME },
>>>> +};
>>>> +
>>>> static void heathrow_class_init(ObjectClass *oc, void *data)
>>>> {
>>>> MachineClass *mc = MACHINE_CLASS(oc);
>>>> @@ -420,6 +413,7 @@ static void heathrow_class_init(ObjectClass *oc, void
>>>> *data)
>>>> mc->default_display = "std";
>>>> mc->ignore_boot_device_suffixes = true;
>>>> mc->default_ram_id = "ppc_heathrow.ram";
>>>> + compat_props_add(mc->compat_props, props, G_N_ELEMENTS(props));
>>>> fwc->get_dev_path = heathrow_fw_dev_path;
>>>> }
>>>
>>> The qemu_vga.ndrv is deliberately kept separate from the PCI option ROM
>>> because it is a binary generated by a separate project: otherwise you'd
>>> end up creating a dependency between OpenBIOS and QemuMacDrivers, which is
>>> almost impossible to achieve since qemu_vga.ndrv can only (currently) be
>>> built in an emulated MacOS 9 guest.
>>
>> I don't get this. The dependency is already there as qemu_vga.ndrv ships
>> with QEMU such as all the vgabios-*.bin and SeaBIOS binaries which are also
>> built from different projects. The qemu_vga.ndrv would also still be part
>> of an FCode ROM together with vga.fs if OpenBIOS could run that so this
>> patch solely changes the way of passing the ROM binary to OpenBIOS from
>> fw_cfg to the card ROM which is closer to how it should be and can direcly
>> be replaced with the FCode ROM later after OpenBIOS will be advanced to
>> that point.
>
> Even if OpenBIOS were able to execute PCI option ROMs, the problem is that
> OpenBIOS cannot generate the qemu_vga.ndrv binary from source and therefore
> cannot generate the complete ROM by itself. Hence why the existing mechanism
> exists to inject qemu_vga.ndrv via fw_cfg() so the OpenBIOS ROM is
> self-contained.
And how does this change by this patch? The ndrv is built separately and
included in QEMU currently. This does not change at all. The only thing
that changes is that QEMU does not add it to fw_cfg but to the ROM where
OpenBIOS adds it to the device tree but it can do it much simpler removing
some code to handle downloading the file as it already reads the ROM. The
option ROM is not self contained now and it will not be after this patch
it's just a different way to solve the same issue simpler. What you don't
like about it?
>>> The best way to do this would be to extract the PCI config words from your
>>> ATI OpenBIOS patches and the alter drivers/vga.fs so that it only
>>> generates the driver,AAPL,MacOS,PowerPC property if the device id and
>>> vendor id match that of the QEMU VGA device.
>>
>> This is further down the road and does not block this patch. The config
>> access words should be provided by OpenBIOS not vga.fs. If we want to do it
>> like on the real machine then vga.fs and qemu_vga,ndrv should be together
>> the FCode ROM that the card has and OpenBIOS would run that. This is also
>> how the ATI and NVIDIA ROMs do it which contain some Forth to init the card
>> and add the embedded ndrv to the device tree for MacOS. But that's
>> independent of this patch and needs OpenBIOS changes, while this patch does
>> not need any change in OpenBIOS just moves to that direction to be able to
>> attach a proper FCode ROM sometimes later and simpify fw_cfg handling in
>> OpenBIOS. For now adding the ndrv in the ROM is enough for OpenBIOS as it
>> has additional code to handle it already.
>
> The problem you are ultimately trying to solve though is that OpenBIOS is
> loading the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs
> so that the NDRV is loaded only for the QEMU VGA device?
>
>> So this patch neither adds new dependency to QEMU nor repends on any change
>> in OpenBIOS. It just gets rid of passing files via fw_cfg.
>
> Unfortunately that still doesn't solve the problem of building a
> self-contained OpenBIOS ROM, so this patch isn't the right way forward.
It does take a step to make it possible to eventually add a self contained
ROM and remove the vga.fs from OpenBIOS but it's not doing that fully. It
just simplifies QEMU and OpenBIOS vga.fs for now and making the ROM also
contain the FCode will be a further step but we can't get there if you
don't allow to make smaller steps or don't merge my patches for OpenBIOS
which would allow it to run FCode ROMs. If you're waiting for all this to
be finished I'll give up and it will never be finished. If you allow to
progress in smaller steps then maybe we'll get there.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-22 21:48 ` BALATON Zoltan
@ 2023-01-22 22:18 ` Josh Juran
2023-01-23 21:36 ` Mark Cave-Ayland
1 sibling, 0 replies; 64+ messages in thread
From: Josh Juran @ 2023-01-22 22:18 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
On Jan 22, 2023, at 4:48 PM, BALATON Zoltan <balaton@eik.bme.hu> wrote:
> It would be tough to come up with a name for the powerbook3_2 though as these were called Early 2001 Titanium PowerBook G4 or code name Mercury but even Mac fanatics probably couldn't tell that was a powerbook if you call it g4mercury so I'm open to votes on naming but hard to be convinced there's anything simpler and more straightforward than using machine id which is usually also listed everywhere for these.
g4tibook1stgen?
("TiBook" being an affectionate abbreviation for "Titanium PowerBook")
Cheers,
Josh
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-22 21:48 ` BALATON Zoltan
2023-01-22 22:18 ` Josh Juran
@ 2023-01-23 21:36 ` Mark Cave-Ayland
2023-01-24 0:36 ` BALATON Zoltan
1 sibling, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-23 21:36 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc
On 22/01/2023 21:48, BALATON Zoltan wrote:
> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
>> On 11/01/2023 00:36, BALATON Zoltan wrote:
>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>>> The mac99 machine emulates different machines depending on machine
>>>>> properties or even if it is run as qemu-system-ppc64 or
>>>>> qemu-system-ppc. This is very confusing for users and many hours were
>>>>> lost trying to explain it or finding out why commands users came up
>>>>> with are not working as expected. (E.g. Windows users might think
>>>>> qemu-system-ppc64 is just the 64 bit version of qemu-system-ppc and
>>>>> then fail to boot a 32 bit OS with -M mac99 trying to follow an
>>>>> example that had qemu-system-ppc.) To avoid such confusion, add
>>>>> explicit machine types for the different configs which will work the
>>>>> same with both qemu-system-ppc and qemu-system-ppc64 and also make the
>>>>> command line clearer for new users.
>>>>>
>>>>> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu>
>>>>
>>>> Some thoughts on this: the first is that not everyone agrees that for
>>>> qemu-system-X that X represents the target. There were previous discussion where
>>>> some KVM people assumed X represented the host, i.e. ppc64 was the binary that
>>>> ran all PPC guests but with hardware acceleration for ppc64 guests on ppc64
>>>> hosts. This was a while ago, so it may be worth starting a thread on qemu-devel
>>>> to see what the current consensus is.
>>>
>>> I don't see how this is relevant to this series, Also likely not the case any more
>>> as qemu-system-ppc and qemu-system-ppc64 share most of the code since a while with
>>> ppc64 including the config of ppc and adding more machines.
>>
>> Well the patch defines the powermac 7.3 machine just for TARGET_PPC64, no? So
>> you're making the assumption qemu-system-ppc64 represents a 64-bit target rather
>> than a 64-bit host.
>
> I'm not making that assumption, it's already there:
>
> $ qemu-system-ppc -machine help
> Supported machines are:
> 40p IBM RS/6000 7020 (40p)
> bamboo bamboo
> g3beige Heathrow based PowerMAC (default)
> mac99 Mac99 based PowerMAC
> mpc8544ds mpc8544ds
> none empty machine
> pegasos2 Genesi/bPlan Pegasos II
> ppce500 generic paravirt e500 platform
> ref405ep ref405ep
> sam460ex aCube Sam460ex
> virtex-ml507 Xilinx Virtex ML507 reference design
>
> $ 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
> powernv IBM PowerNV (Non-Virtualized) POWER9 (alias of powernv9)
> powernv9 IBM PowerNV (Non-Virtualized) POWER9
> ppce500 generic paravirt e500 platform
> pseries-2.1 pSeries Logical Partition (PAPR compliant)
> [lots of different pseries versions omitted here]
> pseries pSeries Logical Partition (PAPR compliant) (alias of pseries-8.0)
> pseries-8.0 pSeries Logical Partition (PAPR compliant) (default)
> ref405ep ref405ep
> sam460ex aCube Sam460ex
> virtex-ml507 Xilinx Virtex ML507 reference design
>
> It makes no sense to define it for qemu-system-ppc as that version does not have G5
> and 64 bit CPUs compiled in. Cf. qemu-system-ppc -cpu help and qemu-system-ppc64 -cpu
> help or target/ppc/cpu-models.c so I don't know what you're talking about.
I did a quick ask around online, and the general consensus was that it references the
target (see https://lists.gnu.org/archive/html/qemu-devel/2022-05/msg00757.html for
one of the more recent discussions about this as why this isn't always clear).
However as you point out the 64-bit CPU isn't available for qemu-system-ppc so you're
right that won't be an issue here.
>>>> Secondly it's not clear to me why you've chosen names like "powermac_3_1" instead
>>>> of "g4agp"? Does powermac_3_1 uniquely identify the G4 AGP Sawtooth model? For
>>>> QEMU it is always best to emulate real machines, and whilst I understand you want
>>>> to separate out the two versions of the mac99 machine, having "powermac_X_Y"
>>>> seems less clear to me.
>>>
>>> These machine model identifiers are used by Apple to uniquely identify (all of)
>>> their machines since new-world Macs (even modern iPads and Macs have them) so for
>>> Mac people this should be clearer than the informal names that could get a bit
>>> long and confusing as there may be slight differences within a family. In any
>>> case, qemu-system-ppc -M mac99 is not corresponding to any real Mac so I'd like
>>> the options which do emulate real Macs to be called in a name that show which Mac
>>> is that. For the PPC Macs there's some info here for example:
>>>
>>> https://en.wikipedia.org/wiki/Power_Mac_G4
>>>
>>> And everymac.com also has info on all Macs. There were actually more than one G4
>>> PowerMac with AGP but the other one was informally called gigabit ethernet. So the
>>> model ID is a shorter and better way to clearly identify which hardware is it (and
>>> it's also referenced in the device-tree of these Macs).
>>
>> Are you planning to work on different types of G4 Mac where this could be
>> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of Mac is
>> being emulated, whereas "g4agp" (much in the same way as g3beige) is much more
>> friendlier to people interested in using QEMU for Mac emulation.
>
> This is similar problem as some people like to call Mac OS X versions by number and
> some by big cats names. Personally I prefer version numbers because it's easy to tell
> which is newer or older that way without remembering a nomenclature or having to look
> it up every time. It would be good if others interested in this also shared their
> preference because if it's only us two with different views then it's hard to make a
> decision. I still think machine ID is better also because then these machines would
> be grouped in the -machine help output like the others but as long as we don't have
> other machines that start with a g or other Macs that have some other name it might
> work so I could change the naming if that's all needed for this to get in.
I'd lean towards the g* naming, because not only is it more obvious to less technical
Mac users what is being emulated, it matches the existing precedent set by g3beige.
>>>> Finally can you post links to the device trees that you are using for each of the
>>>> new machine types so that we have a clear reference point for future changes to
>>>> the QEMU Mac machines? Even better include the links in the comments for each
>>>> machine so that the information is easily visible for developers.
>>>
>>> I still have those I've posted over the past 8 years when I made changes to
>>> OpenBIOS to make the device-tree closer to real machine. I've downloaded it back
>>> then, don't know where to find it now but searching for e.g. "PowerMac3,1"
>>> "device-tree" should get some results.
>>
>> Nothing shows up for me, I'm afraid (remember that Google searches are unique to
>> each user). If you want argue for changing the QEMU machines, then we should agree
>> on the reference device model for future changes.
>
> Sigh, maybe search your list archives instead of Googls. Also it's "PowerMac3,1"
> where I've converted the comma to underscre for qemu command line parsing so became
> powermac3_1 not powermac_3_1. Try searching with quotes to reduce the number of false
> results.
>
> - mac99 (via=cuda) does not exist so no real device tree for this needed
>
> - powermac3_1 (currently mac99,via=pmu) I've sent links years ago e.g.:
> https://mail.coreboot.org/pipermail/openbios/2016-February/009145.html
> but you still keep asking
Right, because old documentation like this is slowly disappearing from the internet.
We should consider a patch to add those public links into the source files so there
is a (hopefully) long-term reference to them.
> - powermac7_3 (ppc64 mac99) The expected hardware is listed in a comment in
> mac_newworld.c also it adds a 970fx CPU and according to
> https://en.wikipedia.org/wiki/Power_Mac_G5 PowerMac7,3 was the first version with
> 970fx so I think that was the target for whoever started it back then. These G5 Macs
> are probably still around so you should be able to ask someone to get a device tree
> dump, I've only seen Linux hardware listings:
> https://gist.github.com/tomari/3689297
> https://forum.ubuntu-fr.org/viewtopic.php?id=2026003 (last post)
>
> -powerbook3_2 (mac99,via=pmi-adb) this is rare as Macs with PMU usually have USB and
> not ADB; only the first PowerBooks had an ADB trackpad (but no outside ports AFAIK).
> All other Macs with ADB had CUDA so I'm not even sure we need this option but if we
> want it then the first PowerBooks are candidates, I've picked the lowest number for
> 1st gen Titanium PowerBook from here:
> https://en.wikipedia.org/wiki/PowerBook_G4
> and e.g. these links confirm it had ADB:
> https://forums.freebsd.org/threads/12-powerbook-g4-867mhz-xorg-doesnt-work.37815/
> http://macos9lives.com/smforum/index.php/topic,4781.msg41380.html?PHPSESSID=75b23dcb4c042b51c6dddd311cff2341#msg41380
>
>
> It would be tough to come up with a name for the powerbook3_2 though as these were
> called Early 2001 Titanium PowerBook G4 or code name Mercury but even Mac fanatics
> probably couldn't tell that was a powerbook if you call it g4mercury so I'm open to
> votes on naming but hard to be convinced there's anything simpler and more
> straightforward than using machine id which is usually also listed everywhere for these.
The question really is which OSs use -M mac99,via=cuda and -M mac99,via=pmu-adb, and
what real machines were intended to boot them. Howard, perhaps you have better
knowledge of this?
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-22 22:07 ` BALATON Zoltan
@ 2023-01-23 22:06 ` Mark Cave-Ayland
2023-01-23 23:16 ` Howard Spoelstra
2023-01-24 1:24 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
0 siblings, 2 replies; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-23 22:06 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Howard Spoelstra, qemu-devel, qemu-ppc
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.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-22 22:16 ` BALATON Zoltan
@ 2023-01-23 22:12 ` Mark Cave-Ayland
2023-01-24 0:13 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-01-23 22:12 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc
On 22/01/2023 22:16, BALATON Zoltan wrote:
>> The problem you are ultimately trying to solve though is that OpenBIOS is loading
>> the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the
>> NDRV is loaded only for the QEMU VGA device?
>>
>>> So this patch neither adds new dependency to QEMU nor repends on any change in
>>> OpenBIOS. It just gets rid of passing files via fw_cfg.
>>
>> Unfortunately that still doesn't solve the problem of building a self-contained
>> OpenBIOS ROM, so this patch isn't the right way forward.
>
> It does take a step to make it possible to eventually add a self contained ROM and
> remove the vga.fs from OpenBIOS but it's not doing that fully. It just simplifies
> QEMU and OpenBIOS vga.fs for now and making the ROM also contain the FCode will be a
> further step but we can't get there if you don't allow to make smaller steps or don't
> merge my patches for OpenBIOS which would allow it to run FCode ROMs. If you're
> waiting for all this to be finished I'll give up and it will never be finished. If
> you allow to progress in smaller steps then maybe we'll get there.
You can already add a self-contained rom using the romfile= property, so that's not
preventing you from doing anything though? Even once OpenBIOS can read PCI option
ROMs, the option ROM will still need to contain OpenBIOS's vga.fs as a payload, and
it will still need to be able to inject qemu_vga.ndrv because OpenBIOS cannot have an
external dependency upon QemuMacDrivers.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-23 22:06 ` Mark Cave-Ayland
@ 2023-01-23 23:16 ` Howard Spoelstra
2023-01-24 1:47 ` BALATON Zoltan
2023-11-06 6:45 ` Error detecting linker while compiling qemu-system-ppc on macOS Howard Spoelstra
2023-01-24 1:24 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
1 sibling, 2 replies; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-23 23:16 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: BALATON Zoltan, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 9962 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 12850 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-23 22:12 ` Mark Cave-Ayland
@ 2023-01-24 0:13 ` BALATON Zoltan
2023-02-01 23:23 ` Mark Cave-Ayland
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 0:13 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>> The problem you are ultimately trying to solve though is that OpenBIOS is
>>> loading the NDRV for all VGA PCI devices, so why not just fix
>>> drivers/vga.fs so that the NDRV is loaded only for the QEMU VGA device?
>>>
>>>> So this patch neither adds new dependency to QEMU nor repends on any
>>>> change in OpenBIOS. It just gets rid of passing files via fw_cfg.
>>>
>>> Unfortunately that still doesn't solve the problem of building a
>>> self-contained OpenBIOS ROM, so this patch isn't the right way forward.
>>
>> It does take a step to make it possible to eventually add a self contained
>> ROM and remove the vga.fs from OpenBIOS but it's not doing that fully. It
>> just simplifies QEMU and OpenBIOS vga.fs for now and making the ROM also
>> contain the FCode will be a further step but we can't get there if you
>> don't allow to make smaller steps or don't merge my patches for OpenBIOS
>> which would allow it to run FCode ROMs. If you're waiting for all this to
>> be finished I'll give up and it will never be finished. If you allow to
>> progress in smaller steps then maybe we'll get there.
>
> You can already add a self-contained rom using the romfile= property, so
> that's not preventing you from doing anything though? Even once OpenBIOS can
Except that OpenBIOS will break the device tree by adding the
qemu_vga.ndrv to the video card node so the card rom I pass via romfile
will see it's already there and won't install its owm. Then MacOS will try
to use the wrong driver and it does not work and I spend a lot of time to
find out I also need -prom env vga-ndrv?=false to avoid this problem which
I always forget and somebody trying this for the first time won't even
know.
What's more, all this complication is not needed. With this patch
everything works as before for std VGA as it will have the qemu_vga.ndrv
as its romfile but ati-vga won't so OpenBIOS only installs it for std VGA
without adding anything to OpenBIOS to handle this. Adding a romfile to
ati-vga will work without further hassle and the romfile option can also
be used to replace or disable the qemu_vga.ndrv for std VGA as -device
VGA,romdile="" (or add your FCode in development here). Due to the way
standard VGA works adding -device VGA,romfile= to the command line won't
add a second VGA device just set the option for the default one (actually
it omits the default and adds the specified one but the point is this
just works).
Then we not only not need to add anythig to OpenBIOS but we can drop the
vga-ndrv? option (which does not exist on real machines anyway) and also
all the code in vga.fs to get the driver from fw_cfg so simplifying it
leaving only the code which will eventually need to be part of the FCode
ROM. Once this patch is accepted it fixes the above problem and allows to
simplify OpenBIOS later and when we're there you just have to replace
qemu_vga.ndrv with the version that prepends the FCode from vga.fs before
it so I don't see what's your problem with this patch. Can you give a
reason why it can't be accepted?
> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's
> vga.fs as a payload, and it will still need to be able to inject
> qemu_vga.ndrv because OpenBIOS cannot have an external dependency upon
> QemuMacDrivers.
The way real card ROMs work is that they embed the driver binary and have
some FCode that adds that to the device tree. It should be the same for
QEMU emulated cards so if you say that you want only vga.fs as the card
ROM which then downloads the qemu_vga.ndrv from QEMU that makes no sense
at all. Currently the qemu_vga.ndrv is build from QemuMacDrivers and added
as a binary to QEMU. You can add it as a binary the same way to OpenBIOS
then build the FCOde ROM from vga.fs and qemu_vga.ndrv bin that results in
the FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You just say
this is not possible because you're OK with adding the qemu_vga,ndrv
binary to QEMU but doing the same with OpenBIOS cannot be done?
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs
2023-01-23 21:36 ` Mark Cave-Ayland
@ 2023-01-24 0:36 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 0:36 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
> On 22/01/2023 21:48, BALATON Zoltan wrote:
>> On Sun, 22 Jan 2023, Mark Cave-Ayland wrote:
>>> On 11/01/2023 00:36, BALATON Zoltan wrote:
>>>> On Tue, 10 Jan 2023, Mark Cave-Ayland wrote:
>>>>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>>>> Secondly it's not clear to me why you've chosen names like
>>>>> "powermac_3_1" instead of "g4agp"? Does powermac_3_1 uniquely identify
>>>>> the G4 AGP Sawtooth model? For QEMU it is always best to emulate real
>>>>> machines, and whilst I understand you want to separate out the two
>>>>> versions of the mac99 machine, having "powermac_X_Y" seems less clear to
>>>>> me.
>>>>
>>>> These machine model identifiers are used by Apple to uniquely identify
>>>> (all of) their machines since new-world Macs (even modern iPads and Macs
>>>> have them) so for Mac people this should be clearer than the informal
>>>> names that could get a bit long and confusing as there may be slight
>>>> differences within a family. In any case, qemu-system-ppc -M mac99 is not
>>>> corresponding to any real Mac so I'd like the options which do emulate
>>>> real Macs to be called in a name that show which Mac is that. For the PPC
>>>> Macs there's some info here for example:
>>>>
>>>> https://en.wikipedia.org/wiki/Power_Mac_G4
>>>>
>>>> And everymac.com also has info on all Macs. There were actually more than
>>>> one G4 PowerMac with AGP but the other one was informally called gigabit
>>>> ethernet. So the model ID is a shorter and better way to clearly identify
>>>> which hardware is it (and it's also referenced in the device-tree of
>>>> these Macs).
>>>
>>> Are you planning to work on different types of G4 Mac where this could be
>>> confusing? Even to me "PowerMac 3.1" doesn't really tell me what model of
>>> Mac is being emulated, whereas "g4agp" (much in the same way as g3beige)
>>> is much more friendlier to people interested in using QEMU for Mac
>>> emulation.
>>
>> This is similar problem as some people like to call Mac OS X versions by
>> number and some by big cats names. Personally I prefer version numbers
>> because it's easy to tell which is newer or older that way without
>> remembering a nomenclature or having to look it up every time. It would be
>> good if others interested in this also shared their preference because if
>> it's only us two with different views then it's hard to make a decision. I
>> still think machine ID is better also because then these machines would be
>> grouped in the -machine help output like the others but as long as we don't
>> have other machines that start with a g or other Macs that have some other
>> name it might work so I could change the naming if that's all needed for
>> this to get in.
>
> I'd lean towards the g* naming, because not only is it more obvious to less
> technical Mac users what is being emulated, it matches the existing precedent
> set by g3beige.
The g3beige is not a good example as model ids were introduced with new
world Macs and the beige G3 is one of the last old world ones which had a
numeric ID so we can't give that a name by model ID. All later Macs though
have a model ID which is a short and clear way to idenfify a model. Found
a list here:
https://www.macupgrades.co.uk/store/mac_model_id/
and it even carries on for modern Macs:
https://support.apple.com/en-us/HT201634
and it's listed in System Profiler next to the model name:
https://support.apple.com/en-gb/HT201581
so it should be pretty obvious and familiar to Mac users. So I think
anything else would be more confusing but I don't care that much as long
as we can have a separate name for each machine we emulate. I'll take
whatever names you come up with if that's what it takes for this patch to
get merged. Please tell me what names you want and I'll change it if
nobody else votes fot the names I've proposed.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-23 22:06 ` Mark Cave-Ayland
2023-01-23 23:16 ` Howard Spoelstra
@ 2023-01-24 1:24 ` BALATON Zoltan
1 sibling, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 1:24 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Howard Spoelstra, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-23 23:16 ` Howard Spoelstra
@ 2023-01-24 1:47 ` BALATON Zoltan
2023-01-24 11:24 ` Howard Spoelstra
2023-11-06 6:45 ` Error detecting linker while compiling qemu-system-ppc on macOS Howard Spoelstra
1 sibling, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 1:47 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-24 1:47 ` BALATON Zoltan
@ 2023-01-24 11:24 ` Howard Spoelstra
2023-01-24 14:13 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-24 11:24 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 3172 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4818 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-24 11:24 ` Howard Spoelstra
@ 2023-01-24 14:13 ` BALATON Zoltan
2023-01-24 15:02 ` Howard Spoelstra
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 14:13 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-24 14:13 ` BALATON Zoltan
@ 2023-01-24 15:02 ` Howard Spoelstra
2023-01-24 15:31 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-24 15:02 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 6004 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 8574 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-24 15:02 ` Howard Spoelstra
@ 2023-01-24 15:31 ` BALATON Zoltan
2023-01-26 10:06 ` Howard Spoelstra
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 15:31 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-12 20:22 ` Howard Spoelstra
2023-01-12 23:51 ` BALATON Zoltan
@ 2023-01-24 16:37 ` BALATON Zoltan
1 sibling, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-24 16:37 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
2023-01-05 14:28 ` Philippe Mathieu-Daudé
2023-01-10 22:52 ` Mark Cave-Ayland
@ 2023-01-24 21:05 ` Warner Losh
2 siblings, 0 replies; 64+ messages in thread
From: Warner Losh @ 2023-01-24 21:05 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc, Mark Cave-Ayland
[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]
> 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
>
>
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 874 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-24 15:31 ` BALATON Zoltan
@ 2023-01-26 10:06 ` Howard Spoelstra
2023-01-26 14:16 ` BALATON Zoltan
2023-01-26 20:55 ` BALATON Zoltan
0 siblings, 2 replies; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-26 10:06 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 7869 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 10011 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-26 10:06 ` Howard Spoelstra
@ 2023-01-26 14:16 ` BALATON Zoltan
2023-01-26 20:55 ` BALATON Zoltan
1 sibling, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-26 14:16 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-26 10:06 ` Howard Spoelstra
2023-01-26 14:16 ` BALATON Zoltan
@ 2023-01-26 20:55 ` BALATON Zoltan
2023-01-26 22:48 ` Howard Spoelstra
1 sibling, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-26 20:55 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-26 20:55 ` BALATON Zoltan
@ 2023-01-26 22:48 ` Howard Spoelstra
2023-01-27 0:03 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-26 22:48 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 3295 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 4097 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-26 22:48 ` Howard Spoelstra
@ 2023-01-27 0:03 ` BALATON Zoltan
2023-01-27 2:27 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-27 0:03 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-27 0:03 ` BALATON Zoltan
@ 2023-01-27 2:27 ` BALATON Zoltan
2023-01-27 7:01 ` Howard Spoelstra
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-01-27 2:27 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
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
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option
2023-01-27 2:27 ` BALATON Zoltan
@ 2023-01-27 7:01 ` Howard Spoelstra
0 siblings, 0 replies; 64+ messages in thread
From: Howard Spoelstra @ 2023-01-27 7:01 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel, qemu-ppc
[-- Attachment #1: Type: text/plain, Size: 6470 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 8780 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-01-24 0:13 ` BALATON Zoltan
@ 2023-02-01 23:23 ` Mark Cave-Ayland
2023-02-02 0:46 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-02-01 23:23 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: qemu-devel, qemu-ppc
On 24/01/2023 00:13, BALATON Zoltan wrote:
> On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
>> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>>> The problem you are ultimately trying to solve though is that OpenBIOS is loading
>>>> the NDRV for all VGA PCI devices, so why not just fix drivers/vga.fs so that the
>>>> NDRV is loaded only for the QEMU VGA device?
>>>>
>>>>> So this patch neither adds new dependency to QEMU nor repends on any change in
>>>>> OpenBIOS. It just gets rid of passing files via fw_cfg.
>>>>
>>>> Unfortunately that still doesn't solve the problem of building a self-contained
>>>> OpenBIOS ROM, so this patch isn't the right way forward.
>>>
>>> It does take a step to make it possible to eventually add a self contained ROM and
>>> remove the vga.fs from OpenBIOS but it's not doing that fully. It just simplifies
>>> QEMU and OpenBIOS vga.fs for now and making the ROM also contain the FCode will be
>>> a further step but we can't get there if you don't allow to make smaller steps or
>>> don't merge my patches for OpenBIOS which would allow it to run FCode ROMs. If
>>> you're waiting for all this to be finished I'll give up and it will never be
>>> finished. If you allow to progress in smaller steps then maybe we'll get there.
>>
>> You can already add a self-contained rom using the romfile= property, so that's not
>> preventing you from doing anything though? Even once OpenBIOS can
>
> Except that OpenBIOS will break the device tree by adding the qemu_vga.ndrv to the
> video card node so the card rom I pass via romfile will see it's already there and
> won't install its owm. Then MacOS will try to use the wrong driver and it does not
> work and I spend a lot of time to find out I also need -prom env vga-ndrv?=false to
> avoid this problem which I always forget and somebody trying this for the first time
> won't even know.
>
> What's more, all this complication is not needed. With this patch everything works as
> before for std VGA as it will have the qemu_vga.ndrv as its romfile but ati-vga won't
> so OpenBIOS only installs it for std VGA without adding anything to OpenBIOS to
> handle this. Adding a romfile to ati-vga will work without further hassle and the
> romfile option can also be used to replace or disable the qemu_vga.ndrv for std VGA
> as -device VGA,romdile="" (or add your FCode in development here). Due to the way
> standard VGA works adding -device VGA,romfile= to the command line won't add a second
> VGA device just set the option for the default one (actually it omits the default and
> adds the specified one but the point is this just works).
>
> Then we not only not need to add anythig to OpenBIOS but we can drop the vga-ndrv?
> option (which does not exist on real machines anyway) and also all the code in vga.fs
> to get the driver from fw_cfg so simplifying it leaving only the code which will
> eventually need to be part of the FCode ROM. Once this patch is accepted it fixes the
> above problem and allows to simplify OpenBIOS later and when we're there you just
> have to replace qemu_vga.ndrv with the version that prepends the FCode from vga.fs
> before it so I don't see what's your problem with this patch. Can you give a reason
> why it can't be accepted?
It doesn't work this way though: once the FCode ROM is working it also generates the
QEMU,VGA device tree node, which means that -device VGA,romfile="" will not only
disable qemu_vga.ndrv, but also leave a device node missing the properties required
for the guest to correctly identify the VGA adapter.
As I already mentioned, this is the wrong approach and what is needed is to fix
vga.fs in OpenBIOS so that the NDRV is only loaded for the QEMU,VGA device.
>> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's vga.fs
>> as a payload, and it will still need to be able to inject qemu_vga.ndrv because
>> OpenBIOS cannot have an external dependency upon QemuMacDrivers.
>
> The way real card ROMs work is that they embed the driver binary and have some FCode
> that adds that to the device tree. It should be the same for QEMU emulated cards so
> if you say that you want only vga.fs as the card ROM which then downloads the
> qemu_vga.ndrv from QEMU that makes no sense at all. Currently the qemu_vga.ndrv is
> build from QemuMacDrivers and added as a binary to QEMU. You can add it as a binary
> the same way to OpenBIOS then build the FCOde ROM from vga.fs and qemu_vga.ndrv bin
> that results in the FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You
> just say this is not possible because you're OK with adding the qemu_vga,ndrv binary
> to QEMU but doing the same with OpenBIOS cannot be done?
What you're suggesting doesn't make any sense, as all you're doing is moving the
binary from QEMU where there is already precedent for distributing binary ROMs to
OpenBIOS where it becomes a build dependency that cannot be built outside of a very
specific guest environment.
I should also add that it wasn't me who designed and implemented the existing scheme
for keeping the qemu_vga.ndrv binary in QEMU, it was Ben - and his approach still
seems to be the best solution in my opinion.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 0/7] Misc ppc/mac machines clean up
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
` (6 preceding siblings ...)
2023-01-04 21:59 ` [PATCH v7 7/7] mac_newworld: Document deprecation BALATON Zoltan
@ 2023-02-01 23:31 ` Mark Cave-Ayland
2023-02-01 23:59 ` BALATON Zoltan
7 siblings, 1 reply; 64+ messages in thread
From: Mark Cave-Ayland @ 2023-02-01 23:31 UTC (permalink / raw)
To: BALATON Zoltan, qemu-devel, qemu-ppc
On 04/01/2023 21:59, BALATON Zoltan wrote:
> This is the remainder of the series that were postponed to after the
> freeze the last time I've tried to submit them with some new patches
> I did meanwhile.
>
> BALATON Zoltan (7):
> input/adb: Only include header where needed
> mac_{old,new}world: Use local variable instead of qdev_get_machine()
> mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
> mac_newworld: Add machine types for different mac99 configs
> mac_newworld: Deprecate mac99 with G5 CPU
> mac_newworld: Deprecate mac99 "via" option
> mac_newworld: Document deprecation
>
> docs/about/deprecated.rst | 7 ++
> docs/system/ppc/powermac.rst | 12 ++--
> hw/misc/macio/cuda.c | 2 -
> hw/misc/macio/pmu.c | 3 -
> hw/misc/mos6522.c | 1 -
> hw/ppc/mac_newworld.c | 130 +++++++++++++++++++++++++++++++----
> hw/ppc/mac_oldworld.c | 21 ++----
> include/hw/misc/mac_via.h | 1 +
> include/hw/misc/macio/cuda.h | 1 +
> include/hw/misc/macio/pmu.h | 1 +
> include/hw/misc/mos6522.h | 3 +-
> 11 files changed, 142 insertions(+), 40 deletions(-)
I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the right
solution to the problem, and the discussion as to how the New World machines should
be organised in future for patches 4 to 7 still hasn't been clarified.
ATB,
Mark.
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 0/7] Misc ppc/mac machines clean up
2023-02-01 23:31 ` [PATCH v7 0/7] Misc ppc/mac machines clean up Mark Cave-Ayland
@ 2023-02-01 23:59 ` BALATON Zoltan
2023-02-07 16:50 ` BALATON Zoltan
0 siblings, 1 reply; 64+ messages in thread
From: BALATON Zoltan @ 2023-02-01 23:59 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
> On 04/01/2023 21:59, BALATON Zoltan wrote:
>> This is the remainder of the series that were postponed to after the
>> freeze the last time I've tried to submit them with some new patches
>> I did meanwhile.
>>
>> BALATON Zoltan (7):
>> input/adb: Only include header where needed
>> mac_{old,new}world: Use local variable instead of qdev_get_machine()
>> mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
>> mac_newworld: Add machine types for different mac99 configs
>> mac_newworld: Deprecate mac99 with G5 CPU
>> mac_newworld: Deprecate mac99 "via" option
>> mac_newworld: Document deprecation
>>
>> docs/about/deprecated.rst | 7 ++
>> docs/system/ppc/powermac.rst | 12 ++--
>> hw/misc/macio/cuda.c | 2 -
>> hw/misc/macio/pmu.c | 3 -
>> hw/misc/mos6522.c | 1 -
>> hw/ppc/mac_newworld.c | 130 +++++++++++++++++++++++++++++++----
>> hw/ppc/mac_oldworld.c | 21 ++----
>> include/hw/misc/mac_via.h | 1 +
>> include/hw/misc/macio/cuda.h | 1 +
>> include/hw/misc/macio/pmu.h | 1 +
>> include/hw/misc/mos6522.h | 3 +-
>> 11 files changed, 142 insertions(+), 40 deletions(-)
>
> I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the
> right solution to the problem, and the discussion as to how the New World
> machines should be organised in future for patches 4 to 7 still hasn't been
> clarified.
Thanks, let's come back to patch 3 in the other thread. As for 4-7 the
discussion seems to have ended and the result was that nobody really cares
besides you and me. So make a suggestion for names instead of the machine
id based ones I came up with and I'll change it to use those names.
Whatever we call these is still better than what we have currently so as
long as I can get PowerMac3,1 and PowerMac7,2 with a simple -machine
option without getting them confused in qemu-system-ppc64 I'd go for that.
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
2023-02-01 23:23 ` Mark Cave-Ayland
@ 2023-02-02 0:46 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-02-02 0:46 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
> On 24/01/2023 00:13, BALATON Zoltan wrote:
>> On Mon, 23 Jan 2023, Mark Cave-Ayland wrote:
>>> On 22/01/2023 22:16, BALATON Zoltan wrote:
>>>>> The problem you are ultimately trying to solve though is that OpenBIOS
>>>>> is loading the NDRV for all VGA PCI devices, so why not just fix
>>>>> drivers/vga.fs so that the NDRV is loaded only for the QEMU VGA device?
>>>>>
>>>>>> So this patch neither adds new dependency to QEMU nor repends on any
>>>>>> change in OpenBIOS. It just gets rid of passing files via fw_cfg.
>>>>>
>>>>> Unfortunately that still doesn't solve the problem of building a
>>>>> self-contained OpenBIOS ROM, so this patch isn't the right way forward.
>>>>
>>>> It does take a step to make it possible to eventually add a self
>>>> contained ROM and remove the vga.fs from OpenBIOS but it's not doing that
>>>> fully. It just simplifies QEMU and OpenBIOS vga.fs for now and making the
>>>> ROM also contain the FCode will be a further step but we can't get there
>>>> if you don't allow to make smaller steps or don't merge my patches for
>>>> OpenBIOS which would allow it to run FCode ROMs. If you're waiting for
>>>> all this to be finished I'll give up and it will never be finished. If
>>>> you allow to progress in smaller steps then maybe we'll get there.
>>>
>>> You can already add a self-contained rom using the romfile= property, so
>>> that's not preventing you from doing anything though? Even once OpenBIOS
>>> can
>>
>> Except that OpenBIOS will break the device tree by adding the qemu_vga.ndrv
>> to the video card node so the card rom I pass via romfile will see it's
>> already there and won't install its owm. Then MacOS will try to use the
>> wrong driver and it does not work and I spend a lot of time to find out I
>> also need -prom env vga-ndrv?=false to avoid this problem which I always
>> forget and somebody trying this for the first time won't even know.
>>
>> What's more, all this complication is not needed. With this patch
>> everything works as before for std VGA as it will have the qemu_vga.ndrv as
>> its romfile but ati-vga won't so OpenBIOS only installs it for std VGA
>> without adding anything to OpenBIOS to handle this. Adding a romfile to
>> ati-vga will work without further hassle and the romfile option can also be
>> used to replace or disable the qemu_vga.ndrv for std VGA as -device
>> VGA,romdile="" (or add your FCode in development here). Due to the way
>> standard VGA works adding -device VGA,romfile= to the command line won't
>> add a second VGA device just set the option for the default one (actually
>> it omits the default and adds the specified one but the point is this just
>> works).
>>
>> Then we not only not need to add anythig to OpenBIOS but we can drop the
>> vga-ndrv? option (which does not exist on real machines anyway) and also
>> all the code in vga.fs to get the driver from fw_cfg so simplifying it
>> leaving only the code which will eventually need to be part of the FCode
>> ROM. Once this patch is accepted it fixes the above problem and allows to
>> simplify OpenBIOS later and when we're there you just have to replace
>> qemu_vga.ndrv with the version that prepends the FCode from vga.fs before
>> it so I don't see what's your problem with this patch. Can you give a
>> reason why it can't be accepted?
>
> It doesn't work this way though: once the FCode ROM is working it also
> generates the QEMU,VGA device tree node, which means that -device
> VGA,romfile="" will not only disable qemu_vga.ndrv, but also leave a device
> node missing the properties required for the guest to correctly identify the
> VGA adapter.
Under what circumstances does it make sense to not have the ndrv in the
device tree when using vga.fs or a ROM built from that later?
> As I already mentioned, this is the wrong approach and what is needed is to
> fix vga.fs in OpenBIOS so that the NDRV is only loaded for the QEMU,VGA
> device.
Then please do that as it's your code and I don't want to find out how to
change the forth in vga.fs to do this.
>>> read PCI option ROMs, the option ROM will still need to contain OpenBIOS's
>>> vga.fs as a payload, and it will still need to be able to inject
>>> qemu_vga.ndrv because OpenBIOS cannot have an external dependency upon
>>> QemuMacDrivers.
>>
>> The way real card ROMs work is that they embed the driver binary and have
>> some FCode that adds that to the device tree. It should be the same for
>> QEMU emulated cards so if you say that you want only vga.fs as the card ROM
>> which then downloads the qemu_vga.ndrv from QEMU that makes no sense at
>> all. Currently the qemu_vga.ndrv is build from QemuMacDrivers and added as
>> a binary to QEMU. You can add it as a binary the same way to OpenBIOS then
>> build the FCOde ROM from vga.fs and qemu_vga.ndrv bin that results in the
>> FCode ROM that will replace qemu_vga.ndrv binaty in QEMU. You just say this
>> is not possible because you're OK with adding the qemu_vga,ndrv binary to
>> QEMU but doing the same with OpenBIOS cannot be done?
>
> What you're suggesting doesn't make any sense, as all you're doing is moving
> the binary from QEMU where there is already precedent for distributing binary
> ROMs to OpenBIOS where it becomes a build dependency that cannot be built
> outside of a very specific guest environment.
>
> I should also add that it wasn't me who designed and implemented the existing
> scheme for keeping the qemu_vga.ndrv binary in QEMU, it was Ben - and his
> approach still seems to be the best solution in my opinion.
Since I can't convince you I'll leave this for now but it would help if
you could come up with an alternative patch at least solving the problem
of adding the ndrv to vga devices it does not work with. I like the
romfile="" option also because this is needed for other firmwares with
ati-vga that have BIOS emulator that can't run the default vgabios from
QEMU because it contains i386 opcodes that those firmwares' x86 emulators
don't know about. So I'm already listing that option for ati-vga for
sam460ex and pegasos2 in user docs and if the same worked for
mac99,via=pmu that would be simpler for users (and for me always
forgetting about the option to prevent ndrv loading as I don't use it very
often).
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH v7 0/7] Misc ppc/mac machines clean up
2023-02-01 23:59 ` BALATON Zoltan
@ 2023-02-07 16:50 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-02-07 16:50 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: qemu-devel, qemu-ppc
On Thu, 2 Feb 2023, BALATON Zoltan wrote:
> On Wed, 1 Feb 2023, Mark Cave-Ayland wrote:
>> On 04/01/2023 21:59, BALATON Zoltan wrote:
>>> This is the remainder of the series that were postponed to after the
>>> freeze the last time I've tried to submit them with some new patches
>>> I did meanwhile.
>>>
>>> BALATON Zoltan (7):
>>> input/adb: Only include header where needed
>>> mac_{old,new}world: Use local variable instead of qdev_get_machine()
>>> mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg
>>> mac_newworld: Add machine types for different mac99 configs
>>> mac_newworld: Deprecate mac99 with G5 CPU
>>> mac_newworld: Deprecate mac99 "via" option
>>> mac_newworld: Document deprecation
>>>
>>> docs/about/deprecated.rst | 7 ++
>>> docs/system/ppc/powermac.rst | 12 ++--
>>> hw/misc/macio/cuda.c | 2 -
>>> hw/misc/macio/pmu.c | 3 -
>>> hw/misc/mos6522.c | 1 -
>>> hw/ppc/mac_newworld.c | 130 +++++++++++++++++++++++++++++++----
>>> hw/ppc/mac_oldworld.c | 21 ++----
>>> include/hw/misc/mac_via.h | 1 +
>>> include/hw/misc/macio/cuda.h | 1 +
>>> include/hw/misc/macio/pmu.h | 1 +
>>> include/hw/misc/mos6522.h | 3 +-
>>> 11 files changed, 142 insertions(+), 40 deletions(-)
>>
>> I've applied patches 1 and 2 to my qemu-macppc branch. Patch 3 isn't the
>> right solution to the problem, and the discussion as to how the New World
>> machines should be organised in future for patches 4 to 7 still hasn't been
>> clarified.
>
> Thanks, let's come back to patch 3 in the other thread. As for 4-7 the
> discussion seems to have ended and the result was that nobody really cares
> besides you and me. So make a suggestion for names instead of the machine id
> based ones I came up with and I'll change it to use those names. Whatever we
> call these is still better than what we have currently so as long as I can
> get PowerMac3,1 and PowerMac7,2 with a simple -machine option without getting
> them confused in qemu-system-ppc64 I'd go for that.
Thank you for taking care of these, now only the last patches are not yet
merged. We can postpone the NDRV patch for later but I'd appreciate if you
could make an alternative fix in OpenBIOS. I'd still want to resolve the
mac99 machine though and add new machine names and start deprecation now.
I'm waiting for your suggestion on names for these machines and preferred
partitioning of the changes in patches so I can change and resubmit these.
I'd like this to not miss the freeze which may seem far ahead but at the
speed these are reviewed and merged I wanted to get over it as soon as
possible. (Othersise this would be the second time these miss a freeze.)
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 64+ messages in thread
* Error detecting linker while compiling qemu-system-ppc on macOS
2023-01-23 23:16 ` Howard Spoelstra
2023-01-24 1:47 ` BALATON Zoltan
@ 2023-11-06 6:45 ` Howard Spoelstra
2023-11-06 10:37 ` BALATON Zoltan
1 sibling, 1 reply; 64+ messages in thread
From: Howard Spoelstra @ 2023-11-06 6:45 UTC (permalink / raw)
To: qemu-devel qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2221 bytes --]
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)
[-- Attachment #2: Type: text/html, Size: 2654 bytes --]
^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: Error detecting linker while compiling qemu-system-ppc on macOS
2023-11-06 6:45 ` Error detecting linker while compiling qemu-system-ppc on macOS Howard Spoelstra
@ 2023-11-06 10:37 ` BALATON Zoltan
0 siblings, 0 replies; 64+ messages in thread
From: BALATON Zoltan @ 2023-11-06 10:37 UTC (permalink / raw)
To: Howard Spoelstra; +Cc: qemu-devel qemu-devel, Rene Engel, Paolo Bonzini
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)
>
^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2023-11-06 10:37 UTC | newest]
Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-04 21:59 [PATCH v7 0/7] Misc ppc/mac machines clean up BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 1/7] input/adb: Only include header where needed BALATON Zoltan
2023-01-05 13:45 ` Philippe Mathieu-Daudé
2023-01-10 22:12 ` Mark Cave-Ayland
2023-01-04 21:59 ` [PATCH v7 2/7] mac_{old,new}world: Use local variable instead of qdev_get_machine() BALATON Zoltan
2023-01-05 7:23 ` [PATCH v7 2/7] mac_{old, new}world: " Philippe Mathieu-Daudé
2023-01-05 17:15 ` [PATCH v7 2/7] mac_{old,new}world: " Bernhard Beschow
2023-01-10 22:13 ` [PATCH v7 2/7] mac_{old, new}world: " Mark Cave-Ayland
2023-01-04 21:59 ` [PATCH v7 3/7] mac_{old,new}world: Pass MacOS VGA NDRV in card ROM instead of fw_cfg BALATON Zoltan
2023-01-10 22:25 ` Mark Cave-Ayland
2023-01-11 0:54 ` BALATON Zoltan
2023-01-22 17:54 ` Mark Cave-Ayland
2023-01-22 22:16 ` BALATON Zoltan
2023-01-23 22:12 ` Mark Cave-Ayland
2023-01-24 0:13 ` BALATON Zoltan
2023-02-01 23:23 ` Mark Cave-Ayland
2023-02-02 0:46 ` BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 4/7] mac_newworld: Add machine types for different mac99 configs BALATON Zoltan
2023-01-10 22:46 ` Mark Cave-Ayland
2023-01-11 0:36 ` BALATON Zoltan
2023-01-22 17:39 ` Mark Cave-Ayland
2023-01-22 21:48 ` BALATON Zoltan
2023-01-22 22:18 ` Josh Juran
2023-01-23 21:36 ` Mark Cave-Ayland
2023-01-24 0:36 ` BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 5/7] mac_newworld: Deprecate mac99 with G5 CPU BALATON Zoltan
2023-01-05 7:28 ` Philippe Mathieu-Daudé
2023-01-05 11:58 ` BALATON Zoltan
2023-01-04 21:59 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
2023-01-05 14:28 ` Philippe Mathieu-Daudé
2023-01-05 16:06 ` BALATON Zoltan
2023-01-10 22:52 ` Mark Cave-Ayland
2023-01-11 0:12 ` BALATON Zoltan
2023-01-12 20:22 ` Howard Spoelstra
2023-01-12 23:51 ` BALATON Zoltan
2023-01-13 7:26 ` Howard Spoelstra
2023-01-13 13:32 ` BALATON Zoltan
2023-01-22 18:06 ` Mark Cave-Ayland
2023-01-22 22:07 ` BALATON Zoltan
2023-01-23 22:06 ` Mark Cave-Ayland
2023-01-23 23:16 ` Howard Spoelstra
2023-01-24 1:47 ` BALATON Zoltan
2023-01-24 11:24 ` Howard Spoelstra
2023-01-24 14:13 ` BALATON Zoltan
2023-01-24 15:02 ` Howard Spoelstra
2023-01-24 15:31 ` BALATON Zoltan
2023-01-26 10:06 ` Howard Spoelstra
2023-01-26 14:16 ` BALATON Zoltan
2023-01-26 20:55 ` BALATON Zoltan
2023-01-26 22:48 ` Howard Spoelstra
2023-01-27 0:03 ` BALATON Zoltan
2023-01-27 2:27 ` BALATON Zoltan
2023-01-27 7:01 ` Howard Spoelstra
2023-11-06 6:45 ` Error detecting linker while compiling qemu-system-ppc on macOS Howard Spoelstra
2023-11-06 10:37 ` BALATON Zoltan
2023-01-24 1:24 ` [PATCH v7 6/7] mac_newworld: Deprecate mac99 "via" option BALATON Zoltan
2023-01-24 16:37 ` BALATON Zoltan
2023-01-24 21:05 ` Warner Losh
2023-01-04 21:59 ` [PATCH v7 7/7] mac_newworld: Document deprecation BALATON Zoltan
2023-01-05 7:31 ` Philippe Mathieu-Daudé
2023-01-05 12:02 ` BALATON Zoltan
2023-02-01 23:31 ` [PATCH v7 0/7] Misc ppc/mac machines clean up Mark Cave-Ayland
2023-02-01 23:59 ` BALATON Zoltan
2023-02-07 16:50 ` BALATON Zoltan
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.