[Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Greg Ungerer]

The shipping default setting for the Freescale M5208EVB board is to run
the CPU at 166MHz. The current qemu emulation code for this board is
defaulting to 66MHz. This results in time appearing to run way to slowly.
So a "sleep 5" in a standard ColdFire Linux build takes almost 15
seconds in real time to actually complete.

Change the hard coded default to match the default hardware setting.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
---
 hw/m68k/mcf5208.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
index 9240ebf..2d0b464 100644
--- a/hw/m68k/mcf5208.c
+++ b/hw/m68k/mcf5208.c
@@ -21,7 +21,7 @@
 #include "elf.h"
 #include "exec/address-spaces.h"
 
-#define SYS_FREQ 66000000
+#define SYS_FREQ 166000000
 
 #define PCSR_EN         0x0001
 #define PCSR_RLD        0x0002
-- 
1.9.1

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Thomas Huth]

On 27.09.2016 03:29, Greg Ungerer wrote:
> The shipping default setting for the Freescale M5208EVB board is to run
> the CPU at 166MHz. The current qemu emulation code for this board is
> defaulting to 66MHz. This results in time appearing to run way to slowly.
> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
> seconds in real time to actually complete.
> 
> Change the hard coded default to match the default hardware setting.
> 
> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
> ---
>  hw/m68k/mcf5208.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
> index 9240ebf..2d0b464 100644
> --- a/hw/m68k/mcf5208.c
> +++ b/hw/m68k/mcf5208.c
> @@ -21,7 +21,7 @@
>  #include "elf.h"
>  #include "exec/address-spaces.h"
>  
> -#define SYS_FREQ 66000000
> +#define SYS_FREQ 166000000

Good catch. But actually, the M5208EVB User's Manual talks about 166.67
MHz, so while you're at it, maybe you should change it to 166666666 instead?

 Thomas

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Laurent Vivier]

Le 27/09/2016 à 09:33, Thomas Huth a écrit :
> On 27.09.2016 03:29, Greg Ungerer wrote:
>> The shipping default setting for the Freescale M5208EVB board is to run
>> the CPU at 166MHz. The current qemu emulation code for this board is
>> defaulting to 66MHz. This results in time appearing to run way to slowly.
>> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
>> seconds in real time to actually complete.
>>
>> Change the hard coded default to match the default hardware setting.
>>
>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>> ---
>>  hw/m68k/mcf5208.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>> index 9240ebf..2d0b464 100644
>> --- a/hw/m68k/mcf5208.c
>> +++ b/hw/m68k/mcf5208.c
>> @@ -21,7 +21,7 @@
>>  #include "elf.h"
>>  #include "exec/address-spaces.h"
>>  
>> -#define SYS_FREQ 66000000
>> +#define SYS_FREQ 166000000
> 
> Good catch. But actually, the M5208EVB User's Manual talks about 166.67
> MHz, so while you're at it, maybe you should change it to 166666666 instead?

In this case, it should be better to use a period of 6000000 ns (and
ptimer_set_period() instead of ptimer_set_freq()).

Laurent

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Greg Ungerer]

Hi Thomas,

On 27/09/16 17:33, Thomas Huth wrote:
> On 27.09.2016 03:29, Greg Ungerer wrote:
>> The shipping default setting for the Freescale M5208EVB board is to run
>> the CPU at 166MHz. The current qemu emulation code for this board is
>> defaulting to 66MHz. This results in time appearing to run way to slowly.
>> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
>> seconds in real time to actually complete.
>>
>> Change the hard coded default to match the default hardware setting.
>>
>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>> ---
>>  hw/m68k/mcf5208.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>> index 9240ebf..2d0b464 100644
>> --- a/hw/m68k/mcf5208.c
>> +++ b/hw/m68k/mcf5208.c
>> @@ -21,7 +21,7 @@
>>  #include "elf.h"
>>  #include "exec/address-spaces.h"
>>
>> -#define SYS_FREQ 66000000
>> +#define SYS_FREQ 166000000
>
> Good catch. But actually, the M5208EVB User's Manual talks about 166.67
> MHz, so while you're at it, maybe you should change it to 166666666 instead?

Yep, it sure does. I will make that change.

Thanks
Greg

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Greg Ungerer]

Hi Laurent,

On 27/09/16 18:11, Laurent Vivier wrote:
> Le 27/09/2016 à 09:33, Thomas Huth a écrit :
>> On 27.09.2016 03:29, Greg Ungerer wrote:
>>> The shipping default setting for the Freescale M5208EVB board is to run
>>> the CPU at 166MHz. The current qemu emulation code for this board is
>>> defaulting to 66MHz. This results in time appearing to run way to slowly.
>>> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
>>> seconds in real time to actually complete.
>>>
>>> Change the hard coded default to match the default hardware setting.
>>>
>>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>>> ---
>>>  hw/m68k/mcf5208.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>>> index 9240ebf..2d0b464 100644
>>> --- a/hw/m68k/mcf5208.c
>>> +++ b/hw/m68k/mcf5208.c
>>> @@ -21,7 +21,7 @@
>>>  #include "elf.h"
>>>  #include "exec/address-spaces.h"
>>>
>>> -#define SYS_FREQ 66000000
>>> +#define SYS_FREQ 166000000
>>
>> Good catch. But actually, the M5208EVB User's Manual talks about 166.67
>> MHz, so while you're at it, maybe you should change it to 166666666 instead?
>
> In this case, it should be better to use a period of 6000000 ns (and
> ptimer_set_period() instead of ptimer_set_freq()).

Why is that better in this case?
All the documentation lists it as 166.67MHz, even on the PCB.
Isn't it clearer to define it based on the actual value documented?

Regards
Greg

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Laurent Vivier]

Le 27/09/2016 à 15:22, Greg Ungerer a écrit :
> Hi Laurent,
> 
> On 27/09/16 18:11, Laurent Vivier wrote:
>> Le 27/09/2016 à 09:33, Thomas Huth a écrit :
>>> On 27.09.2016 03:29, Greg Ungerer wrote:
>>>> The shipping default setting for the Freescale M5208EVB board is to run
>>>> the CPU at 166MHz. The current qemu emulation code for this board is
>>>> defaulting to 66MHz. This results in time appearing to run way to
>>>> slowly.
>>>> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
>>>> seconds in real time to actually complete.
>>>>
>>>> Change the hard coded default to match the default hardware setting.
>>>>
>>>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>>>> ---
>>>>  hw/m68k/mcf5208.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>>>> index 9240ebf..2d0b464 100644
>>>> --- a/hw/m68k/mcf5208.c
>>>> +++ b/hw/m68k/mcf5208.c
>>>> @@ -21,7 +21,7 @@
>>>>  #include "elf.h"
>>>>  #include "exec/address-spaces.h"
>>>>
>>>> -#define SYS_FREQ 66000000
>>>> +#define SYS_FREQ 166000000
>>>
>>> Good catch. But actually, the M5208EVB User's Manual talks about 166.67
>>> MHz, so while you're at it, maybe you should change it to 166666666
>>> instead?
>>
>> In this case, it should be better to use a period of 6000000 ns (and
>> ptimer_set_period() instead of ptimer_set_freq()).
> 
> Why is that better in this case?
> All the documentation lists it as 166.67MHz, even on the PCB.
> Isn't it clearer to define it based on the actual value documented?

It is better because 166.67 MHZ is clearly a rounded value computed from
the period: 1000000000/6000000 = 166.666666666666666666666666...

And internally QEMU uses the period, not the frequency.

Laurent

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Greg Ungerer]

On 27/09/16 23:27, Laurent Vivier wrote:
> Le 27/09/2016 à 15:22, Greg Ungerer a écrit :
>> Hi Laurent,
>>
>> On 27/09/16 18:11, Laurent Vivier wrote:
>>> Le 27/09/2016 à 09:33, Thomas Huth a écrit :
>>>> On 27.09.2016 03:29, Greg Ungerer wrote:
>>>>> The shipping default setting for the Freescale M5208EVB board is to run
>>>>> the CPU at 166MHz. The current qemu emulation code for this board is
>>>>> defaulting to 66MHz. This results in time appearing to run way to
>>>>> slowly.
>>>>> So a "sleep 5" in a standard ColdFire Linux build takes almost 15
>>>>> seconds in real time to actually complete.
>>>>>
>>>>> Change the hard coded default to match the default hardware setting.
>>>>>
>>>>> Signed-off-by: Greg Ungerer <gerg@uclinux.org>
>>>>> ---
>>>>>  hw/m68k/mcf5208.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/hw/m68k/mcf5208.c b/hw/m68k/mcf5208.c
>>>>> index 9240ebf..2d0b464 100644
>>>>> --- a/hw/m68k/mcf5208.c
>>>>> +++ b/hw/m68k/mcf5208.c
>>>>> @@ -21,7 +21,7 @@
>>>>>  #include "elf.h"
>>>>>  #include "exec/address-spaces.h"
>>>>>
>>>>> -#define SYS_FREQ 66000000
>>>>> +#define SYS_FREQ 166000000
>>>>
>>>> Good catch. But actually, the M5208EVB User's Manual talks about 166.67
>>>> MHz, so while you're at it, maybe you should change it to 166666666
>>>> instead?
>>>
>>> In this case, it should be better to use a period of 6000000 ns (and
>>> ptimer_set_period() instead of ptimer_set_freq()).
>>
>> Why is that better in this case?
>> All the documentation lists it as 166.67MHz, even on the PCB.
>> Isn't it clearer to define it based on the actual value documented?
> 
> It is better because 166.67 MHZ is clearly a rounded value computed from
> the period: 1000000000/6000000 = 166.666666666666666666666666...

Perhaps it is, but again it is not documented that way.
All the 5208 documentation talks in terms of frequency.
Would it not be clearer to define it in the same way that
the documentation lists?

Prime example from the M5208 Reference Manual regarding
the PLL settings:

. Voltage controlled oscillator range from 350 MHz to 540 MHz, resulting in a core frequency
  (fvco ÷ 3 (or fvco ÷ 4)) of 87.5 MHz to 166.67 MHz (maximum rated for device)


> And internally QEMU uses the period, not the frequency.

Ultimately I don't mind doing it in any way that results in
the patch being accepted :-)

Regards
Greg

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Peter Maydell]

On 27 September 2016 at 16:49, Greg Ungerer <gerg@uclinux.org> wrote:
> On 27/09/16 23:27, Laurent Vivier wrote:
>> It is better because 166.67 MHZ is clearly a rounded value computed from
>> the period: 1000000000/6000000 = 166.666666666666666666666666...
>
> Perhaps it is, but again it is not documented that way.
> All the 5208 documentation talks in terms of frequency.
> Would it not be clearer to define it in the same way that
> the documentation lists?
>
> Prime example from the M5208 Reference Manual regarding
> the PLL settings:
>
> . Voltage controlled oscillator range from 350 MHz to 540 MHz, resulting in a core frequency
>   (fvco ÷ 3 (or fvco ÷ 4)) of 87.5 MHz to 166.67 MHz (maximum rated for device)

Documentation quite often describes things in ways which
aren't what the underlying hardware actually does -- there's
an art to reading it and figuring out what's really going
on under the hood :-)

In the text you list here it says specifically that the
87.5 and 166.67 MHz frequencies are the results of
dividing the fvco clock by 3 or 4, which is obviously
 350 / 4 == 87.5 (for the low end)
 500 / 3 == 166.666666... (for the high end)

(If you care you can probably work through what the PLL
registers are set to that generates the 500MHz from
the crystal frequency.)

thanks
-- PMM

Re: [Qemu-devel] [PATCH] m68k: change default system clock for m5208evb

[Greg Ungerer]

On 28/09/16 10:22, Peter Maydell wrote:
> On 27 September 2016 at 16:49, Greg Ungerer <gerg@uclinux.org> wrote:
>> On 27/09/16 23:27, Laurent Vivier wrote:
>>> It is better because 166.67 MHZ is clearly a rounded value computed from
>>> the period: 1000000000/6000000 = 166.666666666666666666666666...
>>
>> Perhaps it is, but again it is not documented that way.
>> All the 5208 documentation talks in terms of frequency.
>> Would it not be clearer to define it in the same way that
>> the documentation lists?
>>
>> Prime example from the M5208 Reference Manual regarding
>> the PLL settings:
>>
>> . Voltage controlled oscillator range from 350 MHz to 540 MHz, resulting in a core frequency
>>   (fvco ÷ 3 (or fvco ÷ 4)) of 87.5 MHz to 166.67 MHz (maximum rated for device)
> 
> Documentation quite often describes things in ways which
> aren't what the underlying hardware actually does -- there's
> an art to reading it and figuring out what's really going
> on under the hood :-)

That can certainly be true.


> In the text you list here it says specifically that the
> 87.5 and 166.67 MHz frequencies are the results of
> dividing the fvco clock by 3 or 4, which is obviously
>  350 / 4 == 87.5 (for the low end)
>  500 / 3 == 166.666666... (for the high end)
> 
> (If you care you can probably work through what the PLL
> registers are set to that generates the 500MHz from
> the crystal frequency.)

It is reasonably strait forward, at least by what is documented
in the 5208 Reference Manual:

The output of the PLL is determined by:

  fsys = fref * (pfdr / (4 * cpudiv))

Where:

  fref is the external crystal (in this case 16MHz).
  pfdr is the PLL dividor register (set to 0x7d=125)
  cpudiv is from the PODR register (set to 3)

So that trivially gives fsys = 166666666

Anyway, perhaps the hardware designers set the maximum
operating frequency of the device based on cycle time
(ie 6ns) given internal path lengths, etc. Maybe there is
other reasons. Does it really matter? It is spelled out clearly
that the device limit is 166.67MHz, and that is by default
what the m5208evb is set to run at.

So what is an acceptable change to the frequency/cycle time
setting code in mcf5208.c for qemu? To just change the current
frequency definition, or change it to use period time and use
ptimer_set_period()?

Regards
Greg