[U-Boot-Users] TFTP bug on sequoia boards

[Jeffrey Mann]

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