> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- 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
