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

[Detlev Zundel]

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

-- 
I will use free software even if it is less powerful, or less reliable,
because freedom is the most important thing, and that is what the Free
Software movement is about.  How we get freedom.
                       -- Richard M. Stallman
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de