Dear Wolfgang Denk, >> Actually CONFIG_SYS_HZ (whatever that is). > > It is defined to be 1000.
Ok, game with that. Then the define CONFIG_SYS_HZ should not be in every <board>.h since that suggests that a board developer has some freedom there... >> I think it is necessary to summarize all implicit or explicit documented >> "defined to have's" regarding the timer and then to verify that all >> implementations adhere to them. > > Indeed - documentation is an are where U-Boot has a serious lack. OK, to summarize: 1. reset_timer(), get_timer(base) operate with 1ms granularity. An implementation MUST make that close to 1ms. On second thought, it might be valueable to be able to set CONFIG_SYS_HZ to the exact value of the actual granularity. (for example 1024, if a 32kHz based timer is used). It should be pointed out, that the pair reset_timer()/get_timer() cannot be used nested, and MOST IMPORTANT that some implementations of udelay() might call reset_timer() and therefore break an outer timeout loop !!! It is also open if reset_timer() does actually reset the hardware timer (e.g. tbu/tbl at PPC) - which would be messing up any time difference calculation using get_ticks() - or does emulate that by remembering the hardware value and subtracting it later in every subsequent get_timer() call? 2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC). Since they are defined as having 64 bits they MUST not wrap at 32 bits, i.e. if the hardware provides only 32 bits, the upper 32 bits must be emulated by software. Otherwise we have to document that get_ticks() cannot be used to get 64 bit time differences. OR fall back to a 32 bit get_ticks() that should perhaps increment at a microsecond rate (see Bill Campbell's post). If you really closely look at the various implementations of those timers, you will easyly see the wide variations implemented there. Best Regards, Reinhard _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
