-----Original Message----- From: u-boot-users-bounces@lists.sourceforge.net [mailto:u-boot-users-bounces@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@lists.sourceforge.net [mailto:u-boot-users-bounces@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