public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: PF4Public <PF4Public@mail.ru>
To: u-boot@lists.denx.de
Subject: [U-Boot] u-boot tftp problem
Date: Thu, 26 Feb 2015 01:01:00 +0300	[thread overview]
Message-ID: <54EE461C.6070701@mail.ru> (raw)
In-Reply-To: <CANr=Z=bdaQgpc=ib3ZHBLhpe_6eT0oE1ACRTy0sRHvdREGupeA@mail.gmail.com>

Hello, Joe

 >Can you provide more exact details on the servers you are trying including versions?
 >Perhaps also provide pcap files (not text dumps) so the exact packet contents can be 
observed?

Recently I've done some tests, hope you find them interesting.

Server in question:
Linux sterver 3.2.0-4-686-pae #1 SMP Debian 3.2.65-1+deb7u1 i686 GNU/Linux
  r8169 0000:08:04.0: eth1: RTL8169sc/8110sc at 0xf827e000, 90:e6:ba:07:3e:a5, XID 
18000000 IRQ 19
ii  tftpd                             0.17-18 i386                  Trivial file transfer 
protocol server

I have mirrored 2 ports at the switch. Here's what I have found:
1. tftp block ack packets have some extra bytes. They are "mage octet tim". Suppose that's 
because buffer reuse in u-boot after "uImage octet timeout 5", although I'm not so sure.
2. u-boot never generates wrong block acks if "#define TIMEOUT     8000UL". Obviously 8 
seconds is enough for tftp server to resend the block, so with this define, it is not 
timing out and keeps downloading till the end. Ofcourse it just masks the real problem, 
nothing more.
3. at the times of server resending block it is u-boot who lost the packet. I believe that 
if the packet was delivered to mirrored port, it must have been delivered to u-boot. But 
logging at u-boot shows no evidence of packet reception, however packets following missed 
one are registered.
4. the only condition at which u-boot didn't loose packets and downloaded uImage without 
timeouts was when I made it log everything regarding network. this gave enormous output to 
console, but no tftp packets lost. Even though I tested it twice it could be a coincidence.

Also I tried disabling caches. Rebuilding with "CONFIG_SYS_ICACHE_OFF" and 
"CONFIG_SYS_DCACHE_OFF" was no difference at all. At least for tftp download.

I was about to provide you with pcap files from mirror port and corresponding u-boot 
console log, but sadly seems that I have deleted u-boot log by mistake :( I think I have 
to repeat the whole thing before I can provide you with them both.

Best regards

  reply	other threads:[~2015-02-25 22:01 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-14  2:05 [U-Boot] u-boot tftp problem PF4Public
2015-02-17 17:10 ` Joe Hershberger
2015-02-18 15:33   ` PF4Public
2015-02-18 17:31     ` Nikolay Dimitrov
     [not found]       ` <54E4CE0E.5000308@mail.bg>
2015-02-20 14:43         ` [U-Boot] Fwd: " PF4Public
2015-02-20 15:50           ` [U-Boot] " Nikolay Dimitrov
2015-02-20 16:51             ` PF4Public
2015-02-23 23:02               ` Joe Hershberger
2015-02-25 22:01                 ` PF4Public [this message]
2015-03-02 22:22                 ` PF4Public

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54EE461C.6070701@mail.ru \
    --to=pf4public@mail.ru \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox