Jerry Van Baren wrote: > Bartlomiej Sieka wrote: >> There are two aspects of a TFTP transfer involving timeouts: >> 1. timeout waiting for initial server reply after sending RRQ >> 2. timeouts while transferring actual data from the server >> >> Since the upcoming auto-update feature attempts a TFTP download during >> each >> boot, it is undesirable to have a long delay when the TFTP server is not >> available. Thus, this commit makes the server timeout (1.) >> configurable by two >> global variables: >> >> TftpRRQTimeoutSecs >> TftpRRQTimeoutCountMax >> >> TftpRRQTimeoutSecs overrides default timeout when trying to connect to >> a TFTP >> server, TftpRRQTimeoutCountMax overrides default number of connection >> retries. >> The total delay when trying to download a file from a non-existing >> TFTP server >> is TftpRRQTimeoutSecs x TftpRRQTimeoutCountMax seconds. > > Hi Bartlomiej, > > Are seconds an appropriate scale factor for the timeout?
Hi Jerry, The patch didn't introduce changes in this regard -- TFTP timeouts were defined in seconds originally. The patch makes the timeout behavior configurable, instead of being hardcoded, but the units remain the same: #define TIMEOUT 5UL /* Seconds to timeout for a lost pkt */ Regards, Bartlomiej Sieka _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot