Hey Wolfgang, Here is the printenv of my u-boot, it seems that the MAC addresses on the development boards are set to a standard which does not change, since I got a printenv from freescale where they have the ping working and they have the same ethaddr as I do on my dev board:
Here is my printenv: => printenv bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr -$fdtaddrramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddrnfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr\ bootdelay=6 baudrate=115200 loads_echo=1 ethaddr=04:00:00:00:00:0A eth1addr=04:00:00:00:00:0B loadaddr=200000 netdev=eth0 consoledev=ttyS0 ramdiskaddr=1000000 ramdiskfile=ramfs.83xx fdtaddr=400000 fdtfile=mpc8315erdb.dtb stdin=serial stdout=serial stderr=serial ethact=eTSEC0 ipaddr=192.168.0.109 serverip=192.168.0.22 gatewayip=192.168.0.31 Environment size: 1043/8188 bytes => ping 192.168.0.31 Speed: 100, full duplex Using eTSEC0 device ping failed; host 192.168.0.31 is not alive => Here is the printenv from Freescale where they are able to successfully ping another device on their network: => printenv ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr bootdelay=6 baudrate=115200 loads_echo=1 ethaddr=04:00:00:00:00:0A eth1addr=04:00:00:00:00:0B loadaddr=200000 netdev=eth0 consoledev=ttyS0 ramdiskaddr=1000000 ramdiskfile=ramfs.83xx fdtaddr=400000 bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=10.192.208.120: rootpath=/tftpboot/10.192.208.246 bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=10.192.208.120:/tftpboot/ 10.192.208.246 fdtfile=/tftpboot/mpc8315.dtb bootfile=/tftpboot/uImage stdin=serial stdout=serial stderr=serial gatewayip=10.192.208.254 serverip=10.192.208.120 ipaddr=10.192.208.246 ethact=eTSEC0 Environment size: 1019/8188 bytes => ping 10.192.208.120 Speed: 100, full duplex Using eTSEC0 device host 10.192.208.120 is alive => On Wed, Mar 18, 2009 at 1:23 PM, Wolfgang Denk <w...@denx.de> wrote: > Dear Louis Ruch, > > In message <85a17cd50903180302x62c0f6c1u11e4876452608...@mail.gmail.com> > you wrote: > > > > We erased the flash on the board and every since then cannot get a ping > > reply from any deivce on our network, and we cannot ping the board > itself. > ... > > Since all the lights on the hub are on we once again know that it is able > to > > detect the presence of the cable on the board. Also since the board can > > detect the pressense of a cable it seems to be working, at least on the > > physical layer. Is there anything one must do to ensure that u-boot has > > network support? We have built editted versions as well us just > extracting > > u-boot, building it and programming it. Nothing seems to be working. > > Did you check your environment settings, especially the MAC addresses? > Did you use valid MAC addresses? > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de > All repairs tend to destroy the structure, to increase the entropy > and disorder of the system. Less and less effort is spent on fixing > original design flaws; more and more is spent on fixing flaws intro- > duced by earlier fixes. - Fred Brooks, "The Mythical Man Month" > -- Regards, Louis C. Ruch
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
