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
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: ################################################################# ############ 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. =>