Hi Michael,
On Sun, Sep 4, 2022 at 1:54 AM Michael Walle michael@walle.cc wrote:
Am 2022-09-04 02:02, schrieb Tony Dinh:
Hi Stefan,
Sorry, that message was prematurely sent (fat finger). Please see the continuation below.
On Sat, Sep 3, 2022 at 4:43 PM Tony Dinh mibodhi@gmail.com wrote:
Hi Stefan,
On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese sr@denx.de wrote:
Hi Tony,
On 03.09.22 11:44, Tony Dinh wrote:
Hi Stefan,
On Thu, Sep 1, 2022 at 11:25 PM Stefan Roese sr@denx.de wrote:
Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE enabled, like pogo_v4.
Signed-off-by: Stefan Roese sr@denx.de
v2:
- Change timer_get_boot_us() to use the timer_early functions
- Remove #if CONFIG_IS_ENABLED(BOOTSTAGE)
Simon, I'm currently looking into this timer_get_boot_us() to using timer_early_get_count() etc consolidation.
Indeed, as you've mentioned above, I think timer_early_get_count() and timer_early_get_rate() do need to take into consideration what the input_clock_type is for Kirkwood boards with CONFIG_BOOTSTAGE such as the Pogo V4.
I'm seeing on the Pogo V4 test, the timer command reports time about 6 times slower than it should. It does seem to jive with the fact that the Pogo V4 CONFIG_SYS_TCLK is 166Mhz, versus MVEBU 25MHz clock rate.
Ah, I've missing updating the early functions to also differentiate between fixed clocks and TCLK timer.
Please give the attached patch a try - should be applied on top of this latest patchset.
That looks promising, but I think we are still missing something. After applying the attached patch, I ran the test again and it behaved the same way (clock rate 6 times slower). So I did another test.
--- Test 1 Pogo_V4> timer start; sleep 60; timer get; sleep 30; timer get 60.000 90.000
So apparently the sleep cmd has reset the correct clock rate.
--- Test 2
Pogo_V4> timer start; sleep 30; timer get; sleep 30; timer get 30.000 60.000
And then wait for 30 seconds, do another "timer get" (I expected to see about 90 to 95 seconds).
Pogo_V4> timer get 66.237
I've did the same test and can confirm it. But I think that is a drawback from the timer command. With a 32bit timer and a TCLK of 166MHz (on my board), the timer will wrap around about every 26s. So if you don't do a get_timer() call for that whole period, the overflow won't be counted in timer_conv_64().
For the sleep command it works correctly, because it will poll get_timer() every 100us.
In summary, you cannot expect a "timer get" on the console to work if you cannot make sure, the you call it at least every "2^32 / TCLK" seconds.
-michael
Thanks for confirming that and the explanation. It makes perfect sense! I think I got side tracked and never noticed that it is a 32-bit timer wrap- around :)
All the best, Tony