Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk CC: Alexander Graf agraf@csgraf.de --- openbios-devel/arch/ppc/qemu/init.c | 10 +++++++++- openbios-devel/forth/admin/nvram.fs | 1 + 2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/openbios-devel/arch/ppc/qemu/init.c b/openbios-devel/arch/ppc/qemu/init.c index fcbd04d..60a5303 100644 --- a/openbios-devel/arch/ppc/qemu/init.c +++ b/openbios-devel/arch/ppc/qemu/init.c @@ -258,7 +258,15 @@ cpu_generic_init(const struct cpudef *cpu) push_str("icache-block-size"); fword("property");
- PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ)); + /* Some OS (early Darwin) require a value of timebase-frequency + that closely matches real hardware in order to prevent a + timing loop hang. Use CLOCKFREQ / 16 as a good approximation. */ + fword("force-real-tbfreq?"); + if (POP()) { + PUSH(fw_cfg_read_i32(FW_CFG_PPC_CLOCKFREQ) / 0x10); + } else { + PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ)); + } fword("encode-int"); push_str("timebase-frequency"); fword("property"); diff --git a/openbios-devel/forth/admin/nvram.fs b/openbios-devel/forth/admin/nvram.fs index 20f6462..cf3e905 100644 --- a/openbios-devel/forth/admin/nvram.fs +++ b/openbios-devel/forth/admin/nvram.fs @@ -336,6 +336,7 @@ s" -1" s" real-size" int-config s" 4000000" s" load-base" int-config s" -1" s" virt-base" int-config s" -1" s" virt-size" int-config +s" false" s" force-real-tbfreq?" bool-config [THEN]
[IFDEF] CONFIG_X86
Am 29.06.2013 um 13:27 schrieb Mark Cave-Ayland mark.cave-ayland@ilande.co.uk:
Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk CC: Alexander Graf agraf@csgraf.de
I think I'd prefer a QEMU option to modify the timebase for real. That would change the emulated frequency as well as the one it exposes to OpenBIOS.
Alex
openbios-devel/arch/ppc/qemu/init.c | 10 +++++++++- openbios-devel/forth/admin/nvram.fs | 1 + 2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/openbios-devel/arch/ppc/qemu/init.c b/openbios-devel/arch/ppc/qemu/init.c index fcbd04d..60a5303 100644 --- a/openbios-devel/arch/ppc/qemu/init.c +++ b/openbios-devel/arch/ppc/qemu/init.c @@ -258,7 +258,15 @@ cpu_generic_init(const struct cpudef *cpu) push_str("icache-block-size"); fword("property");
- PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
- /* Some OS (early Darwin) require a value of timebase-frequency
that closely matches real hardware in order to prevent atiming loop hang. Use CLOCKFREQ / 16 as a good approximation. */- fword("force-real-tbfreq?");
- if (POP()) {
PUSH(fw_cfg_read_i32(FW_CFG_PPC_CLOCKFREQ) / 0x10);- } else {
PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));- } fword("encode-int"); push_str("timebase-frequency"); fword("property");
diff --git a/openbios-devel/forth/admin/nvram.fs b/openbios-devel/forth/admin/nvram.fs index 20f6462..cf3e905 100644 --- a/openbios-devel/forth/admin/nvram.fs +++ b/openbios-devel/forth/admin/nvram.fs @@ -336,6 +336,7 @@ s" -1" s" real-size" int-config s" 4000000" s" load-base" int-config s" -1" s" virt-base" int-config s" -1" s" virt-size" int-config +s" false" s" force-real-tbfreq?" bool-config [THEN]
[IFDEF] CONFIG_X86
1.7.10.4
On 29/06/13 14:04, Alexander Graf wrote:
Am 29.06.2013 um 13:27 schrieb Mark Cave-Aylandmark.cave-ayland@ilande.co.uk:
Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Aylandmark.cave-ayland@ilande.co.uk CC: Alexander Grafagraf@csgraf.de
I think I'd prefer a QEMU option to modify the timebase for real. That would change the emulated frequency as well as the one it exposes to OpenBIOS.
Hmmm okay - that's something that's reasonably beyond my level of QEMU knowledge to do at the moment :/ Although I have seen that some patches for throttling QEMU in the past have been rejected...
ATB,
Mark.
On 29.06.2013, at 15:14, Mark Cave-Ayland wrote:
On 29/06/13 14:04, Alexander Graf wrote:
Am 29.06.2013 um 13:27 schrieb Mark Cave-Aylandmark.cave-ayland@ilande.co.uk:
Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Aylandmark.cave-ayland@ilande.co.uk CC: Alexander Grafagraf@csgraf.de
I think I'd prefer a QEMU option to modify the timebase for real. That would change the emulated frequency as well as the one it exposes to OpenBIOS.
Hmmm okay - that's something that's reasonably beyond my level of QEMU knowledge to do at the moment :/ Although I have seen that some patches for throttling QEMU in the past have been rejected...
The throttling is already in place :). Check out cpu_ppc_tb_init() in hw/ppc/ppc.c. Actually it almost looks like the only thing we're doing wrong is the exported tbfreq value...
hw/ppc/mac_oldworld.c: cpu_ppc_tb_init(env, 16600000UL); hw/ppc/mac_newworld.c: cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL);
Alex
On Jun 29, 2013, at 7:27 AM, Mark Cave-Ayland wrote:
Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Ayland mark.cave-ayland@ilande.co.uk CC: Alexander Graf agraf@csgraf.de
openbios-devel/arch/ppc/qemu/init.c | 10 +++++++++- openbios-devel/forth/admin/nvram.fs | 1 + 2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/openbios-devel/arch/ppc/qemu/init.c b/openbios-devel/arch/ppc/qemu/init.c index fcbd04d..60a5303 100644 --- a/openbios-devel/arch/ppc/qemu/init.c +++ b/openbios-devel/arch/ppc/qemu/init.c @@ -258,7 +258,15 @@ cpu_generic_init(const struct cpudef *cpu) push_str("icache-block-size"); fword("property");
- PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));
- /* Some OS (early Darwin) require a value of timebase-frequency
that closely matches real hardware in order to prevent atiming loop hang. Use CLOCKFREQ / 16 as a good approximation. */- fword("force-real-tbfreq?");
- if (POP()) {
PUSH(fw_cfg_read_i32(FW_CFG_PPC_CLOCKFREQ) / 0x10);- } else {
PUSH(fw_cfg_read_i32(FW_CFG_PPC_TBFREQ));- } fword("encode-int"); push_str("timebase-frequency"); fword("property");
diff --git a/openbios-devel/forth/admin/nvram.fs b/openbios-devel/forth/admin/nvram.fs index 20f6462..cf3e905 100644 --- a/openbios-devel/forth/admin/nvram.fs +++ b/openbios-devel/forth/admin/nvram.fs @@ -336,6 +336,7 @@ s" -1" s" real-size" int-config s" 4000000" s" load-base" int-config s" -1" s" virt-base" int-config s" -1" s" virt-size" int-config +s" false" s" force-real-tbfreq?" bool-config [THEN]
[IFDEF] CONFIG_X86
1.7.10.4
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
I thought the emulation was better than a 1 to 16 ration.
We should do a timing loop that more accurately calculates the emulated processor's speed. The calculations would be pretty simple. Other G3 computers can be used to help benchmark this loop.
This is my algorithm
declare counter variable set counter variable to 0 loop for 10,000,000 cycles { counter = counter + 1 }
Then after we have the count, we compare it with values from real G3 computers...
real-G3-266-count-value / counter = calculated-clock-ratio
timebase-frequency = 266mhz * calculated-clock-ratio.
I do have a real Beige G3 that I can use to help with the algorithm.
-
Alexander Graf -
Mark Cave-Ayland -
Programmingkid