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 E13D0C00144 for ; Mon, 1 Aug 2022 13:32:09 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id C2F8684005; Mon, 1 Aug 2022 15:32:07 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=kernel.org header.i=@kernel.org header.b="BNsDYsIO"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DED1783E4C; Mon, 1 Aug 2022 15:32:06 +0200 (CEST) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 6B3B383E4C for ; Mon, 1 Aug 2022 15:32:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=kernel.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=pali@kernel.org Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id F06BD612D4; Mon, 1 Aug 2022 13:32:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A3A2C433C1; Mon, 1 Aug 2022 13:32:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659360722; bh=jJ1v56NFKxE7wJodq42lr2P8TOUu54ckonvb2gwZoyo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BNsDYsIOrWEi4khSwO1+fwi9LbutYnVLom/p31mhSGf9JKpIJRkRLEC/R+KZxiYiL dP9iEv+o9yb5Yrx3EwC5F0XMivBGxJTgXi0jq9Q7LYwYW8rwTFCsPdfeJVmFN7aOec 09VfMQpKKRaWEn1Xf3ctFOlBHZBcDao/SKfv0yX+7vJvW5pCzfP+Cb9MLVUxqisBdh EZYNjFS49MbpjtCnXJJRKDC2uoXcXcyGymC+6g/cSp82JDXNghQrJs+YSyLohiz8XT ATlfoOD2N3mvX8fhZXuNjgIJG4zkXEWi2GOyGe3dX0QLDRnOYV/xzho1B6Vq3Nehvb A5tjWalSYKhJA== Received: by pali.im (Postfix) id C56E8CD7; Mon, 1 Aug 2022 15:31:59 +0200 (CEST) From: =?UTF-8?q?Pali=20Roh=C3=A1r?= To: "Peng Fan (OSS)" Cc: Tom Rini , u-boot@lists.denx.de Subject: [PATCH v2 2/4] board: freescale: p1_p2_rdb_pc: Add workaround for non-working watchdog Date: Mon, 1 Aug 2022 15:31:44 +0200 Message-Id: <20220801133146.11481-2-pali@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20220801133146.11481-1-pali@kernel.org> References: <20220501122314.32626-1-pali@kernel.org> <20220801133146.11481-1-pali@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 If watchdog timer was already set to non-disabled value then it means that watchdog timer was already activated, has already expired and caused CPU reset. If this happened then due to CPLD firmware bug, writing to wd_cfg register has no effect and therefore it is not possible to reactivate watchdog timer again. Watchdog starts working again after CPU reset via non-watchdog method. Implement this workaround (reset CPU when it was reset by watchdog) to make watchdog usable again. Watchdog timer logic on these P1/P2 RDB boards is connected to CPLD, not to SoC itself. Note that reset does not occur immediately after calling do_reset(), but after few ms later as real reset is done by CPLD. So it is normal that function do_reset() returns. Therefore hangs after calling do_reset() to prevent CPU execution of the rest U-Boot code. Signed-off-by: Pali Rohár --- Changes in v2: * Call eieio() before do_reset() to ensure that all IO operations completes * Hang after calling do_reset() as reset does not occur immediately. --- board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c index 84e1d65cdb1f..16224752adb1 100644 --- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c +++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c @@ -92,6 +92,7 @@ void board_reset(void) void board_cpld_init(void) { struct cpld_data *cpld_data = (void *)(CONFIG_SYS_CPLD_BASE); + u8 prev_wd_cfg = in_8(&cpld_data->wd_cfg); out_8(&cpld_data->wd_cfg, CPLD_WD_CFG); out_8(&cpld_data->status_led, CPLD_STATUS_LED); @@ -111,6 +112,26 @@ void board_cpld_init(void) * and it has to be done in 100ms since the last start of reset. */ out_8(&cpld_data->system_rst, CPLD_SYS_RST); + + /* + * If watchdog timer was already set to non-disabled value then it means + * that watchdog timer was already activated, has already expired and + * caused CPU reset. If this happened then due to CPLD firmware bug, + * writing to wd_cfg register has no effect and therefore it is not + * possible to reactivate watchdog timer again. Also if CPU was reset + * via watchdog then some peripherals like i2c do not work. Watchdog and + * i2c start working again after CPU reset via non-watchdog method. + * + * So in case watchdog timer register in CPLD was already enabled then + * disable it in CPLD and reset CPU which cause new boot. Watchdog timer + * is disabled few lines above, after reading CPLD previous value. + * This logic (disabling timer before reset) prevents reboot loop. + */ + if (prev_wd_cfg != CPLD_WD_CFG) { + eieio(); + do_reset(NULL, 0, 0, NULL); + while (1); /* do_reset() does not occur immediately */ + } } void board_gpio_init(void) -- 2.20.1