[OpenBIOS] [PATCH] PPC: Add "real" CPU timebase-frequency override NVRAM variable

[Programmingkid]

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 at ilande.co.uk>
> CC: Alexander Graf <agraf at 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
> -- 
> 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.