T T T T T T T T T T T T T". The whole information as follows:
U-Boot 1.1.4_XT (Jun 6 2006 - 17:36:18)
U-Boot code: 0C300000 -> 0C31AD70 BSS: -> 0C31EF98 RAM Configuration:
Bank #0: 0c000000 8 MB Bank #1: 0c800000 8 MB Flash: 2 MB
*** Warning - bad CRC, using default environment In: serial
Out: serial Err: serial
Hit any key to stop autoboot: 0 XT=> help tftp
tftpboot [loadAddress] [bootfilename] XT=> tftpboot 0x0c700000 image.bin
TFTP from server 192.168.0.23; our IP address is 192.168.0.70 Filename 'image.bin'.
Load address: 0xc700000
Loading: T T T T T T T T T T T T T T T T T T T T Retry count exceeded; starting again
TFTP from server 192.168.0.23; our IP address is 192.168.0.70
Would someone give me some suggestions?
Answer 2:: (1) Verify your TFTP server is working. On a machine (not the TFTP server nor your development board) use tftp to read the target file.
$ tftp 192.168.0.23 get image.bin
If this doesn't work, fix your TFTP server configuration and make sure it is running.
(2) If your TFTP server is working, run ethereal (or equivalent ethernet sniffing) to see what ethernet packets are being sent by your development board. It usually works best to run ethereal on your TFTP server (if you run it on a different machine and you use an ethernet switch, the third machine likely won't see the tftp packets).
14.2.15. Why is my Ethernet operation not reliable?
Question:My ethernet connection is not working reliable. On one switch it works fine, but on another one it doesn't.
or: Question:
I always see transmit errors or timeouts for the first packet of a download, but then it works well. or:
Question:
I cannot mount the Linux root file system over NFS; especially not with recent Linux kernel versions (older kernel versions work better). Specifying "proto=tcp" as mount option greatly improves the situation.
etc. Answer:
There are many possible explanations for such problems. After eliminating the obvious sources (like broken cables etc.) you should check the configuration of your Ethernet PHY. One common cause of problems is if your PHY is hard configured in duplex mode (for example 100baseTX Full Duplex or 10baseT Full Duplex). If such a setup is combined with a autonegotiating switch, then trouble is ahead.
Jerry Van Baren explained this as follows:
Ignoring the configuration where both ends are (presumably correctly) manually configured, you end up with five cases, two of them
misconfigured and WRONG:
1) Autonegotiation <-> autonegotiation - reliable. 2) 10bT half duplex <-> autonegotiation - reliable. 3) 100bT half duplex <-> autonegotiation - reliable. 4) 10bT *FULL* duplex <-> autonegotiation - *UNreliable*. 5) 100bT *FULL* duplex <-> autonegotiation - *UNreliable*.
The problem that I've observed is that the *humans* (the weak links) that do the manual configuration don't understand that "parallel detection" *must be* half duplex by definition in the spec (it is hard to define a reliable algorithm to detect full duplex capability so the spec writers punted). As a result, the human invariably picks "full duplex" because everybody knows full duplex is better... and end up as case (4) or (5). They inadvertently end up with a slower unreliable link (lots of "collisions" resulting in runt packets) rather than the faster better link they thought they were picking (d'oh!). The really bad thing is that the network works fine in testing on an isolated LAN with no traffic and absolutely craps its pants when it hits the real world.
That is my reasoning behind my statement that we can generally ignore the autonegotiation <-> fixed configuration case because the odds of it working properly are poor anyway.
Rule:
Always try to set up your PHY for autonegotiation.
If you must use some fixed setting, then set it to half duplex mode.
If you really must use a fixed full-duplex setting, then you absolutley must make sure that the link partner is configured exactly the same.
14.2.16. How the Command Line Parsing Works
There are two different command line parsers available with U-Boot: the old "simple" one, and the much more powerful "hush" shell:14.2.16.1. Old, simple command line parser
supports environment variables (through setenv / saveenv commands) •several commands on one line, separated by ';'
•
variable substitution using "... ${_variablename_} ..." syntax
NOTE: Older versions of U-Boot used "$(...)" for variable substitution. Support for this syntax is still present in current versions, but will be removed soon. Please use "${...}" instead, which has the additional benefit that your environment definitions are compatible with the Hush shell, too.
•
special characters ('$', ';') can be escaped by prefixing with '\', for example: •
setenv bootcmd bootm \${address}
You can also escape text by enclosing in single apostrophes, for example:
setenv addip 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:${netdev}:off' •
14.2.16.2. Hush shell
similar to Bourne shell, with control structures like if...then...else...fi,
for...do...done, while...do...done, until...do...done, ... •
supports environment ("global") variables (through setenv / saveenv commands) and local shell variables (through standard shell syntax name=value ); only environment variables can be used with the run command, especially as the variable to run (i. e. the first argument).
•
In the current implementation, the local variables space and global environment variables space are separated. Local variables are those you define by simply typing like name=value. To access a local variable later on, you have to write '$name' or '${name}'; to execute the contents of a variable directly you can type '$name' at the command prompt. Note that local variables can only be used for simple commands, not for compound commands etc.
•
Global environment variables are those you can set and print using setenv and printenv. To run a command stored in such a variable, you need to use the run command, and you must not use the '$' sign to access them.
•
To store commands and special characters in a variable, use single quotation marks surrounding the whole text of the variable, instead of the backslashes before semicolons and special symbols. •
Be careful when using the hash ('#') character - like with a "real" Bourne shell it is the comment character, so you have to escape it when you use it in the value of a variable.
•
Examples:
setenv bootcmd bootm \$address
setenv addip 'setenv bootargs $bootargs ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off'
14.2.16.3. Hush shell scripts
Here are a few examples for the use of the advanced capabilities of the hush shell in U-Boot environment variables or scripts:
Example:
=> setenv check 'if imi $addr; then echo Image OK; else echo Image corrupted!!; fi' => print check
check=if imi $addr; then echo Image OK; else echo Image corrupted!!; fi => addr=0 ; run check
## Checking Image at 00000000 ... Bad Magic Number
Image corrupted!!
=> addr=40000 ;run check
## Checking Image at 00040000 ... Image Name: ARM Linux-2.4.18
Created: 2003-06-02 14:10:54 UTC
Image Type: ARM Linux Kernel Image (gzip compressed) Data Size: 801609 Bytes = 782.8 kB
Load Address: 0c008000 Entry Point: 0c008000 Verifying Checksum ... OK Image OK
Instead of "echo Image OK" there could be a command (sequence) to boot or otherwise deal with the correct image; instead of the "echo Image corrupted!!" there could be a command (sequence) to (load and) boot an alternative image, etc.
Example:
=> addr1=0 => addr2=10
=> bootm $addr1 || bootm $addr2 || tftpboot $loadaddr $loadfile && bootm ## Booting image at 00000000 ...
Bad Magic Number
## Booting image at 00000010 ... Bad Magic Number
TFTP from server 192.168.3.1; our IP address is 192.168.3.68 Filename '/tftpboot/TRAB/uImage'. Load address: 0xc400000 Loading: ################################################################# ################################################################# ########################### done
Bytes transferred = 801673 (c3b89 hex) ## Booting image at 0c400000 ... Image Name: ARM Linux-2.4.18
This will check if the image at (flash?) address "addr1" is ok and boot it; if the image is not ok, the alternative image at address "addr2" will be checked and booted if it is found to be OK. If both images are missing or corrupted, a new image will be loaded over TFTP and booted.
14.2.16.4. General rules
If a command line (or an environment variable executed by a run command) contains several commands separated by semicolons, and one of these commands fails, the remaining commands will still be executed.
1.
If you execute several variables with one call to run (i. e. calling run with a list of variables as arguments), any failing command will cause run to terminate, i. e. the remaining variables are not executed.
2.