[U-Boot] fighting with unreliable designware-based 1G debug port

[rpjday at crashcourse.ca]

   i've just been handed an issue regarding a modified version of
u-boot v2015.07 and an unreliable designware MAC i'm hoping someone
can give me some guidance on while i continue to dig through the code
and continue testing.

   ARM-based target board has, among other things, an ethernet debug
port that is used for downloading and flashing firmware images while
in u-boot. problem is that, after coming up in u-boot, the debug port
is totally inoperative anywhere from 1/3 to 1/2 of the time
(reportedly no packet traffic at all). if one resets a few times,
eventually the port is operational. there is no apparent pattern, and
no predictable number of retries until the port works.

   for the testers, i configured u-boot to include the mdio command to
let them poke around, then went to the DW data sheet, where i found
the following in the GMAC register map:

   reg 48: 0x00C0        AN Control Register
   reg 49: 0x00C4        AN Status Register

further down in the data sheet, a couple useful bits from the status
register:

   5     ANC     Auto-Negotiation Complete
   2     LS      Link Status

   one of the testers, armed with this information and an ability to
poke around the registers, *assures* me that there is a direct
correlation between the debug port working, and those two bits from
the status register both being set to one. both one -- working. both
zero -- dead. given my assumption that those two bits simply display
the current situation (you can't just set them), this suggests that
*something* related to the dwmac is not being initialized properly
when u-boot comes up.

i can also see register:

   reg 54: 0x00D8        SGMII/RGMII/SMII Control and Status Register

but have yet to dig into that; that's today's project.

   there is, AFAICT, a single line change to the v2015.07
designware.c file for this target board, down around line 267
(clearly modifying settings in the AN control register):

     ... snip ...
     #ifdef CONFIG_DW_AXI_BURST_LEN
         writel((CONFIG_DW_AXI_BURST_LEN & 0x1FF >> 1), &dma_p->axibus);
     #endif

          * Enable Auto-Negotiation and External loopback (same way as
          * linux driver does it) to get this driver to work.
          */

====>   writel(readl((u32)mac_p + 0xc0) | (1<<12) | (1<<14),  
(u32)mac_p + 0xc0);

         /* Start up the PHY */
         ret = phy_startup(priv->phydev);
     ... snip ...

   the line marked "====>" is the line added to the source file. from
the data sheet, the two bits being set in the AN control register are:

   14    ELE     loopback enable
   12    ANE     auto-negotiation enable

despite the comment that that line is necessary to get the driver to
work, it is still unreliable as i've already described.

   finally, the configuration for this board does *not* include
CONFIG_RESET_PHY_R, so there is no invocation of a board-specific
reset_phy() routine in common/board_r.c:

   #ifdef CONFIG_CMD_NET
   static int initr_net(void)
   {
         puts("Net:   ");
         eth_initialize();
   #if defined(CONFIG_RESET_PHY_R)        <=== NOT configured
         debug("Reset Ethernet PHY\n");
         reset_phy();
   #endif
         return 0;
   }
   #endif

which makes me wonder if there *should* be a reset_phy() routine
defined for this board (whatever it might need to do).

   bottom line: has anyone else had this sort of maddeningly unreliable
behaviour with a designware MAC? have there been any bug fixes since
v2015.07 that might be applicable here? (i'm about to dig into the git
log to see what's happened since then.) does that single line change
to designware.c to set ELE and ANE in the AN control register look
familiar to anyone, as in, has anyone else needed to do something
similar?

   totally open to advice here.

rday