Hi Jeffrey,
U-boot Users:
I received an updated u-boot image for the next batch of sequoia boards. In the process of updating our test procedure, I found a bug affecting the TFTP functionality. I built a u-boot binary from the tree and discovered that the cause of this problem is now in the tree. The example below shows that when a binary is loaded onto the board using source code compiled from the current top of the u-boot tree, every few hundred words are bad. I do not know what sort of changes have been made recently that affect the net systems in the source, so I am just putting this out there to see if anyone else can reproduce it or knows what the problem is.
-Jeffrey
These examples show the problem's isolation to the new u-boot:
File loaded into 0x200000 over JTAG the same file is TFTPed in the following examples. These files are compared. They should be exactly the same (for the first 0x60000 bytes).
The 'broken' u-boot, compiled from top of tree: => tftp 100000 u-boot.bin Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.58; our IP address is 10.0.0.211 Filename 'u-boot.bin'. Load address: 0x100000 Loading: ########################### done Bytes transferred = 393216 (60000 hex) => cmp 100000 200000 60000 word at 0x001004f4 (0x9bcdcbca) != word at 0x002004f4 (0x00000000) Total of 317 words were the same <- this is the first of many wrong words in the file . Taking the CRC32 confirms that 0x200000 is correct and 0x100000 is wrong
0x4f4 works out to be 1268 decimal. The biggest change in the area in question is the change of the default tftp block size. Simply checking the number of hashes output (one for ten blocks) clearly indicates the difference between the two versions you cite (David Updegraff added these changes in commit 53a5c424).
Now the interesting part is why I have seen a sequoia here locally correctly working with the larger block sizes, while you have problems. It may be that your tftp server has a problem not correctly nacking the blocksize option and falling back to 512 byte blocks but really having problems handling the larger blocks.
My advise is to get out wireshark, trace the interaction or try a different tftp server.
the u-boot shipped on sequoia RCD5, this is u-boot 1.2.xxxx-dirty, I think: => tftp 100000 u-boot.bin Waiting for PHY auto negotiation to complete.. done ENET Speed is 100 Mbps - FULL duplex connection (EMAC0) Using ppc_4xx_eth0 device TFTP from server 10.0.0.58; our IP address is 10.0.0.211 Filename 'u-boot.bin'. Load address: 0x100000 Loading: ################################################################# ############
Note the number of hashes corresponding to 512 byte blocks.
done Bytes transferred = 393216 (60000 hex) => crc32 100000 200000 60000 CRC32 for 00100000 ... 002fffff ==> 253570e9 => cmp 100000 200000 60000 word at 0x00160000 (0x80890000) != word at 0x00260000 (0xfdc9a783) Total of 98304 words were the same <- the file is transfered correctly. Taking the CRC32 confirms this. =>
Best wishes Detlev