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