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

[Joakim Tjernlund <Joakim.Tjernlund@transmode.se>]

> -----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.