Messages in this thread | | | From | Andy Duan <> | Subject | RE: [EXT] Re: [PATCH v4 2/2] ARM: imx6plus: enable internal routing of clk_enet_ref where possible | Date | Tue, 30 Jun 2020 06:36:39 +0000 |
| |
From: Sven Van Asbroeck <thesven73@gmail.com> Sent: Monday, June 29, 2020 10:37 PM > On Mon, Jun 29, 2020 at 10:26 AM Fabio Estevam <festevam@gmail.com> > wrote: > > > > Just tested 5.4.24_2.1.0 on an imx6qp sabresd and DHCP also fails there. > > I think I discovered the problem ! > > When I compare the sabresd devicetree on mainline with the actual sabresd > schematics, the devicetree is incorrect ! Things still work, but only by > accident. > > The sabresd has an AR8131 PHY, which generates the enet ref clock, not the > imx6. So on the schematic we see that the clock output of the PHY is wired to > imx6 ENET_REF_CLK, so it can be used as a clock source. And GPIO_16 is > disconnected, as it should, because the imx6 is not generating the ref clk. > > But the devicetree is written as if the imx6 is providing the clock ! See > here: > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr > ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6 > %23n513&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d > 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 > C0%7C637290382588751887&sdata=hCRNGa9WrQzQ0XYwR%2FQTQ8h > jY7CDHjhIbXr0L33fr%2Bc%3D&reserved=0 > > Also there is no override of the fec PTP clock: > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Ftr > ee%2Farch%2Farm%2Fboot%2Fdts%2Fimx6qdl-sabresd.dtsi%3Fh%3Dv5.7.6 > %23n202&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d > 8e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7 > C0%7C637290382588751887&sdata=qOfiLs%2FGi01h9hSA787PHfGxTN > bfYWFXVA3IhUB553Q%3D&reserved=0 > > Although Shawn's mainline patch mandates this? > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.ker > nel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fstable%2Flinux.git%2Fco > mmit%2F%3Fh%3Dv5.7.6%26id%3D810c0ca879098a993e2ce0a190d24d11c > 17df748&data=02%7C01%7Cfugang.duan%40nxp.com%7C16c43e8d9d8 > e4ff0b9ee08d81c39f7f2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C > 0%7C637290382588751887&sdata=3PiAnDlxO8iqsVR6YQWjCk1xsg8iW > RK8TSGee4LhkjI%3D&reserved=0 > > This will work, but only by accident. So on a plus, when we > (incorrectly) switch the > bypass bit on, things stop working.
Fabio, our QA double verify 5.4.24_2.1.0, no matter SD boot or tftp/nfs boot, both work fine on i.MX6QP sabresd board, please double check your environment.
Sven, no matter PHY supply 125Mhz clock to pad or not, GPR5[9] is to select RGMII gtx clock source from: - 0 Clock from pad - 1 Clock from PLL
Since i.MX6QP can internally supply clock to MAC, we can set GPR5[9] bit by default.
| |