已解决! 转到解答。
clockwork,
When debugging u-boot networking and a new board for the first time, the real first step is KISS (keep it simple stupid) before you try more advanced networking, downloading etc. with it. u-boot has some quirks and also some of the setup is not 100% obvious if you are a u-boot newbie (as I was just 6 months ago)
First you should hook up your target board directly to your server using a straight through cable (as all the boards I've seen from Freescale have PHYs that have auto-crossover). Not all cross-over cables are created equal and some will not work at gigabit. The PHY on the board should take care of things OK.
Make sure that you see the carrier light on the port and also check the server side with an ifconfig (or similar command) to see that the port is up OK on the server as well. Also use a "known good" cable.
Assuming everything is OK at the physical level, you need to make sure u-boot is configured OK. Here is my config (for an MPC8313E-RDB board, but your config should be similar in the areas I will talk about):
=> print
flash_nfs=run nfsargs addip addtty;bootm ${kernel_addr}
flash_self=run ramargs addip addtty;bootm ${kernel_addr} ${ramdisk_addr}
net_nfs=tftp 200000 ${bootfile};run nfsargs addip addtty;bootm
load=tftp 100000 uboot_8313
update=protect off fe000000 fe04ffff; era fe000000 fe04ffff; cp.b 100000 fe00000
0 ${filesize}
upd=run load;run update
fdtaddr=400000
fdtfile=mpc8313erdb.dtb
vsc=cp.b fe050000 40000 12000;go 40004
bootcmd=protect on fe050000 fe07ffff;run vsc
ramargs=set bootargs root=/dev/ram rw ramdisk=128000
ethact=TSEC0
mtdids=nor0=nor,nand0=nand
rootpath=/tftpboot/192.168.2.192
filesize=119d
fileaddr=400000
gatewayip=192.168.2.1
netmask=255.255.255.0
ipaddr=192.168.2.192
serverip=192.168.2.129
bootargs=root=/dev/ram rw ramdisk=128000 console=ttyS0,115200
stdin=serial
stdout=serial
stderr=serial
Environment size: 1747/8188 bytes
=>
Here are the key ones to focus on:
Make sure the local ipaddr and netmask are OK and for initial debugging, make sure you used hard configured IP addresses on both the target and the server, here are mine:
ipaddr=192.168.2.192
netmask=255.255.255.0
Make sure the server IP address is set OK and if you are using a back to back cable you need to make sure the server and the target are on the same subnet:
serverip=192.168.2.129
I believe the 8360 device like the 8313 has multiple ETSECs, so you need to make sure that the correct ETSEC is set as default (i.e. the one connected to the port you are trying to run). In my case, I typically use ETSEC1 in the chip, but one thing that may bite you is the Freescale numbers ETSECs starting at 1 (ETSEC1, ETSEC2) whereas u-boot starts from 0 (TSEC0, TSEC1), so in my case I want to use ETSEC1 so I set ethact on u-boot to TSEC0. The active TSEC is set using the ethact environment variable (here is a print command showing mine):
=> print ethact
ethact=TSEC0
=>
Another thing that may bite you is sometimes when u-boot fails, it will automatically toggle between TSEC0 and TSEC1, so if ping isn't working, use the print ethact command to see if you are on the right port. If it is wrong, you can use the set command:
=> set ethact TSEC0
Another thing that may bite you is my board (and perhaps yours) also has an embedded Ethernet Switch. If your board has one, you need to make sure that it is loaded and running if you are trying to ping through that switch. The MPC8313E-RDB board has a Vitesse switch chip hooked up to TSEC1 (u-boot TSEC0) which must be running properly. In my case, I have my boot command setup to load the code automatically at startup (run vsc) as follows:
vsc=cp.b fe050000 40000 12000;go 40004
bootcmd=protect on fe050000 fe07ffff;run vsc
For my board when you "run vsc" you get the following output:
Protected 3 sectors
## Starting application at 0x00040004 ...
VSC7385 Version = 0x273850e9
Value in IRAM matches binary, total bytes 0x2000 loaded
## Application terminated, rc = 0x0
Also note that as the TSEC is directly connected on the boardto a port on the switch, it will always report the TSEC port as up even though nothing is connected to other switches on the port (this can cause confusion as well for a first time Freescale board user).
Another interesting bug (but shouldn't get you eventually get ping to work) is at least on my board and u-boot, the first time you try a ping, it gets an error, but then pings OK as follows:
=> ping 192.168.2.129
Speed: 1000, full duplex
Using TSEC0 device
Got error 4
host 192.168.2.129 is alive
=>
Subsequent pings then work OK:
=> ping 192.168.2.129
Speed: 1000, full duplex
Using TSEC0 device
host 192.168.2.129 is alive
=>
Notice that the ping command also tells you the speed, duplex setting and TSEC setting, make sure all those are OK (with the caution that if attached to an on-board switch chip that is running OK, it will always be at 1000, full duplex). If the TSEC device is the wrong one, use the set ethact command to change it. Also it is a good idea to save.
Another thing to remember while debugging u-boot networking is that u-boot can transmit ping requests and process the received ping replies, but u-boot does not support receiving ping requests and will silently discard them (so if you ping from the server to a u-boot target, you will not see a ping reply at the server side).
Last thing I can think of is I have seen cases where I've done a set ethact followed by a save and after a reboot, it doesn't "stick" and the other TSEC is the active one (not sure if this is a bug or a feature). Again either the print ethact or the ping command itself will tell which one is active (again remembering that u-boot numbers are one off from Freescale spec TSEC name).
Hope this helps :smileyhappy: Also after you get Ping to work OK, for other u-boot observations (such as running TFTP OK when running back to back, but sometimes failing on a network), you can check out my reply to another post at:
http://forums.freescale.com/freescale/board/message?board.id=MCUCOMM&thread.id=493
Cheers,
abartky
clockwork,
I did a quick google search and found a "working" u-boot example for the 8360 where I searched for "FSL GETH0 printenv", the link I found is at:
http://www.mail-archive.com/linuxppc-embedded@ozlabs.org/msg20887.html
Here is an excerpt:
U-Boot 1.1.3 (ppc83xx-20050315-dev) (Dec 14 2005 - 09:37:59) MPC83XX
Clock configuration:
Coherent System Bus: 264 MHz
Core: 528 MHz
QE: 396 MHz
Local Bus Controller: 264 MHz
Local Bus: 66 MHz
DDR: 264 MHz
DDR Secondary: 264 MHz
I2C: 264 MHz
CPU: MPC83xx, Rev: 20 at 528 MHz
Board: Freescale MPC8360EPB
I2C: ready
DRAM:
SDRAM on Local Bus: 64 MB
DDR RAM: 256 MB
FLASH: 16 MB
In: serial
Out: serial
Err: serial
Net: FSL GETH0
Hit any key to stop autoboot: 0
=> printenv
bootcmd=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrramboot=setenv
bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp
$ramdiskaddr $ramdiskfile;tftp $loarnfsboot=setenv bootargs root=/dev/nfs
rw nfsroot=$serverip:$rootpath
ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netrbootdelay=6
baudrate=115200
loads_echo=1
ethaddr=00:04:9f:11:22:33
eth1addr=00:E0:0C:00:7D:01
hostname=unknown
loadaddr=200000
netdev=eth0
consoledev=ttyS0
ramdiskaddr=400000
ramdiskfile=ramfs.83xx
ethact=FSL GETH0
filesize=2d030a
fileaddr=20000
gatewayip=192.168.3.1
netmask=255.255.255.0
serverip=192.168.3.81
bootfile=/tftpboot/vmlinux.gz
ipaddr=192.168.3.253
stdin=serial
stdout=serial
stderr=serial
Environment size: 1005/8188 bytes
=> setenv bootargs console=ttyS1 root=/dev/ram
=> tftp 200000 uImage_test
Auto negotiating done
switching to rgmii 100
duplexity: full
mac speed set to: 100
Using FSL GETH0 device
TFTP from server 192.168.3.81; our IP address is 192.168.3.253
Filename 'uImage_test'.
Load address: 0x200000
Loading: #################################################################
#################################################################
#################################################################
#######
done
Bytes transferred = 1033098 (fc38a hex)
=>
In your printenv, I did not see a netmask=255.255.255.0, so make sure that is set. Also I noticed the example working code also sets the eth1addr, so if you have a 2 port system, you may want to try that as well.
The other worrysome part are the startup messages from your trace saying "number", "CPU revision!" and "Rev: Unknown, incompatible u-boot image" and the fact that the ping command is hanging there, rather than timing out, do not bode well. Considering the fact the ping command is reporting the PHY status OK (full duplex Gigabit Ethernet), if adding the netmask and the eth1addr doesn't fix things, then you may have a u-boot software issue. Are you using the version of u-boot that came with the board's BSP?
Cheers,
abartky