Implementation of time processing and latency functions in uboot

The implementation methods of time processing and latency functions in uboot are so hungry when we port uboot. without looking at the latency processing function carefully, we can use a very simple latency function to confuse it. Later, although it can be run, the time-out algorithm cannot be used or error occurs. A typical problem is that the sleep command cannot be correctly executed. Whether it is sleep 0 or sleep 9999, it will all be done at once.
This evening, I carefully studied the uboot time processing and timeout algorithm (which is quite simple because there is no interruption ). In uboot, two global variables are closely related to time processing: Timestamp and lastdec. In the process of init and reset, the timestamp is initialized to zero, and lastdec is initialized to the timer load value (generally, the 32-bit timer is full F, that is, 0 xffffffff ). The timer works in the automatic loading mode, decreasing the count.
To simplify the problem, assume that it is the first time to take the time, that is, the timestamp is zero, and lastdec is 0 xffffffff. In the get_timer function, the timestamp is assigned the lastdec value minus the current timer Count value (if the timer overflows, overflow correction is required. For details, refer to uboot code) and return timestamp.
In the latency function udelay, first convert the passed parameter USEC (millisecond) to the number of clocks, then get the current timestamp through get_timer, and add the current timestamp to the previous number of clocks, that is, get the timeout timestamp, and then continue to get the timestamp until the obtained time exceeds the above Count value.
It should be said that the time processing and timeout algorithms of uboot are relatively simple. This algorithm also has defects, especially for sep4020. Because the timer of sep4020 has no pre-division, the timer will decrease the count directly driven by the system clock. When the clock speed is 96 m, the timestamp can only keep the Count value less than 45 seconds. Once the value exceeds this value, the timestamp overflows. Therefore, upper-layer applications are required to detect and correct the vulnerability.
The above is a bit of experience with uboot time processing and timeout algorithms. Time is too short, and errors are inevitable.