On 7/12/2011 6:10 AM, Wolfgang Denk wrote:
Dear Graeme Russ,
<snip>
Do we? What exactly is the needed resolution of the underlying hardware timer? So far, it appears sufficient to have it ticking with 1000 Hz or more. Are there really systems that cannot provide that? The only architecture I remember that seemed prolematic was NIOS - but then the NIOS documentation suggests that this might actually be
Hi All, The NIOS2 "systems" are a FPGA based architecture ("soft" core). They CAN have all different kinds of timers. However, there are many already out in the world that were built (generated) with a timer that has 10 ms resolution. We can't retro-actively change these. We can declare them not supported in future releases, but we can't fix the resolution problem retroactively. I have two comments regarding this discussion so far. First, I think using the "time" function name at all is a VERY BAD idea. People will confuse it with the "normal" c library function that returns the time of day since the epoch. One may say that they should RTFM, but it is lots easier to just use another name and avoid all such confusion. Second, I think forcing all systems to use 64 bit time stamps is not a good idea. The main purpose of the timer API is to provide hardware timeouts. 64 bits is vast overkill for such a purpose. Mandating 64 bit capability for all u-boots is I think counter-productive. A 32 bit timestamp in millisecond resolution plus udelay covers all practical cases. The 1 ms resolution is probably inadequate for performance measurement, but for every u-boot system that is sometimes used for performance measurement, there are 100 (probably even more, like 1000, but I don't really have the figures) systems that are just used to boot Linux or another stand alone program. So we may need a different API for performance measurement that uses higher resolution. On most "larger" CPUs, there are hardware timers that can already do this with minimal work. On some less-capable CPUs, it may be lots harder, but if you aren't doing performance measurement, you don't need it. So I suggest that mandating a 64 bit API for some of the processors (68K comes to mind) is not really a good idea. It seems counter to the elegant simplicity of the rest of u-boot to stick a 64 bit requirement on timestamps used to determine if the boot delay is expired.
Best Regards, J. William Campbell
Best regards,
Wolfgang Denk