首要，清晰一个问题：
1、嵌入式体系板子上的时刻是用date规范体系指令检查的，date是SHELL指令，例如busybox或许uClinux上的sash等。这个时刻是有运转起来的嵌入式LINUX软件保护的，其实便是内存中的一个全局变量，LINUX默许发动给这个全局变量赋值便是19700101这样的数值。
2、RTC芯片(很多是嵌入式处理器内置RTC模块，那么便是CPU内部寄存器)内部的寄存器保护的时刻值。
一般的，LINUX发动后，您能够经过date指令来设置更改体系时刻，但掉电就会丢掉的，发动后又是1970这样的时刻了。若要能date设置后保存体系时刻，使得在下次重启后还能坚持的话，就有必要有RTC+后备电池 的软硬件支撑。
例如，咱们PC上能够设置体系时刻，重启后也不会丢掉，便是因为咱们PC主板上有RTC支撑。
RTC能够是外接的一个芯片，例如常见的X1226/1227等，它们便是经过I2C接到处理器上的。
当然，现在更多的状况是CPU内置RTC模块，这样您硬件规划的话就只需供给后备电池即可。
清晰了体系时刻的两个概念后，咱们来看看RTC的完成机制。
在嵌入式体系上，完成的办法能够灵活多样，只需能到达终究的意图：
您可经过某种操作获取当时的正确的时刻，并且重启不会丢掉。
那么看看几种完成机制。
在开端介绍几种办法前，咱们先阐明一下软件时刻的办法：
咱们的渠道是嵌入式LINUX，要完成RTC支撑，则有必要是“驱动+应用程序”的办法，而咱们的驱动都主张是选用MODULES办法独立加载的办法，这样可不影响整个LINUX内核。
下面开端介绍完成办法：
从上面能够看到，时刻实践上是两个当地一起在保护的，一个是RTC芯片内部寄存器或CPU的RTC寄存器;另一个则是LINUX保护的时刻。LINUX的时刻重启就会丢掉，而RTC因为有后备电池保护，则不会丢掉，在板子断电后还能够持续保持计时。所以，最好了解的完成办法便是让LINUX内核发动的时分，从RTC芯片里边读取时刻值，赋给LINUX的时刻变量。这样LINUX一发动时刻就校对过来，不再是1970了。当然，这样做，就不能用独立的RTC驱动的MODULES方法了。而当您经过date指令设置LINUX时刻时，您还要修正date指令的代码，使之一起还要经过I2C修正RTC芯片内部寄存器数值(或CPU内部寄存器数值)，当然了，这样仍是需求一个读写RTC的驱动的。
下面则是一个更简化的完成办法
即LINUX发动时，不从RTC芯片里边读取时刻，而您直接修正date指令的代码，让它不要从LINUX供给的接口读取，而是直接经过驱动从RTC里边直接读取。
别的，如果您的体系答应的话，您都能够不走date的道路，即读取体系时刻不必date指令也能够，能够自己直接写个读取时刻的函数，例如read_rtc/write_rtc，就用这两个函数替代date指令读取和设置体系时刻的功用。
呵呵，写了这么多，如同也没说清楚，最终，咱们记住：
咱们看到的时刻，实践是在两个不同的当地保护的
一个是LINUX保护的，一个是RTC芯片里边的。
这样就存在一个两个时刻同步的问题，一个产生在LINUX发动的时分，需求从RTC里边获取时刻;另一个产生在您设置体系时刻的时分，需求两个一起更改。
当然了，中心一些猫腻就能够产生，例如您能够偷闲越过LINUX时刻，让date或许您自己的代码直接读取RTC时刻，而彻底不理睬LINUX的时刻(还让它是1970…吧)
在ARM9试验箱等板子上，咱们是经过修正busybox的date.c代码来完成的的;而在HHGW-LITE-R3等HHPPC渠道上则是经过自己写的writeRTC来作的。
前一种办法改变了体系运转办法，后一种则没有把硬件时刻同LINUX体系时刻联系起来。
