+ Rob On Wed, May 08, 2019 at 11:05:29PM +0000, Vladimir Oltean wrote: > On 5/9/19 1:55 AM, Tom Rini wrote: > > On Wed, May 08, 2019 at 10:52:28PM +0000, Vladimir Oltean wrote: > >> On 5/9/19 1:48 AM, Tom Rini wrote: > >>> On Wed, May 08, 2019 at 10:45:50PM +0000, Vladimir Oltean wrote: > >>>> On 5/9/19 1:42 AM, Tom Rini wrote: > >>>>> On Wed, May 08, 2019 at 10:40:57PM +0000, Vladimir Oltean wrote: > >>>>>> On 5/9/19 1:24 AM, Joe Hershberger wrote: > >>>>>>> On Tue, May 7, 2019 at 5:15 PM Joe Hershberger > >>>>>>> <joe.hershber...@ni.com> wrote: > >>>>>>>> > >>>>>>>> Hi Tom, > >>>>>>>> > >>>>>>>> The following changes since commit > >>>>>>>> 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > >>>>>>>> > >>>>>>>> I rebased on your master and built for BB Black. DHCP seems to work > >>>>>>>> fine. > >>>>>>>> MLO also now fits again. > >>>>>>>> > >>>>>>>> Merge branch 'master' of git://git.denx.de/u-boot-sh > >>>>>>>> (2019-05-07 09:38:00 -0400) > >>>>>>>> > >>>>>>>> are available in the git repository at: > >>>>>>>> > >>>>>>>> git://git.denx.de/u-boot-net.git master > >>>>>>>> > >>>>>>>> for you to fetch changes up to > >>>>>>>> 8d0c6858455e89b089222a08d55ff711681ca011: > >>>>>>>> > >>>>>>>> net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 > >>>>>>>> 14:51:55 -0500) > >>>>>>>> > >>>>>>>> ---------------------------------------------------------------- > >>>>>>>> Carlo Caione (4): > >>>>>>>> net: phy: Add generic helpers to access MMD PHY registers > >>>>>>>> net: phy: ti: use generic helpers to access MMD registers > >>>>>>>> cmd: mdio: Switch to generic helpers when accessing the > >>>>>>>> registers > >>>>>>>> net: phy: realtek: Introduce quirk to mark RXC not > >>>>>>>> stoppable > >>>>>>>> > >>>>>>>> James Byrne (2): > >>>>>>>> net: phy: micrel: Use correct skew values on KSZ9021 > >>>>>>>> net: phy: micrel: Find Micrel PHY node correctly > >>>>>>>> > >>>>>>>> Murali Karicheri (2): > >>>>>>>> ARM: k2g-gp-evm: update to rgmii pinmux configuration > >>>>>>>> ARM: k2g-ice: Add pinmux support for rgmii interface > >>>>>>>> > >>>>>>>> Pankaj Bansal (1): > >>>>>>>> drivers: net: ldpaa_eth: fix resource leak > >>>>>>>> > >>>>>>>> Siva Durga Prasad Paladugu (2): > >>>>>>>> net: phy: Reloc next and prev pointers inside phy_drivers > >>>>>>>> net: phy: Fix return value check phy_probe > >>>>>>>> > >>>>>>>> Valentin-catalin Neacsu (1): > >>>>>>>> net: phy: aquantia: Set only autoneg on in register 4.c441 > >>>>>>>> > >>>>>>>> Vladimir Oltean (6): > >>>>>>>> net: phy: ar803x: Address packet drops at low traffic rate > >>>>>>>> due to SmartEEE feature > >>>>>>>> net: phy: ar803x: Make RGMII Tx delays actually > >>>>>>>> configurable for AR8035 > >>>>>>>> net: phy: ar803x: Use common functions for RGMII internal > >>>>>>>> delays > >>>>>>>> net: phy: ar803x: Clarify the configuration of the CLK_25M > >>>>>>>> output pin > >>>>>>>> net: phy: ar803x: Explicitly disable RGMII delays > >>>>>>> > >>>>>>> Tom, this [1] is the patch that is breaking the evm. It doesn't affect > >>>>>>> BB Black because it uses an SMSC phy, where as this evm uses an > >>>>>>> AR8031/AR8033. > >>>>>>> > >>>>>>> Is it possible the device tree [2] is wrong for the board? It lists > >>>>>>> 'phy-mode = "rgmii-txid";', so that means that with this patch the RX > >>>>>>> delay is now being disabled. > >>>>>>> > >>>>>>> Any thoughts, Vladimir? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> -Joe > >>>>>>> > >>>>>>> [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays" > >>>>>>> [2] arch/arm/dts/am335x-evm.dts > >>>>>>> > >>>>>>>> net: phy: ar803x: Clarify the intention of ar8021_config > >>>>>>>> > >>>>>>>> arch/arm/dts/sama5d3xcm.dtsi | 32 +++--- > >>>>>>>> arch/arm/dts/sama5d3xcm_cmp.dtsi | 32 +++--- > >>>>>>>> arch/arm/dts/socfpga_arria5_socdk.dts | 4 +- > >>>>>>>> arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +- > >>>>>>>> arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +- > >>>>>>>> arch/arm/dts/socfpga_cyclone5_sockit.dts | 4 +- > >>>>>>>> arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +- > >>>>>>>> board/ti/ks2_evm/mux-k2g.h | 36 +++---- > >>>>>>>> cmd/mdio.c | 27 +++-- > >>>>>>>> doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 +++++ > >>>>>>>> drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + > >>>>>>>> drivers/net/phy/Kconfig | 41 ++++++++ > >>>>>>>> drivers/net/phy/aquantia.c | 7 +- > >>>>>>>> drivers/net/phy/atheros.c | 128 > >>>>>>>> ++++++++++++++++------- > >>>>>>>> drivers/net/phy/micrel_ksz90x1.c | 24 ++++- > >>>>>>>> drivers/net/phy/phy.c | 21 +++- > >>>>>>>> drivers/net/phy/realtek.c | 19 ++++ > >>>>>>>> drivers/net/phy/ti.c | 130 > >>>>>>>> +++++------------------- > >>>>>>>> include/phy.h | 70 > >>>>>>>> +++++++++++++ > >>>>>>>> 19 files changed, 394 insertions(+), 221 deletions(-) > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>>> -Joe > >>>>>>>> _______________________________________________ > >>>>>>>> U-Boot mailing list > >>>>>>>> U-Boot@lists.denx.de > >>>>>>>> https://lists.denx.de/listinfo/u-boot > >>>>>>> > >>>>>> > >>>>>> Hi Joe, Tom, > >>>>>> > >>>>>> It sounds like what Joe pointed to (my patch) has a high chance of > >>>>>> causing link failure. > >>>>>> If the board is relying on RX delays in the Atheros PHY to ensure > >>>>>> correct RGMII timing budget, then for sure it was working before and > >>>>>> now > >>>>>> it is broken. In that case, it was working by mistake; the DT blob is > >>>>>> broken and should be corrected. > >>>>>> Sorry for the trouble this has caused. > >>>>> > >>>>> How is this handled in the Linux kernel and/or why doesn't it fail > >>>>> there? > >>>> > >>>> On the latest net-next, it's handled the same: disable everything and > >>>> enable only what's specified in phy-mode. I didn't keep track of older > >>>> versions. > >>> > >>> So you would expect the network to be broken on net-next with this DTS? > >>> Because that's not allowed... > >>> > >> > >> Yes, if it's the same problem, the behavior should be the same. > >> I see net-next is only rejecting the bad DT since 2019-02-21: > >> https://patchwork.kernel.org/patch/10819279/ > >> So it depends when you checked it last time. > > > > I'll see about testing eth in Linux with net-next tomorrow, but, uh, is > > there some work-around for the DTS so that ethernet works? > > Work-around in Linux or in U-boot? > U-boot can fix up the DT for Linux and replace "rgmii-txid" with > "rgmii-id", whereas neither Linux nor U-boot can do anything for > themselves except either load a correct DT blob, or not use (revert, not > upgrade to, etc) the enforcing patch. > > > You cannot break existing DTs > RGMII delay breakages happen all the time. To play the devil's advocate, > protecting against them should be done by observing the semantics > described in the devicetree/bindings document. > If you follow Linux net-next, a breakage for RTL8211F is planned out > right as we speak. > > But let's wait until we know for sure that this is what's causing the > issues.
OK, so net-next works. Looking harder that's because of: commit 37685f6a63eeca2135d1f704e7638409a071b1f6 Author: Peter Ujfalusi <peter.ujfal...@ti.com> Date: Tue Feb 19 08:46:33 2019 -0800 ARM: dts: am335x-evm: Fix PHY mode for ethernet which changes: &cpsw_emac0 { phy-handle = <ðphy0>; - phy-mode = "rgmii-txid"; + phy-mode = "rgmii-id"; }; Which explains why things work but I still cannot believe that despite "DT is ABI" and "You cannot break existing DT binaries" we're apparently breaking existing DT binaries. -- Tom
signature.asc
Description: PGP signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot