[U-Boot-Users] Problems with new ethernet init on mpc8360

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Hi Kim,

I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
start up (good), but seems to cause the board to hang on the *second* 
ethernet operation.

I can cause this by doing two pings in a row: the first ping initializes 
the network and completes successfully.  The second ping hangs the 
board: it never completes.  I cannot abort it with ^C.  The only way out 
is to reset the board.

The same thing happens with two back-to-back tftp operations or a ping 
followed by a tftp operation.

If I back out the ee62ed patch (below), it "fixes" the problem.

I tried backing out some simple portions of the patch (added delays back 
in) with no success.  I've given up chasing this for tonight.  Any 
inspiration you can generate would be appreciated, I'll chase it some 
more tomorrow.

Thanks,
gvb


commit ee62ed3286f83b98b7785e0318dc6379e78f7ff6
Author: Kim Phillips <kim.phillips@freescale.com>
Date:   Tue Jan 15 14:11:00 2008 -0600

      net: reduce boot latency on QE UEC based boards

      actually polling for PHY autonegotiation to finish enables us to
remove the
      5 second boot prompt latency present on QE based boards.

      call to qe_set_mii_clk_src in init_phy, and mv call to init_phy from
      uec_initialize to uec_init by Joakim Tjernlund; autonegotiation wait
      code shamelessly stolen from tsec driver.

      also rm unused CONFIG_RMII_MODE code.

      Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
      Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
      Signed-off-by: Ben Warren <biggerbadderben@gmail.com>

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Kim Phillips]

On Mon, 25 Feb 2008 22:55:37 -0500
Jerry Van Baren <gvb.uboot@gmail.com> wrote:

> Hi Kim,
> 
> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
> start up (good), but seems to cause the board to hang on the *second* 
> ethernet operation.
> 
> I can cause this by doing two pings in a row: the first ping initializes 
> the network and completes successfully.  The second ping hangs the 
> board: it never completes.  I cannot abort it with ^C.  The only way out 
> is to reset the board.
> 
> The same thing happens with two back-to-back tftp operations or a ping 
> followed by a tftp operation.
> 
> If I back out the ee62ed patch (below), it "fixes" the problem.
> 
> I tried backing out some simple portions of the patch (added delays back 
> in) with no success.  I've given up chasing this for tonight.  Any 
> inspiration you can generate would be appreciated, I'll chase it some 
> more tomorrow.

I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.

can you provide more details about which u-boot version, what board rev
you're on, what kind of connection you're using, speed, etc.?

Kim

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Kim Phillips wrote:
> On Mon, 25 Feb 2008 22:55:37 -0500
> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> 
>> Hi Kim,
>>
>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
>> start up (good), but seems to cause the board to hang on the *second* 
>> ethernet operation.
>>
>> I can cause this by doing two pings in a row: the first ping initializes 
>> the network and completes successfully.  The second ping hangs the 
>> board: it never completes.  I cannot abort it with ^C.  The only way out 
>> is to reset the board.
>>
>> The same thing happens with two back-to-back tftp operations or a ping 
>> followed by a tftp operation.
>>
>> If I back out the ee62ed patch (below), it "fixes" the problem.
>>
>> I tried backing out some simple portions of the patch (added delays back 
>> in) with no success.  I've given up chasing this for tonight.  Any 
>> inspiration you can generate would be appreciated, I'll chase it some 
>> more tomorrow.
> 
> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
> 
> can you provide more details about which u-boot version, what board rev
> you're on, what kind of connection you're using, speed, etc.?
> 
> Kim

Hi Kim,

OK, probably operator error.  I claim to be using 1.3.2-rc2 but my 
repository clone could be introducing problems.  I'll do a clean clone 
and rebuild of u-boot, hopefully that is all it is.

It is connection is through a commercial switch, should be 100bT full 
duplex (not verified, cannot see the blinky lights from here).  I don't 
know the board rev off-hand (I'm not on-site at the moment).

=> version
U-Boot 1.3.2-rc2-g330a77f6-dirty (Feb 25 2008 - 22:21:12) MPC83XX

root:~> cat /proc/cpuinfo
processor : 0
cpu : e300c1
clock : 528.000000MHz
revision : 2.0 (pvr 8083 0020)
bogomips : 131.58
timebase : 66000000
platform : MPC836x MDS

Thanks,
gvb

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Kim Phillips wrote:
> On Mon, 25 Feb 2008 22:55:37 -0500
> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> 
>> Hi Kim,
>>
>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
>> start up (good), but seems to cause the board to hang on the *second* 
>> ethernet operation.
>>
>> I can cause this by doing two pings in a row: the first ping initializes 
>> the network and completes successfully.  The second ping hangs the 
>> board: it never completes.  I cannot abort it with ^C.  The only way out 
>> is to reset the board.
>>
>> The same thing happens with two back-to-back tftp operations or a ping 
>> followed by a tftp operation.
>>
>> If I back out the ee62ed patch (below), it "fixes" the problem.
>>
>> I tried backing out some simple portions of the patch (added delays back 
>> in) with no success.  I've given up chasing this for tonight.  Any 
>> inspiration you can generate would be appreciated, I'll chase it some 
>> more tomorrow.
> 
> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
> 
> can you provide more details about which u-boot version, what board rev
> you're on, what kind of connection you're using, speed, etc.?
> 
> Kim

OK, I confirmed it was operator error by doing a clean clone and rebuild 
of u-boot.

Sorry for the noise,
gvb

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Jerry Van Baren wrote:
> Kim Phillips wrote:
>> On Mon, 25 Feb 2008 22:55:37 -0500
>> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
>>
>>> Hi Kim,
>>>
>>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
>>> start up (good), but seems to cause the board to hang on the *second* 
>>> ethernet operation.
>>>
>>> I can cause this by doing two pings in a row: the first ping initializes 
>>> the network and completes successfully.  The second ping hangs the 
>>> board: it never completes.  I cannot abort it with ^C.  The only way out 
>>> is to reset the board.
>>>
>>> The same thing happens with two back-to-back tftp operations or a ping 
>>> followed by a tftp operation.
>>>
>>> If I back out the ee62ed patch (below), it "fixes" the problem.
>>>
>>> I tried backing out some simple portions of the patch (added delays back 
>>> in) with no success.  I've given up chasing this for tonight.  Any 
>>> inspiration you can generate would be appreciated, I'll chase it some 
>>> more tomorrow.
>> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
>>
>> can you provide more details about which u-boot version, what board rev
>> you're on, what kind of connection you're using, speed, etc.?
>>
>> Kim
> 
> OK, I confirmed it was operator error by doing a clean clone and rebuild 
> of u-boot.
> 
> Sorry for the noise,
> gvb

My bad, the noise *wasn't* noise.  What worked for me was 1.3.1 (above 
results), which initializes the ethernet on start up.  When I cloned the 
u-boot repo (or u-boot-testing), the second ping hangs the board for me.

Is the fact that I don't have a valid env a clue (I have never bothered 
to save an env)?  Hmmmm, what env variables could be messing me up?  I 
would suspect the ethernet rotation one.  I don't have the second 
etherspiggot plugged in, but that should simply fail and rotate back to 
the first etherspiggot (scratches head).

Thanks,
gvb


U-Boot 1.3.2-rc2 (Feb 26 2008 - 13:21:20) MPC83XX

Reset Status: Software Hard, External/Internal Soft, External/Internal Hard

CPU:   e300c1, MPC8360E, Rev: 12 at 528 MHz, CSB:  264 MHz
Board: Freescale MPC8360EMDS
I2C:   ready
DRAM:  256 MB (DDR1, 64-bit, ECC off)
SDRAM: 64 MB (local bus)
PCI 32bit bus on PMC1 & PMC2 &PMC3
FLASH: 16 MB
*** Warning - bad CRC, using default environment

PCI clock is 66MHz
In:    serial
Out:   serial
Err:   serial
Net:   FSL UEC0, FSL UEC1
Hit any key to stop autoboot:  0

=> set serverip 192.168.47.8 ; set ipaddr 192.168.47.214

=> ping 192.168.47.8
UEC: PHY is Marvell 88E11x1 (1410cc2)
FSL UEC0: Full Duplex
switching to rgmii 100
FSL UEC0: Speed 100BT
FSL UEC0: Link is up
Using FSL UEC0 device
host 192.168.47.8 is alive

=> ping 192.168.47.8

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Jerry Van Baren wrote:
> Jerry Van Baren wrote:
>> Kim Phillips wrote:
>>> On Mon, 25 Feb 2008 22:55:37 -0500
>>> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
>>>
>>>> Hi Kim,
>>>>
>>>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the 
>>>> start up (good), but seems to cause the board to hang on the *second* 
>>>> ethernet operation.
>>>>
>>>> I can cause this by doing two pings in a row: the first ping initializes 
>>>> the network and completes successfully.  The second ping hangs the 
>>>> board: it never completes.  I cannot abort it with ^C.  The only way out 
>>>> is to reset the board.
>>>>
>>>> The same thing happens with two back-to-back tftp operations or a ping 
>>>> followed by a tftp operation.
>>>>
>>>> If I back out the ee62ed patch (below), it "fixes" the problem.
>>>>
>>>> I tried backing out some simple portions of the patch (added delays back 
>>>> in) with no success.  I've given up chasing this for tonight.  Any 
>>>> inspiration you can generate would be appreciated, I'll chase it some 
>>>> more tomorrow.
>>> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
>>>
>>> can you provide more details about which u-boot version, what board rev
>>> you're on, what kind of connection you're using, speed, etc.?
>>>
>>> Kim
>> OK, I confirmed it was operator error by doing a clean clone and rebuild 
>> of u-boot.
>>
>> Sorry for the noise,
>> gvb
> 
> My bad, the noise *wasn't* noise.  What worked for me was 1.3.1 (above 
> results), which initializes the ethernet on start up.  When I cloned the 
> u-boot repo (or u-boot-testing), the second ping hangs the board for me.
> 
> Is the fact that I don't have a valid env a clue (I have never bothered 
> to save an env)?  Hmmmm, what env variables could be messing me up?  I 
> would suspect the ethernet rotation one.  I don't have the second 
> etherspiggot plugged in, but that should simply fail and rotate back to 
> the first etherspiggot (scratches head).
> 
> Thanks,
> gvb
> 
> 
> U-Boot 1.3.2-rc2 (Feb 26 2008 - 13:21:20) MPC83XX
> 
> Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
> 
> CPU:   e300c1, MPC8360E, Rev: 12 at 528 MHz, CSB:  264 MHz
> Board: Freescale MPC8360EMDS
> I2C:   ready
> DRAM:  256 MB (DDR1, 64-bit, ECC off)
> SDRAM: 64 MB (local bus)
> PCI 32bit bus on PMC1 & PMC2 &PMC3
> FLASH: 16 MB
> *** Warning - bad CRC, using default environment
> 
> PCI clock is 66MHz
> In:    serial
> Out:   serial
> Err:   serial
> Net:   FSL UEC0, FSL UEC1
> Hit any key to stop autoboot:  0
> 
> => set serverip 192.168.47.8 ; set ipaddr 192.168.47.214
> 
> => ping 192.168.47.8
> UEC: PHY is Marvell 88E11x1 (1410cc2)
> FSL UEC0: Full Duplex
> switching to rgmii 100
> FSL UEC0: Speed 100BT
> FSL UEC0: Link is up
> Using FSL UEC0 device
> host 192.168.47.8 is alive
> 
> => ping 192.168.47.8

Sorry, I should have included the default environment contents for 
reference:

=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath 
ip=$ipaddrr
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate 
$othbootr
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath 
ip=$ipaddrr
bootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:ef:01:01
eth1addr=00:04:9f:ef:01:02
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=1000000
ramdiskfile=ramfs.83xx
fdtaddr=400000
fdtfile=mpc8360emds.dtb
stdin=serial
stdout=serial
stderr=serial
ethact=FSL UEC0

Environment size: 979/8188 bytes

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> On Behalf Of Jerry Van Baren
> Sent: den 26 februari 2008 19:41
> To: Kim Phillips
> Cc: U-Boot Users
> Subject: Re: [U-Boot-Users] Problems with new ethernet init on mpc8360
> 
> Jerry Van Baren wrote:
> > Jerry Van Baren wrote:
> >> Kim Phillips wrote:
> >>> On Mon, 25 Feb 2008 22:55:37 -0500
> >>> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> >>>
> >>>> Hi Kim,
> >>>>
> >>>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the
> >>>> start up (good), but seems to cause the board to hang on the *second*
> >>>> ethernet operation.
> >>>>
> >>>> I can cause this by doing two pings in a row: the first ping initializes
> >>>> the network and completes successfully.  The second ping hangs the
> >>>> board: it never completes.  I cannot abort it with ^C.  The only way out
> >>>> is to reset the board.
> >>>>
> >>>> The same thing happens with two back-to-back tftp operations or a ping
> >>>> followed by a tftp operation.
> >>>>
> >>>> If I back out the ee62ed patch (below), it "fixes" the problem.
> >>>>
> >>>> I tried backing out some simple portions of the patch (added delays back
> >>>> in) with no success.  I've given up chasing this for tonight.  Any
> >>>> inspiration you can generate would be appreciated, I'll chase it some
> >>>> more tomorrow.
> >>> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
> >>>
> >>> can you provide more details about which u-boot version, what board rev
> >>> you're on, what kind of connection you're using, speed, etc.?
> >>>
> >>> Kim
> >> OK, I confirmed it was operator error by doing a clean clone and rebuild
> >> of u-boot.
> >>
> >> Sorry for the noise,
> >> gvb
> >
> > My bad, the noise *wasn't* noise.  What worked for me was 1.3.1 (above
> > results), which initializes the ethernet on start up.  When I cloned the
> > u-boot repo (or u-boot-testing), the second ping hangs the board for me.
> >
> > Is the fact that I don't have a valid env a clue (I have never bothered
> > to save an env)?  Hmmmm, what env variables could be messing me up?  I
> > would suspect the ethernet rotation one.  I don't have the second
> > etherspiggot plugged in, but that should simply fail and rotate back to
> > the first etherspiggot (scratches head).
> >
> > Thanks,
> > gvb
> >
> >
> > U-Boot 1.3.2-rc2 (Feb 26 2008 - 13:21:20) MPC83XX
> >
> > Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
> >
> > CPU:   e300c1, MPC8360E, Rev: 12 at 528 MHz, CSB:  264 MHz
> > Board: Freescale MPC8360EMDS
> > I2C:   ready
> > DRAM:  256 MB (DDR1, 64-bit, ECC off)
> > SDRAM: 64 MB (local bus)
> > PCI 32bit bus on PMC1 & PMC2 &PMC3
> > FLASH: 16 MB
> > *** Warning - bad CRC, using default environment
> >
> > PCI clock is 66MHz
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Net:   FSL UEC0, FSL UEC1
> > Hit any key to stop autoboot:  0
> >
> > => set serverip 192.168.47.8 ; set ipaddr 192.168.47.214
> >
> > => ping 192.168.47.8
> > UEC: PHY is Marvell 88E11x1 (1410cc2)
> > FSL UEC0: Full Duplex
> > switching to rgmii 100
> > FSL UEC0: Speed 100BT
> > FSL UEC0: Link is up
> > Using FSL UEC0 device
> > host 192.168.47.8 is alive
> >
> > => ping 192.168.47.8
> 
> Sorry, I should have included the default environment contents for
> reference:
> 
> => printenv
> bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> ip=$ipaddrr
> ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
> $othbootr
> nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> ip=$ipaddrr
> bootdelay=6
> baudrate=115200
> loads_echo=1
> ethaddr=00:04:9f:ef:01:01
> eth1addr=00:04:9f:ef:01:02
> loadaddr=200000
> netdev=eth0
> consoledev=ttyS0
> ramdiskaddr=1000000
> ramdiskfile=ramfs.83xx
> fdtaddr=400000
> fdtfile=mpc8360emds.dtb
> stdin=serial
> stdout=serial
> stderr=serial
> ethact=FSL UEC0
> 
> Environment size: 979/8188 bytes

Maybe you suffer from something I noticed, sometimes the master for MDIO gets
out of sync. Try this patch and see if it helps, not sure if it still applies
but that should be easy to fix up.

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Joakim Tjernlund]

> -----Original Message-----
> From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> On Behalf Of Joakim Tjernlund
> Sent: den 26 februari 2008 20:56
> To: 'Jerry Van Baren'; 'Kim Phillips'
> Cc: 'U-Boot Users'
> Subject: Re: [U-Boot-Users] Problems with new ethernet init on mpc8360
> 
> > -----Original Message-----
> > From: u-boot-users-bounces at lists.sourceforge.net [mailto:u-boot-users-bounces at lists.sourceforge.net]
> > On Behalf Of Jerry Van Baren
> > Sent: den 26 februari 2008 19:41
> > To: Kim Phillips
> > Cc: U-Boot Users
> > Subject: Re: [U-Boot-Users] Problems with new ethernet init on mpc8360
> >
> > Jerry Van Baren wrote:
> > > Jerry Van Baren wrote:
> > >> Kim Phillips wrote:
> > >>> On Mon, 25 Feb 2008 22:55:37 -0500
> > >>> Jerry Van Baren <gvb.uboot@gmail.com> wrote:
> > >>>
> > >>>> Hi Kim,
> > >>>>
> > >>>> I have a mpc8360emds eval board.  The ee62ed patch (below) speeds up the
> > >>>> start up (good), but seems to cause the board to hang on the *second*
> > >>>> ethernet operation.
> > >>>>
> > >>>> I can cause this by doing two pings in a row: the first ping initializes
> > >>>> the network and completes successfully.  The second ping hangs the
> > >>>> board: it never completes.  I cannot abort it with ^C.  The only way out
> > >>>> is to reset the board.
> > >>>>
> > >>>> The same thing happens with two back-to-back tftp operations or a ping
> > >>>> followed by a tftp operation.
> > >>>>
> > >>>> If I back out the ee62ed patch (below), it "fixes" the problem.
> > >>>>
> > >>>> I tried backing out some simple portions of the patch (added delays back
> > >>>> in) with no success.  I've given up chasing this for tonight.  Any
> > >>>> inspiration you can generate would be appreciated, I'll chase it some
> > >>>> more tomorrow.
> > >>> I verified rc2 on rev. 1.1 and 2.1 boards pings more than once.
> > >>>
> > >>> can you provide more details about which u-boot version, what board rev
> > >>> you're on, what kind of connection you're using, speed, etc.?
> > >>>
> > >>> Kim
> > >> OK, I confirmed it was operator error by doing a clean clone and rebuild
> > >> of u-boot.
> > >>
> > >> Sorry for the noise,
> > >> gvb
> > >
> > > My bad, the noise *wasn't* noise.  What worked for me was 1.3.1 (above
> > > results), which initializes the ethernet on start up.  When I cloned the
> > > u-boot repo (or u-boot-testing), the second ping hangs the board for me.
> > >
> > > Is the fact that I don't have a valid env a clue (I have never bothered
> > > to save an env)?  Hmmmm, what env variables could be messing me up?  I
> > > would suspect the ethernet rotation one.  I don't have the second
> > > etherspiggot plugged in, but that should simply fail and rotate back to
> > > the first etherspiggot (scratches head).
> > >
> > > Thanks,
> > > gvb
> > >
> > >
> > > U-Boot 1.3.2-rc2 (Feb 26 2008 - 13:21:20) MPC83XX
> > >
> > > Reset Status: Software Hard, External/Internal Soft, External/Internal Hard
> > >
> > > CPU:   e300c1, MPC8360E, Rev: 12 at 528 MHz, CSB:  264 MHz
> > > Board: Freescale MPC8360EMDS
> > > I2C:   ready
> > > DRAM:  256 MB (DDR1, 64-bit, ECC off)
> > > SDRAM: 64 MB (local bus)
> > > PCI 32bit bus on PMC1 & PMC2 &PMC3
> > > FLASH: 16 MB
> > > *** Warning - bad CRC, using default environment
> > >
> > > PCI clock is 66MHz
> > > In:    serial
> > > Out:   serial
> > > Err:   serial
> > > Net:   FSL UEC0, FSL UEC1
> > > Hit any key to stop autoboot:  0
> > >
> > > => set serverip 192.168.47.8 ; set ipaddr 192.168.47.214
> > >
> > > => ping 192.168.47.8
> > > UEC: PHY is Marvell 88E11x1 (1410cc2)
> > > FSL UEC0: Full Duplex
> > > switching to rgmii 100
> > > FSL UEC0: Speed 100BT
> > > FSL UEC0: Link is up
> > > Using FSL UEC0 device
> > > host 192.168.47.8 is alive
> > >
> > > => ping 192.168.47.8
> >
> > Sorry, I should have included the default environment contents for
> > reference:
> >
> > => printenv
> > bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> > ip=$ipaddrr
> > ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate
> > $othbootr
> > nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
> > ip=$ipaddrr
> > bootdelay=6
> > baudrate=115200
> > loads_echo=1
> > ethaddr=00:04:9f:ef:01:01
> > eth1addr=00:04:9f:ef:01:02
> > loadaddr=200000
> > netdev=eth0
> > consoledev=ttyS0
> > ramdiskaddr=1000000
> > ramdiskfile=ramfs.83xx
> > fdtaddr=400000
> > fdtfile=mpc8360emds.dtb
> > stdin=serial
> > stdout=serial
> > stderr=serial
> > ethact=FSL UEC0
> >
> > Environment size: 979/8188 bytes
> 
> Maybe you suffer from something I noticed, sometimes the master for MDIO gets
> out of sync. Try this patch and see if it helps, not sure if it still applies
> but that should be easy to fix up.
> 

[SNIP]

Maybe you need to define netmask also? Or possibly enable full u-boot relocation?

   Jocke

[U-Boot-Users] Problems with new ethernet init on mpc8360

[Jerry Van Baren]

Joakim Tjernlund wrote:

[snip]

> Maybe you suffer from something I noticed, sometimes the master for MDIO gets
> out of sync. Try this patch and see if it helps, not sure if it still applies
> but that should be easy to fix up.

It applied cleanly with some line offsets, but didn't fix my problem.  :-(

> From 241d7e4f4fb26b2424311a6012c845bd97dfdafa Mon Sep 17 00:00:00 2001
> From: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
> Date: Tue, 18 Dec 2007 14:33:18 +0100
> Subject: [PATCH] Move call to qe_set_mii_clk_src() into uec_read_phy_reg() and
>  uec_write_phy_reg() to make sure MII master clock source is
>  correct.
> 
> ---
>  drivers/qe/uec.c     |    5 -----
>  drivers/qe/uec_phy.c |    6 ++++++
>  2 files changed, 6 insertions(+), 5 deletions(-)

Defining the netmask didn't help either.  Since it works the first time, 
including bootp with a full tftp load (lots of packets), it implies the 
network is fine but someone is shutting down the network (improperly?) 
after the ping/tftp/bootp command completes and not starting it up again 
on the next network command.

Thanks,
gvb