[#4861] Download image fails in BF533-STAMP/EZKIT and BF561-EZKIT when there is ping flood

Document created by Aaronwu Employee on Sep 25, 2013
Version 1Show Document
  • View in full screen mode

[#4861] Download image fails in BF533-STAMP/EZKIT and BF561-EZKIT when there is ping flood

Submitted By: Vivi Li

Open Date

2009-02-05 22:01:36     Close Date

2010-06-17 22:36:01

Priority:

Medium     Assignee:

Mike Frysinger

Category:

networking     Fixed In Release:

N/A

Found In Release:

2009R1     Status:

Closed

Board:

N/A     Processor:

BF533

Silicon Revision:

    Resolution:

Out of Date

Is the bug repeatable?:

yes     

Summary: Download image fails in BF533-STAMP/EZKIT and BF561-EZKIT when there is ping flood

Details:

 

Download image fails in BF533-STAMP/EZKIT and BF561-EZKIT when there is ping flood to it.

 

On PC, use ethtool to change the speed(10/100) and duplex mode(full/half) of Ethernet device and flood ping to target board.

Bellow is the log when we speed is 10 Mb/s and half duplex.

--

test@uboot33-533stamp:~> cd work/cruise/ethtool-3/

test@uboot33-533stamp:~/work/cruise/ethtool-3> sudo ./ethtool -s eth1 speed 10 duplex half

root's password:

test@uboot33-533stamp:~/work/cruise/ethtool-3> sudo ping -f 10.100.4.50

PING 10.100.4.50 (10.100.4.50) 56(84) bytes of data.

..........................................................................................................................................................................................................................................................E...................................................................................................................................................................................

--

 

Then download image in u-boot of target board and it fails.

Bellow is the log of BF533-Stamp. Same problem happens on BF533-EZKIT.

--

U-Boot 2008.10-svn1644 (ADI-2009R1-pre) (Feb  6 2009 - 10:31:52)

 

CPU:   ADSP bf533-0.3 (Detected Rev: 0.3) (bypass boot)

Board: ADI BF533 Stamp board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 497.664 MHz, Core: 497.664 MHz, System: 99.532 MHz

RAM:   128 MB

Flash:  4 MB

In:    serial

Out:   serial

Err:   serial

Net:   MAC:   BA:5F:37:C8:87:B3

Hit any key to stop autoboot:  0

bfin>

bfin> tftp 0x1000000 uImage

Using MAC Address BA:5F:37:C8:87:B3

TFTP from server 10.100.4.174; our IP address is 10.100.4.50

Filename 'uImage'.

Load address: 0x1000000

Loading: T ##T

--

 

Follow-ups

 

--- Mike Frysinger                                           2009-02-05 22:36:01

i dont really see this as being a real bug.  if you're flooding a *half duplex*

connection, then there isnt really a chance for UDP packets to make it reliably

from the board to the host pc and back.

 

--- Robin Getz                                               2009-02-08 20:40:49

I'm not so sure ...

 

The Blackfin should be able to keep up with the ping flood, discarding the ping

packets, and accepting the TFTP packets.

 

Normally this means the Blackfin isn't configured for half duplex properly.

 

--- Mike Frysinger                                           2009-02-08 21:10:58

i'm talking about collisions at the data link layer.  if the host is keeping the

link saturated, then the Blackfin rarely gets the chance to transmit ... this is

just how ethernet works.  i'm not saying the transfer wont work, i'm saying

it'll take a very long time (assuming u-boot itself doesnt simply give up) and

that is correct behavior.

 

--- Robin Getz                                               2009-02-08 21:52:54

If we are dropping packets on the floor (which is what U-Boot does with pings),

then ping flood should only send a ping one hundred times per second (unless you

are setting it to "-i 0" - which I don't think we are).

 

100 packets per second - should provide lots of time for the blackfin to

respond. Don't you think?

 

 

--- Vivi Li                                                  2009-02-12 05:42:56

BF561-EZKIT will also have this problem.

And half and full duplex all may fail, not only half duplex.

 

--- Sonic Zhang                                              2010-04-14 05:33:02

This looks like a bug of the SMC91111 driver in uboot.

bfin_mac driver works as expected.

 

 

--- Mike Frysinger                                           2010-06-02 22:14:22

another thing to keep in mind is that UDP does not guarantee in-order delivery

of packets, and u-boot will ignore any received packets that do not match what

it is currently expecting.

 

so if it gets packet #100 while it is waiting for packet #99, it will discard

it until it gets #99.  after it acks #99 and starts waiting for #100, there will

be a "timeout" because the server already sent #100.  u-boot then

restarts the process by asking for #100 and we see a fast stream again.

 

--- Mike Frysinger                                           2010-06-08 15:18:27

can you enable CONFIG_IP_DEFRAG and see if it makes a difference ?

 

--- Vivi Li                                                  2010-06-10 06:21:02

test script is modified and I will report the result later.

 

--- Vivi Li                                                  2010-06-13 02:49:44

I think this bug disappear without enabling CONFIG_IP_DEFRAG.

Bellow is the log.

 

On PC:

--

uboot32-533ezkit:/home/test/work/cruise/test_scripts/u-boot # ethtool -s eth1

speed 100 duplex full

uboot32-533ezkit:/home/test/work/cruise/test_scripts/u-boot # ping -f

10.100.4.50

PING 10.100.4.50 (10.100.4.50) 56(84) bytes of data.

..............................................................................

--

 

On u-boot:

--

bfin> tftp 0x1000000 uImage.big^M

SMC91111: MAC 00:e0:22:fe:b1:2d^M

Using SMC91111-0 device^M

TFTP from server 10.100.4.174; our IP address is 10.100.4.50^M

Filename 'uImage.big'.^M

Load address: 0x1000000^M

Loading: *^HT T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T T

T T T T T T ^M

Retry count exceeded; starting again^M

SMC91111: MAC 00:e0:22:fe:b1:2d^M

Using SMC91111-0 device^M

TFTP from server 10.100.4.174; our IP address is 10.100.4.50^M

Filename 'uImage.big'.^M

Load address: 0x1000000^M

Loading:

*^H#################################################################^M

         #################################################################^M

         #################################################################^M

         #################################################################^M

         #################################################################^M

         #################################################################^M

         #################################################################^M

         #################################################################^M

         ##############################################^M

done^M

Bytes transferred = 8300035 (7ea603 hex)^M

Image size is 7ea603

Success to tftp download uImage.big.

bfin>

--

 

--- Mike Frysinger                                           2010-06-13 12:55:12

ive enabled that option then

 

--- Vivi Li                                                  2010-06-17 01:41:38

Hi, Mike

 

I'm sorry that you misunderstand my last comment. I should make it clearer.

Option CONFIG_IP_DEFRAG don't needs to be enabled as this test now can pass

even without this option. I think the bug disappeared during u-boot upgrade.

So please revert you commitment. Thanks!

 

--- Mike Frysinger                                           2010-06-17 12:37:28

i think we want that option anyways, so i'll leave it

 

--- Vivi Li                                                  2010-06-17 22:33:21

OK. Close this bug.

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

No Files Were Found

Attachments

    Outcomes