| Message ID | 1474939750-29846-1-git-send-email-gerg@uclinux.org |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
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
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
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
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(-)