From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 6BE4CECAAD3 for ; Wed, 31 Aug 2022 07:22:45 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id DA45784144; Wed, 31 Aug 2022 09:22:42 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1661930563; bh=M485XU1w2+A7vU+YDNhAvawt9z7n1HPrIKYRyDQvlQM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=rHs+A33aQ9t/QaVcJxLszBeOXfH+NW+KCDBgc84P+Lyx9lNU+NXQERm80yJvFdpAe FLImx4eHi6emiPxjRDs+VWHQjsiTvH1VoS//lX+6N8bPWXVEyVvQ9slExpZPNWeoph Q+mpRqnyGvdB2wQw+zHnB8BmzrY8GC19jvo1OmvZ27OO/jMoq+NPVnllcahw+Zd8Et 4utPlsvNmfKQHRI+AtUNv4+K87BF6rCnhr/2sgfqQpFmlyYPFVZmY5ZJRZM/RcmfJT c1wnkULUyeyvoVDy70eswzSk4ydEsn3PvB4c0rnRkpA/7S/PjH1rweQ5pKvU/kBRxv knCNv8zbltMNw== Received: by phobos.denx.de (Postfix, from userid 109) id 4706C8489F; Wed, 31 Aug 2022 09:22:41 +0200 (CEST) Received: from mout-u-204.mailbox.org (mout-u-204.mailbox.org [IPv6:2001:67c:2050:101:465::204]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 98DE980361 for ; Wed, 31 Aug 2022 09:22:38 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=sr@denx.de Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-u-204.mailbox.org (Postfix) with ESMTPS id 4MHbH05CbJz9sQX; Wed, 31 Aug 2022 09:22:36 +0200 (CEST) Message-ID: Date: Wed, 31 Aug 2022 09:22:35 +0200 MIME-Version: 1.0 Subject: Re: [PATCH 0/6] Enable CONFIG_TIMER for all Kirwood / MVEBU boards Content-Language: en-US To: Tony Dinh Cc: U-Boot Mailing List , =?UTF-8?Q?Pali_Roh=c3=a1r?= , Michael Walle References: <20220830115317.410812-1-sr@denx.de> <282eefe1-58d4-89cd-f940-2428bdd42b59@denx.de> From: Stefan Roese In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4MHbH05CbJz9sQX X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean Hi Tony, On 31.08.22 08:30, Tony Dinh wrote: > Hi Stefan, > > On Tue, Aug 30, 2022 at 10:08 PM Stefan Roese 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 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 >>>> >>> >>> 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 >>>> >>>> >>>> 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. > > > 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 > > 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... > > > > > 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. Frankly I don't really understand the problem you describe above. What do you mean with "timer instance"? get_timer(0) will return different values, depending on when you call this function. So where exactly is the problem with the 2nd "sleep 10" above? Thanks, Stefan