Hi, on a custom board based on a i.MX6UL using barebox v2020.08.1 'ifup eth0' invoked after 'ifdown eth0' stucks forever. Have you ever experienced something similar? Snippet from my device tree: &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-mode = "rmii"; phy-handle = <ðphy1>; status = "okay"; phy-reset-gpios = <&gpio1 23 GPIO_ACTIVE_LOW>; phy-reset-duration = <1>; mdio { #address-cells = <1>; #size-cells = <0>; clock-frequency = <5000000>; ethphy1: ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0>; max-speed = <100>; interrupt-parent = <&gpio1>; interrupts = <22 IRQ_TYPE_LEVEL_LOW>; }; }; }; pinctrl_enet1: enet1grp { fsl,pins = < MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0 MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0 MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0 MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0 MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031 MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0 MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0 MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0 MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0 MX6UL_PAD_UART2_RTS_B__GPIO1_IO23 0x1b0b0 MX6UL_PAD_UART2_CTS_B__GPIO1_IO22 0x1b0b0 >; }; Best, Stefano _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Hi Stefano, On Mon, Oct 05, 2020 at 02:43:15PM +0200, Manni Stefano wrote: > Hi, > > on a custom board based on a i.MX6UL using barebox v2020.08.1 'ifup eth0' > invoked after 'ifdown eth0' stucks forever. > > Have you ever experienced something similar? I can confirm the same happens here on an i.MX6q board on current master. I don't know what's happening here. The last thing I see is that fec_tx_task_enable() is entered. Strange enough the same works on i.MX53 whereas on i.MX8M I get "ERROR: eth0: transmission timeout" on the second ifup. This is really strange. It seems fec_tx_task_enable() brings down the whole SoC, but on the other hand the FEC works properly in a chainloaded barebox, which should - from the view of the ethernet controller - be the same as a repeated ifup/ifdown sequence. I have no idea what is going wrong here. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
On Mo, 2020-10-05 at 17:17 +0200, Sascha Hauer wrote: > Hi Stefano, > > On Mon, Oct 05, 2020 at 02:43:15PM +0200, Manni Stefano wrote: > > Hi, > > > > on a custom board based on a i.MX6UL using barebox v2020.08.1 'ifup eth0' > > invoked after 'ifdown eth0' stucks forever. > > > > Have you ever experienced something similar? > > I can confirm the same happens here on an i.MX6q board on current > master. I don't know what's happening here. The last thing I see is that > fec_tx_task_enable() is entered. Strange enough the same works on i.MX53 > whereas on i.MX8M I get "ERROR: eth0: transmission timeout" on the > second ifup. > > This is really strange. It seems fec_tx_task_enable() brings down the > whole SoC, but on the other hand the FEC works properly in a chainloaded > barebox, which should - from the view of the ethernet controller - be > the same as a repeated ifup/ifdown sequence. There is a crucial difference between the two things: in a chainloaded Barebox we go through the FEC driver probe again, before doing the next ifup. When going through probe a full reset of the FEC peripheral is done. Regards, Lucas _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
On Tue, Oct 06, 2020 at 10:44:24AM +0200, Lucas Stach wrote: > On Mo, 2020-10-05 at 17:17 +0200, Sascha Hauer wrote: > > Hi Stefano, > > > > On Mon, Oct 05, 2020 at 02:43:15PM +0200, Manni Stefano wrote: > > > Hi, > > > > > > on a custom board based on a i.MX6UL using barebox v2020.08.1 'ifup eth0' > > > invoked after 'ifdown eth0' stucks forever. > > > > > > Have you ever experienced something similar? > > > > I can confirm the same happens here on an i.MX6q board on current > > master. I don't know what's happening here. The last thing I see is that > > fec_tx_task_enable() is entered. Strange enough the same works on i.MX53 > > whereas on i.MX8M I get "ERROR: eth0: transmission timeout" on the > > second ifup. > > > > This is really strange. It seems fec_tx_task_enable() brings down the > > whole SoC, but on the other hand the FEC works properly in a chainloaded > > barebox, which should - from the view of the ethernet controller - be > > the same as a repeated ifup/ifdown sequence. > > There is a crucial difference between the two things: in a chainloaded > Barebox we go through the FEC driver probe again, before doing the next > ifup. When going through probe a full reset of the FEC peripheral is > done. Actually I thought there is a full FEC reset in fec_halt(): writel(readl(fec->regs + FEC_X_CNTRL) | FEC_ECNTRL_RESET, fec->regs + FEC_X_CNTRL); I only saw the FEC_ECNTRL_RESET bit but didn't realize this goes to a completely unrelated register. We should have a FEC_X_CNTRL_GTS define for this. Given that, the fec_halt/fec_init path really looks quite different from the fec_probe/fec_init path. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox