Designware MAC reset timeout after Linux reboot
abbotti at mev.co.uk
Mon Nov 7 09:56:51 PST 2016
I'm using barebox 2016.10.0 with some custom BSP patches for my Cyclone
V socfpga based board. I've noticed that after issuing a reboot in
Linux, followed by an 'ifup eth0' command in barebox, I get a "eth0: MAC
reset timeout" error, which causes dwc_ether_init() to bail out early.
My Linux kernel is Linux 4.1.17, plus LTSI-4.1.17 patches, plus Altera
patches from linux-socfpga kernel branch socfpga-4.1.22-ltsi, in that
order (git rebase is a wonderful thing!).
Socfpga has two Ethernet MAC controllers. Like several other Cyclone V
boards, my board's device tree disables the first one (&gmac0) and
aliases ethernet0 to the second one (&gmac1).
I don't need the ethernet to work to boot Linux, and Linux manages to
reinitialize the ethernet okay, so it's more of a inconvenience to me
than a show-stopper - I just need to power-cycle the board if I want
ethernet access in barebox.
I am aware of Trent Piepho's patch (commit
f0ae0c33f52ced89da080673ca89a3c5f2ea70e6) which brings the PHY out of
power-down mode before resetting the MAC DMA controller. In fact, the
PHY doesn't seem to be in power-down mode in my case, as the value read
from the MII_BMCR in phy_resume() is 0x1140 (BMCR_ANENABLE |
BMCR_FULLDPLX | BMCR_SPEED1000).
There must be something else stopping the software reset of the MAC
completing successfully, but I'm not sure what. The Cyclone V Hard
Processor System Technical Reference Manual says this about the MAC DMA
software reset bit:
| Note: * The Software reset system is driven only by this bit. *
| The reset operation is completed only when all resets in all
| active clock domains are de-asserted. Therefore, it is
| essential that all the PHY inputs clocks (applicable for the
| selected PHY interface) are present for the software reset
Perhaps the timeout isn't waiting long enough. If I interrupt the 'ifup
eth0' command and display the approriate 'Bus_Mode' register
(0xff703000) with the 'md' command, the DMAMAC_SRST bit (bit 0) is no
barebox at xxxx:/ md -l 0xff703000+4
I tried porting over a few old patches from the U-Boot version of the
driver, in particular these two patches for the mac_reset() function:
They didn't solve my problem, but I'll send those two patches and a
couple of others adapted from the U-Boot version of the driver to the
Sorry for waffling on for so long. Thanks for your time, and any
helpful hints you can offer! On the whole, hacking PTXdist and barebox
is a much more pleasant experience than hacking U-Boot and Yocto!
-=( Ian Abbott @ MEV Ltd. E-mail: <abbotti at mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
More information about the barebox