Hi Michael, On Sun, Sep 4, 2022 at 1:54 AM Michael Walle <mich...@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 <mibo...@gmail.com> wrote: > >> > >> Hi Stefan, > >> > >> On Sat, Sep 3, 2022 at 3:44 AM Stefan Roese <s...@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 <s...@denx.de> wrote: > >> > >> > >> > >> Add timer_get_boot_us() to support boards, that have CONFIG_BOOTSTAGE > >> > >> enabled, like pogo_v4. > >> > >> > >> > >> Signed-off-by: Stefan Roese <s...@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
