[U-Boot-Users] [PATCH] Fix mpc8360emds board hang on second network operation

[Kim Phillips]

On Tue, 26 Feb 2008 21:32:30 -0500
Jerry Van Baren <gvb.uboot at gmail.com> wrote:

> The changeset that causes my problems is ee62ed32
> 
> The original code calls init_phy(dev) followed by phy_change(dev) *once*
> during PHY initialization.  The part of changeset that appears to cause
> my problems is calling phy_change(dev) every time uec_init() is called.

phy_change is there so that u-boot will renegotiate the link in case
its state has changed since the last networking command (this was the
original complaint that warranted the ee62ed32 patch, iirc).

> On my mpc8360emds board, without this change the second command that does
> a network operation hangs the board (requires a hard reset to recover).
> Example failure sequence is two "ping" commands: the first works, the
> second hangs the board.
> 
> This also speeds up the network initialization and doesn't cause a packet
> error on the first TFTP packet.
> 
> Signed-off-by: Gerald Van Baren <vanbaren at cideas.com>
> ---
> 
> Kim:
> 
> Does this make any sense?  Any thoughts why it isn't causing problems
> for you?  It makes all the difference in the world for me.
> 
> One other interesting sequence difference with patch ee62ed32 is that
> the ethernet MAC address is set on every uec_init() call.  The following
> code was inside the "if (uec->the_first_run == 0)" conditional, now it
> is outside the conditional and thus run on every uec_init() call.
> Functionally, it doesn't seem to matter for me either way, but seems
> unnecessary.
> 
> +       /* Set up the MAC address */
> +       if (dev->enetaddr[0] & 0x01) {
> +               printf("%s: MacAddress is multcast address\n",
> +                        __FUNCTION__);
> +               return -1;
> +       }
> +       uec_set_mac_address(uec, dev->enetaddr);
> 

this was done in order to be able to re-set eth[1]addr between
networking commands, and have the new eth[1]addr value actually
programmed on the interface.

I've tested 100BT, and experience the same as you.  The reason u-boot
doesn't recover is that i is not incremented in genmii_update_link(),
but adding that doesn't resolve the problem.  I believe the PHY status
is being incorrectly determined somehow - these PHYs are really
finicky :/.

Kim