All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tony Dinh <mibodhi@gmail.com>
To: Stefan Roese <sr@denx.de>
Cc: "U-Boot Mailing List" <u-boot@lists.denx.de>,
	"Pali Rohár" <pali@kernel.org>,
	"Michael Walle" <michael@walle.cc>
Subject: Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards
Date: Tue, 30 Aug 2022 23:30:43 -0700	[thread overview]
Message-ID: <CAJaLiFzNpnEM3xRqxnU-xXQMVCVUM7ZyDjQ+=qDKnw=HhEWWug@mail.gmail.com> (raw)
In-Reply-To: <ca7ebeb3-ff2c-b318-5079-997ad16498a2@denx.de>

Hi Stefan,

On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese <sr@denx.de> wrote:
>
> Hi Tony,
>
> On 31.08.22 07:02, Stefan Roese wrote:
> > Hi Tony,
> >
> > On 31.08.22 00:15, Tony Dinh wrote:
> >> Hi Stefan,
> >>
> >> On Tue, Aug 30, 2022 at 4:53 AM Stefan Roese <sr@denx.de> wrote:
> >>>
> >>> This patchset enhaces the recently added Orion Timer driver to support
> >>> all other Kirkwood & 32bit MVEBU Armada platforms. Additionally, this
> >>> timer support is then enabled per default for those platforms, so that
> >>> the board config files don't need to be changed. Also necessary is
> >>> some dts hacking, so that the timer DT node is available in early
> >>> U-Boot stages.
> >>>
> >>> I've successfully tested this patchset on an Armada XP board. Additional
> >>> test on other boards and platforms are very welcome and necessary.
> >>
> >> I've run some tests with the following 2 Kirkwood boards: Cloud
> >> Engines Pogo V4 88F6192 (with CONFIG_DM_RTC and CONFIG_RTC_EMULATION),
> >> and Marvell Sheevaplug 88F6281 (with CONFIG_DM_RTC and CONFIG_RTC_MV).
> >>
> >> It seems that it was either frozen or the timer did not expire at some
> >> subsequent sleep commands. Sometime it happened at 2nd command, some
> >> time at a later sleep command. For example,
> >>
> >> === Pogo V4 (the 1st sleep command works correctly at 10 seconds on my
> >> stopwatch)
> >>
> >> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 13:38:24 -0700)
> >> Pogoplug V4
> >>
> >> Hit any key to stop autoboot:  0
> >> Pogo_V4> sleep 10
> >> Pogo_V4> sleep 31.5
> >> <frozen here>
> >
> > Does the cmd interface support fractial numbers? Please test again with
> > 31 or other integral numbers.
> >
> >> === Sheevaplug (RTC battery is old, so the date was not updated, but
> >> the clock seems OK)
> >>
> >> U-Boot 2022.10-rc3-00048-g66ccd87a9c-dirty (Aug 30 2022 - 14:14:24 -0700)
> >> Marvell-Sheevaplug
> >> Hit any key to stop autoboot:  0
> >> => date
> >> Date: 2000-01-01 (Saturday)    Time:  0:02:55
> >> => sleep 10
> >> => date
> >> Date: 2000-01-01 (Saturday)    Time:  0:03:18
> >> => sleep 10
> >> => sleep 20.1
> >> <frozen here>
> >>
> >> Please let me know what I can do (i.e. perhaps running a debug patch).
> >
> > Please see above. I assume that the fractional numbers result in very
> > long numbers internally, which result in a frozen / hanging system.
>
> I just tested fractional numbers on another board and hey, it just
> works. Learned something new. So we seem to have a problem here. Let
> me see, if I can find something.

I've added debug printfs and possibly tracked down this issue. Seems
like in the 2nd call to sleep, get_timer(0) did not reset the start
number.

cmd/sleep.c
static int do_sleep(struct cmd_tbl *cmdtp, int flag, int argc,
                    char *const argv[])
{
       ulong start = get_timer(0);

"do_sleep got a timer start = 2015" is the 1st call to sleep 5.
"do_sleep got a timer start = 16304" is the 2nd call to sleep 10.

<BEGIN log>
Pogo_V4> sleep 5
do_sleep got a timer start = 2015
do_sleep delay = 5000
do_sleep delay = 5000
do_sleep sleeping...
do_sleep start 2015 curent 100
do_sleep start 2015 curent 200
do_sleep start 2015 curent 300
<snip>
do_sleep start 2015 curent 4900
do_sleep end of sleep ... current = 5000
Pogo_V4>

Pogo_V4> sleep 10
do_sleep got a timer start = 16304
do_sleep delay = 10000
do_sleep delay = 10000
do_sleep sleeping...
<snip>

<END log>

So somewhere in the DM timer, "start" got accumulated. I think each
get_timer(0) should be a different timer instance. It looks like the
same timer instance is used again and again, causing the "start "to
grow bigger, and at one point it might just overflow.

Thanks,
Tony

> Thanks,
> Stefan

  parent reply	other threads:[~2022-08-31  6:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 11:53 [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards Stefan Roese
2022-08-30 11:53 ` [PATCH 1/6] timer: orion-timer: Add support for other Armada SoC's Stefan Roese
2022-08-30 11:53 ` [PATCH 2/6] timer: orion-timer: Add timer_get_boot_us() for BOOTSTAGE support Stefan Roese
2022-08-30 12:00   ` Michael Walle
2022-08-30 12:08     ` Stefan Roese
2022-08-30 15:56       ` Simon Glass
2022-08-31  5:57         ` Stefan Roese
2022-08-31 17:44           ` Simon Glass
2022-09-01  5:33             ` Stefan Roese
2022-08-30 11:53 ` [PATCH 3/6] arm: mvebu: Use CONFIG_TIMER on all MVEBU & KIRKWOOD platforms Stefan Roese
2022-08-30 12:04   ` Michael Walle
2022-08-30 12:11     ` Stefan Roese
2022-08-30 11:53 ` [PATCH 4/6] arm: mvebu: dts: Makefile: Compile Armada 375 dtb in a separate step Stefan Roese
2022-08-30 11:53 ` [PATCH 5/6] arm: mvebu: dts: armada-375.dtsi: Add timer0 & timer1 Stefan Roese
2022-08-30 11:53 ` [PATCH 6/6] arm: mvebu: dts: mvebu-u-boot.dtsi: Add "u-boot, dm-pre-reloc" to timer DT node Stefan Roese
2022-08-30 22:15 ` [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards Tony Dinh
2022-08-31  5:02   ` Stefan Roese
2022-08-31  5:08     ` Stefan Roese
2022-08-31  6:12       ` Stefan Roese
2022-08-31  6:45         ` Tony Dinh
2022-08-31  6:30       ` Tony Dinh [this message]
2022-08-31  7:22         ` Stefan Roese
2022-08-31 15:08           ` Tony Dinh
2022-08-31 21:53             ` Tony Dinh
2022-09-01  1:38               ` Tony Dinh
2022-09-01  2:27                 ` Simon Glass
2022-09-01  7:39                   ` Tony Dinh
2022-09-01  9:27                     ` Stefan Roese
2022-09-01 11:52                       ` Stefan Herbrechtsmeier
2022-09-02  5:38                         ` Stefan Roese
2022-09-01 14:34                       ` Simon Glass
2022-09-01 23:46                         ` Tony Dinh
2022-09-02  2:51                           ` Tony Dinh
2022-09-02  3:49                             ` Tony Dinh
2022-09-16  4:34 Stefan Roese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJaLiFzNpnEM3xRqxnU-xXQMVCVUM7ZyDjQ+=qDKnw=HhEWWug@mail.gmail.com' \
    --to=mibodhi@gmail.com \
    --cc=michael@walle.cc \
    --cc=pali@kernel.org \
    --cc=sr@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.