Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1725642
  • 博文数量: 98
  • 博客积分: 667
  • 博客等级: 上士
  • 技术积分: 1631
  • 用 户 组: 普通用户
  • 注册时间: 2009-04-27 15:59
个人简介

一沙一世界 一树一菩提

文章分类

全部博文(98)

文章存档

2021年(8)

2020年(16)

2019年(8)

2017年(1)

2016年(11)

2015年(17)

2014年(9)

2013年(4)

2012年(19)

2011年(1)

2009年(4)

分类: LINUX

2012-08-20 15:39:43

关于系统时钟慢的解决方法,芯片是r8610,内核是linux-3.0.4.下面是自己的解决过程,记录下来,希望对也做这一块的同学有所帮助,错误之处,在所难免,欢迎指出啊。

2月前移植的linux-3.0.4又有问题啦,系统时钟比硬件时间慢,而且慢的很多。
今天又听到消息啦,系统时钟慢。于是我那一台设备,接串口,验证。
首先date设置系统时钟,然后hwclock -w同步。然后计时。经过验证,结论如下:
大概每30分钟慢236s,也就是说每7.6s就会慢1s,12.7%。我靠,慢的也太厉害啦。

首先,我怀疑添加的驱动有问题,把驱动,一些应用都关了。只跑系统。
继续测试,涛声依旧啊。基本一样。

linux系统时间和硬件时间是有一些偏差,由于内核定时器,锁机制的应用,是可能产生一些差距,但是这12.7%确实有点高啊。

先google查找,看看有没有预见同样情况的,一查不要紧,这问题很多啊,看样linux系统的时间确实和硬件时间有一定差距不是个案啊。解决方法一般有下面两种:
1  定时同步,也就是每隔一定时间,进行一次hwclock -s
2  用buxybox提供的adjtimex来调时间

第一种方案,首先肯定的是我这里是可以借鉴的,但是每分钟慢7或者8秒,这个同步周期是不得很短啊。尽管设备对时间要求不是非常严格,但是也不能每分钟有7秒的差距啊。再说每10秒同步一次也不合适啊。
第二种方案,编译完busybox后,用这个命令调时间的话,-t和-f参数是有范围的。我设置参数达到极限值,确实有所改观,但是只能达到每30分钟慢72秒,这也不小啊。

然后我看了看,别人用这两种方法来调试系统时间,一般是差距不很大的情况。我感觉应该是我的系统是有问题的,即使通过同步做的表面上看起来时间差不多,但是这个时间差距这么大会不会有其它潜在的风险呢?

本着负责的态度来重新看待这个问题,不能只停留在解决的层面,要找到原有才是硬道理啊。

首先,给芯片提供商打个电话,确定一下。芯片厂商一个FAE接我的电话,说这个芯片支持从网上下载的标准内核,任何都不用修改,我再三确定,对方很负责任的告诉你,没有任何问题,他们都这么用。我问他们有没有验证过,对方也是很负责任的告诉我在他们的板子上根本就没有这问题,肯定没有这问题。

停了对方这么肯定的回答,我想到三个方面:
1  问题肯定有
2  可能是我的内核编译选项有不合理的地方
3  我们的硬件和厂商的提供的板子有区别

第一步,查看内核选项,只要和时间,定时器,RTC,hwclick,HZ有关的选项我都仔细的看了看。应该没有错误的地方。然后抱着不太相信自己,相信FAE的态度把一些选项修改,再测试。还是那样。问题没有解决。

第二步,把厂商提供的板子的pdf版原理图拿来看看,和我们的板子很大部分都一样。尤其时钟部分肯定一样。

没有进展,实在没有办法,只能看原理图+datasheet啦。我们采用的这颗cpu是r8610,和pc486完全兼容的。
看系统tick这一块,这破datasheet说的也太含糊啦,关键细节地方都没有提及,估计由于和486兼容,让参考相关486芯片呢吧。

r8610的系统时钟是有82c54提供的,82c54确实是pc也采用的定时芯片,一般情况用timer0方式3产生固定838ns周期方波来实现。默认采用14.31818m的外部时钟来提供,根据写到芯片计数器里的初值来计算有多少个838ns的时间间隔来产生irq0,而这个irq0产生的频率就是linux系统里的HZ。例如,在我的系统里HZ设置为250,那么1秒内irq0就要产生250次中断。这个值也就是我们查看/proc/interrupt所显示的第一行的内容。

在linux-3.0.4内核目录下的include/linux目录下的timerx.h这个文件里有这么一个定义:
#define PIT_TICK_RATE 1193182ul
这个就是系统默认使用的定时芯片的采用的计数时钟,

在linux-3.0.4内核目录下的arch/x86/include/asm/timex.h文件有这样的定义:
#define CLOCK_TICK_RATE PIT_TICK_RATE

在linux-3.0.4内核目录下的include/linux目录下的jiffies.h文件里有这么一个宏:
#define LATCH ((CLOCK_TICK_RATE + HZ/2)/HZ,而这个值就是要写入定时器的初始值。我根据我的环境计算了一下,
(1193182+250/2)/250 = 4773.228,这个值写入82c54,这个值也就是说82c54需要经过这么多个838ns的周期才产生一次irq0中断。两次中断之间的时间间隔是:4773.228×838(ns)= 3999965.064.这个值应该就是HZ的倒数。即3999965.064×250应该等于1.而实际计算结果是999991266,基本相等,说明在这个芯片上的linux系统定时器和硬件定时器产生联系的地方就是这里。

上面的计算是理想状态,也就是说如果硬件按照上面的计算过程来运行的话,系统时间也是会有时间差距的,但是很小,以为我们实际计算结果是999991266,每秒还慢8734ns,但是那已经很小了。

我首先考虑到的就是我的定时器时钟可能不是1193182。于是,继续研读r8610 datasheet,看其中关于clock source的选择,可惜,没有提到。于是继续google,打不开啦,被和谐啦,baidu,别用啦,更本找不到啊。等会。抽烟,喝杯茶。30分钟以后,google 查到下面,对我有十分巨大的提示啊:

8254 工作时钟的来历最初在对个人电脑设计时,出于成本考虑,主板上采用了当时广泛应用于电视机且价格最便宜的一个 14.31818MHz 振荡器,该振荡器的频率远高于系统其他器件所需要的频率。所以设计师采用 3 分频后得到 4.77MHz 驱动中央处理器 8088 ;采用 4 分频后得到 3.58MHz 用于驱动彩色图形适配器;最后将系统各种频率的基频 1.1931816 MHz (各种频率的最大公约数,即 12 分频) 作为系统可编程定时器芯片的输入时钟。为了保持兼容性,可编程定时器 8254 就一直采用这个频率的时钟作为输入。

也就是说,这就是14.31818和1193182的关系,是12分频啊。在r8610 datasheet上没有用到外部的14.31818,而是内部的12.5m啊。并且在一个并不起眼的地方发现有下面一句话:
NOTE: the following clock is 14.318MHZ/12(external) or 12.5MHZ/12(internal)
我的个妈呀,不容易啊,终于找到了啊,我要找的就是这一句啊。严重鄙视自己对datasheet的粗心阅读。
也就是说在r8610这颗cpu里面,82c54采用的clk是12.5M/12 = 1041667.
在修改以前,大概计算一下:1193182-1041667/1193182 = 0.126983 = 12.7%。我靠,太正了,啥也别说了,都是眼泪。
赶紧的,注释,修改,测试。
时间ok啦。

以上就是我调试系统时间慢的过程,总结:
1  如果时间慢的很多,可以从硬件入手看看时钟设置是否正确
2  阅读datasheet一定要仔细,一字不落的阅读
3  不要盲目相信FAE

希望以上内容对大家有所帮助
阅读(11206) | 评论(5) | 转发(3) |
给主人留下些什么吧!~~

我是炮灰2013-06-27 21:40:40

大哥 能说明白点不 编译 注释了哪里啊?我也碰到这问题啦。。。。

最大行业软件2012-12-01 10:36:52

PTC Creo Elements/Pro 5.0 M070 Working for Win32-ISO 1DVD(最新多语言正式版包括简、繁体中文)

PTC Creo Elements/Pro 5.0 M070 Working for Win64-ISO 1DVD

PTC Creo Elements View (ex Product View) v10 F000 build 93 Pro Multilanguage Win32 1CD

PTC Creo Elements View (ex Product View) v10 F000 build 93 Pro Multilanguage Win64 1CD

 

PTC Pro/E WildFire+Pro/Mechancia 4.0 M110 Working for Win32-ISO 1DVD(最新多语言正式版包括简、繁体中文)

PTC Pro/E Wil

fireaxe2012-08-27 18:34:39

shiyigudong: 个人感觉描述的确实也不太清晰啊.....
充分证明了总结归纳的重要性。

shiyigudong2012-08-21 14:12:46

个人感觉描述的确实也不太清晰啊

GFree_Wind2012-08-21 10:34:48

虽然看得有点稀里糊涂,但是还是要赞一下。——我脱离底层硬件太多年了啊,亏得我还是电工出身,鄙视自己一下!