linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* linuxppc-embedded: mpc8260 bus frequency calculations
@ 2001-03-02  1:40 Brendan J Simon
  2001-03-02  4:20 ` Neil Russell
  2001-03-02  7:26 ` Dan Malek
  0 siblings, 2 replies; 8+ messages in thread
From: Brendan J Simon @ 2001-03-02  1:40 UTC (permalink / raw)
  To: linuxppc-embedded; +Cc: Dan Malek


I've come accross a problem where our custom embedded 8260 board is
losing time.  I've tracked it down to the bi_busfreq value being set to
66 instead of the true value of
66.6666666666666666666666666666666666666.  One solution is to have the
board_info fields in units of Hz instead of MHz.  I could then set the
bi_busfreq value to 66666667 for much better accuracy.

Another solution might be to regularly read the real time clock.  Does
linux do this normally or does it just read the RTC once at boot up and
then just rely on it's internal timers for the system time.  I can't see
how this can be very accurate.

Thanks,
Brendan Simon.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  1:40 linuxppc-embedded: mpc8260 bus frequency calculations Brendan J Simon
@ 2001-03-02  4:20 ` Neil Russell
  2001-03-02  4:32   ` Brendan J Simon
  2001-03-02  7:26 ` Dan Malek
  1 sibling, 1 reply; 8+ messages in thread
From: Neil Russell @ 2001-03-02  4:20 UTC (permalink / raw)
  To: brendan.simon, linuxppc-embedded; +Cc: Dan Malek


If bi_busfreq is set to 66.0 and the crystal is 66.6666, then the system
clock should appear to go too fast.  Sounds like what you have is the other
way around.  I've seen plenty of crystals that are running at 66.0 MHz.
Do you have one of these?

The system time is set once at boot up from the RTC.  If the system
gains/looses time by some fraction of a percent, then this may well
be just error in the crystal.  Most systems I've seen have some error.
The program "adjtimex" exists to correct this.


Neil.


On Fri, Mar 02, 2001 at 12:40:54PM +1100, Brendan J Simon wrote:
>
> I've come accross a problem where our custom embedded 8260 board is
> losing time.  I've tracked it down to the bi_busfreq value being set to
> 66 instead of the true value of
> 66.6666666666666666666666666666666666666.  One solution is to have the
> board_info fields in units of Hz instead of MHz.  I could then set the
> bi_busfreq value to 66666667 for much better accuracy.
>
> Another solution might be to regularly read the real time clock.  Does
> linux do this normally or does it just read the RTC once at boot up and
> then just rely on it's internal timers for the system time.  I can't see
> how this can be very accurate.
>
> Thanks,
> Brendan Simon.
>
>

--
Neil Russell <caret@c-side.com>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  4:20 ` Neil Russell
@ 2001-03-02  4:32   ` Brendan J Simon
  2001-03-02  5:27     ` Murray Jensen
  2001-03-02 14:50     ` Daris A Nevil
  0 siblings, 2 replies; 8+ messages in thread
From: Brendan J Simon @ 2001-03-02  4:32 UTC (permalink / raw)
  Cc: linuxppc-embedded


I agree that most systems have some error, but about 1 second every
minute is not good :(
This error can be substantially reduced by more accurately specifying
the clock frequency.  We have a custom board with a 66.6666MHz
oscillator module on it.  There is no way to specify this accurately
with the current interpretation of the board_info structure.  The best
one can do is specify 66,000,000 or 67,000,000 Hz :(

I would like to see the board_info structure members be interpreted as
Hz rather than MHz.  I think this must have been the case earlier
because I saw some code that was commented out which looked something
like "/*** / 1000000 ***/".  ie. the Hz value was being divided by
1000000 to display MHz.  Now someone (Dan ?) changed the interpretation
of the board_info structure for a reason, and I'm wondering if I will
break anything if I change the meaning to Hz.  I'm sure there would be
some easy work arounds by just dividing by 1000000 where necessary.

Brendan.



Brendan.

Neil Russell wrote:

> If bi_busfreq is set to 66.0 and the crystal is 66.6666, then the system
> clock should appear to go too fast.  Sounds like what you have is the other
> way around.  I've seen plenty of crystals that are running at 66.0 MHz.
> Do you have one of these?
>
> The system time is set once at boot up from the RTC.  If the system
> gains/looses time by some fraction of a percent, then this may well
> be just error in the crystal.  Most systems I've seen have some error.
> The program "adjtimex" exists to correct this.
>
>
> Neil.
>
>
> On Fri, Mar 02, 2001 at 12:40:54PM +1100, Brendan J Simon wrote:
>
>> I've come accross a problem where our custom embedded 8260 board is
>> losing time.  I've tracked it down to the bi_busfreq value being set to
>> 66 instead of the true value of
>> 66.6666666666666666666666666666666666666.  One solution is to have the
>> board_info fields in units of Hz instead of MHz.  I could then set the
>> bi_busfreq value to 66666667 for much better accuracy.
>>
>> Another solution might be to regularly read the real time clock.  Does
>> linux do this normally or does it just read the RTC once at boot up and
>> then just rely on it's internal timers for the system time.  I can't see
>> how this can be very accurate.
>>
>> Thanks,
>> Brendan Simon.
>>
>>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  4:32   ` Brendan J Simon
@ 2001-03-02  5:27     ` Murray Jensen
  2001-03-02 14:50     ` Daris A Nevil
  1 sibling, 0 replies; 8+ messages in thread
From: Murray Jensen @ 2001-03-02  5:27 UTC (permalink / raw)
  To: brendan.simon; +Cc: linuxppc-embedded


On Fri, 02 Mar 2001 15:32:29 +1100, Brendan J Simon <brendan.simon@bigpond.com> writes:
>I would like to see the board_info structure members be interpreted as
>Hz rather than MHz.

If you used ppcboot, you could enable the CFG_CLKS_IN_HZ config option and
then ppcboot would do exactly what you want.

>... I'm wondering if I will
>break anything if I change the meaning to Hz.

I run my 2.4.1+ 8260 kernel with the board info clocks supplied in HZ and
everything appears to run fine. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing Sci & Tech,         Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen@cmst.csiro.au  (old address was mjj@mlb.dmt.csiro.au)


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  1:40 linuxppc-embedded: mpc8260 bus frequency calculations Brendan J Simon
  2001-03-02  4:20 ` Neil Russell
@ 2001-03-02  7:26 ` Dan Malek
  2001-03-02 14:20   ` Magnus Damm
  1 sibling, 1 reply; 8+ messages in thread
From: Dan Malek @ 2001-03-02  7:26 UTC (permalink / raw)
  To: brendan.simon; +Cc: linuxppc-embedded, Dan Malek


Brendan J Simon wrote:

> .... One solution is to have the
> board_info fields in units of Hz instead of MHz.

I know.  It's one of my patches to add real soon now :-).


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  7:26 ` Dan Malek
@ 2001-03-02 14:20   ` Magnus Damm
  2001-03-08  6:06     ` Dan Malek
  0 siblings, 1 reply; 8+ messages in thread
From: Magnus Damm @ 2001-03-02 14:20 UTC (permalink / raw)
  To: Dan Malek; +Cc: brendan.simon, linuxppc-embedded, Dan Malek


> > .... One solution is to have the
> > board_info fields in units of Hz instead of MHz.
>
> I know.  It's one of my patches to add real soon now :-).

I think that would be nice for the mpc8xx boards too.

/ Magnus

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02  4:32   ` Brendan J Simon
  2001-03-02  5:27     ` Murray Jensen
@ 2001-03-02 14:50     ` Daris A Nevil
  1 sibling, 0 replies; 8+ messages in thread
From: Daris A Nevil @ 2001-03-02 14:50 UTC (permalink / raw)
  To: brendan.simon; +Cc: linuxppc-embedded


Brendan,

We did exactly as you suggest here in the QSLinux kernel.  We modified
the board_info structure to specify the input clock frequency in Hz
rather than in MHz.  Refer to the code in ftp://qslinux.org.

I don't think Dan changed the code (correct me if I'm wrong).  I began
using the 2.2.5 kernel about 2 years ago, and it was specified in MHz
way back then.  I think the original code was probably written by Cort.

You could easily make the change on whatever kernel you are using
(MonteVista?).  The board descriptor structure is meant to be somewhat
flexible.  You just need to do a grep to find out where else the
variable is used.  You will probably find that it is used in the
ethernet and console serial drivers, and in the initialization of the
internal count-down clock.  The board_info structure is not used down in
the internals of the Linux kernel.  It is "board specific", and so it
only applies to a few board specific device drivers.

Regards,
Daris


--
Daris A Nevil
Simple Network Magic Corporation
401 Kentucky Lane
McKinney, TX 75069
214-793-7757
dnevil@snmc.com
www.snmc.com
quickstack.com
qslinux.org

Brendan J Simon wrote:
>
> I agree that most systems have some error, but about 1 second every
> minute is not good :(
> This error can be substantially reduced by more accurately specifying
> the clock frequency.  We have a custom board with a 66.6666MHz
> oscillator module on it.  There is no way to specify this accurately
> with the current interpretation of the board_info structure.  The best
> one can do is specify 66,000,000 or 67,000,000 Hz :(
>
> I would like to see the board_info structure members be interpreted as
> Hz rather than MHz.  I think this must have been the case earlier
> because I saw some code that was commented out which looked something
> like "/*** / 1000000 ***/".  ie. the Hz value was being divided by
> 1000000 to display MHz.  Now someone (Dan ?) changed the interpretation
> of the board_info structure for a reason, and I'm wondering if I will
> break anything if I change the meaning to Hz.  I'm sure there would be
> some easy work arounds by just dividing by 1000000 where necessary.
>
> Brendan.
>
> Brendan.
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: linuxppc-embedded: mpc8260 bus frequency calculations
  2001-03-02 14:20   ` Magnus Damm
@ 2001-03-08  6:06     ` Dan Malek
  0 siblings, 0 replies; 8+ messages in thread
From: Dan Malek @ 2001-03-08  6:06 UTC (permalink / raw)
  To: Magnus Damm; +Cc: brendan.simon, linuxppc-embedded, Dan Malek


Magnus Damm wrote:

> I think that would be nice for the mpc8xx boards too.

My plan is to just change them all.  It was originally this
way because it is the value given to me by the MBX boot rom
and was just propagated through all of the code.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2001-03-08  6:06 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2001-03-02  1:40 linuxppc-embedded: mpc8260 bus frequency calculations Brendan J Simon
2001-03-02  4:20 ` Neil Russell
2001-03-02  4:32   ` Brendan J Simon
2001-03-02  5:27     ` Murray Jensen
2001-03-02 14:50     ` Daris A Nevil
2001-03-02  7:26 ` Dan Malek
2001-03-02 14:20   ` Magnus Damm
2001-03-08  6:06     ` Dan Malek

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).