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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
