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 X-Spam-Level: X-Spam-Status: No, score=-10.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_2 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28E36C47096 for ; Thu, 3 Jun 2021 09:05:13 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 52F54613AA for ; Thu, 3 Jun 2021 09:05:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 52F54613AA Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 40F0F82F8E; Thu, 3 Jun 2021 11:05:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 23F8E82F93; Thu, 3 Jun 2021 11:05:08 +0200 (CEST) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by phobos.denx.de (Postfix) with ESMTP id E613E82E52 for ; Thu, 3 Jun 2021 11:05:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=andre.przywara@arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 40FDE11FB; Thu, 3 Jun 2021 02:05:00 -0700 (PDT) Received: from slackpad.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 35F5C3F774; Thu, 3 Jun 2021 02:04:59 -0700 (PDT) Date: Thu, 3 Jun 2021 10:04:36 +0100 From: Andre Przywara To: Heinrich Schuchardt Cc: Ramon Fried , Joe Hershberger , Jagan Teki , U-Boot Mailing List , Andreas Rehn Subject: Re: [BUG] network is broken on Orange Pi PC Message-ID: <20210603100351.4b45ed0a@slackpad.fritz.box> In-Reply-To: References: Organization: Arm Ltd. X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.31; x86_64-slackware-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 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.102.4 at phobos.denx.de X-Virus-Status: Clean On Thu, 3 Jun 2021 09:46:48 +0200 Heinrich Schuchardt wrote: Hi Heinrich, > On 6/2/21 3:08 PM, Ramon Fried wrote: > > On Tue, Jun 1, 2021 at 12:35 AM Heinrich Schuchardt wrote: > >> > >> Dear all, > >> > >> network is broken in U-Boot on orangepi_pc_defconfig: Thanks for the report! > >> > >> U-Boot 2021.07-rc3-00059-gd8729a114e (May 31 2021 - 21:26:56 +0000) > >> Allwinner Technology > >> eth0: ethernet@1c30000 > >> => dhcp > >> sun8i_emac_eth_start: Timeout > >> > >> Best regards > >> > >> Heinrich > >> > > Hi Heinrich, I don't have OrangePi. can you bisect and tell me when it broke ? > > Thanks. > > Ramon. > > > > Git bisect points to: > > commit 4f0278dac56a658ef1e0967fec0bb95372a875bd > Author: Andre Przywara > Date: Mon Jul 6 01:40:45 2020 +0100 > > net: sun8i-emac: Lower MDIO frequency > > Reverting the patch solves the problem for the OrangePi PC. > > According to the commit message the change was only needed for needed > for external PHYs. The external PHY on the Pine64 (non-plus) was the trigger, however both the manual and the Linux driver point to that we definitely need a higher divider. From what I can see, AHB2 (the EMAC clock) runs at 200 MHz (AHB2=AHB1/1=PLL6/3=200 MHz). So just having "/ 16" results in 12.5 MHz MDIO frequency. Can you check whether any other divider values fix this for you as well? > Can't we let the change depend on priv->use_internal_phy? > > diff --git a/drivers/net/sun8i_emac.c b/drivers/net/sun8i_emac.c > index 5a1b38bf80..d7553fe163 100644 > --- a/drivers/net/sun8i_emac.c > +++ b/drivers/net/sun8i_emac.c > @@ -211,7 +211,9 @@ static int sun8i_mdio_read(struct mii_dev *bus, int > addr, int devad, int reg) > * The EMAC clock is either 200 or 300 MHz, so we need a divider > * of 128 to get the MDIO frequency below the required 2.5 MHz. > */ > - mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << > MDIO_CMD_MII_CLK_CSR_SHIFT; > + if (!priv->use_internal_phy) > + mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << > + MDIO_CMD_MII_CLK_CSR_SHIFT; > > mii_cmd |= MDIO_CMD_MII_BUSY; > > @@ -242,7 +244,9 @@ static int sun8i_mdio_write(struct mii_dev *bus, int > addr, int devad, int reg, > * The EMAC clock is either 200 or 300 MHz, so we need a divider > * of 128 to get the MDIO frequency below the required 2.5 MHz. > */ > - mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << > MDIO_CMD_MII_CLK_CSR_SHIFT; > + if (!priv->use_internal_phy) > + mii_cmd |= MDIO_CMD_MII_CLK_CSR_DIV_128 << > + MDIO_CMD_MII_CLK_CSR_SHIFT; > > mii_cmd |= MDIO_CMD_MII_WRITE; > mii_cmd |= MDIO_CMD_MII_BUSY; > > Best regards > > Heinrich > > I would assume the problem hits all H3 boards. And that's the confusing part: it does not. I tested this on my OrangePi Zero (H2+ with internal PHY), both back then with the original MDIO frequency patch and also now after your report. It always worked reliably for me. Also: I am still puzzled how one influences the other: The error you get is from the *MAC* soft reset: I would think this is an independent operation from any communication attempts with the PHY. There is this thread here about the same symptom on a V3s: https://lists.denx.de/pipermail/u-boot/2021-May/450315.html v2 of this original patch (in the same thread) proposes some other solution, which I am also not very happy with. But just to get some more data points: can you check whether skipping the soft reset fixes this for you? I will have a closer look tonight to check the order of soft reset and PHY communication. Maybe we should only do the soft reset *once* when the MAC probes, and not on every .start call? Thanks, Andre