On Tue, 26 Feb 2008 21:32:30 -0500
Jerry Van Baren <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> ---
>
> 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
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/u-boot-users
