mirror of
https://github.com/AsahiLinux/u-boot
synced 2024-11-25 06:00:43 +00:00
f59be6e850
Currently, the BOOTP code sends out its initial request as soon as the Ethernet driver indicates "link up". If this packet is lost or not replied to for some reason, the code waits for a 1s timeout before retrying. For some reason, such early packets are often lost on my system, so this causes an annoying delay. To optimize this, modify the BOOTP code to have very short timeouts for the first packet transmitted, but gradually increase the timeout each time a timeout occurs. This way, if the first packet is lost, the second packet is transmitted quite quickly and hence the overall delay is low. However, if there's still no response, we don't keep spewing out packets at an insane speed. It's arguably more correct to try and find out why the first packet is lost. However, it seems to disappear inside my Ethenet chip; the TX chip indicates no error during TX (not that it has much in the way of reporting...), yet wireshark on the RX side doesn't see any packet. FWIW, I'm using an ASIX USB Ethernet adapter. Perhaps "link up" is reported too early or based on the wrong condition in HW, and we should add some fixed extra delay into the driver. However, this would slow down every link up event even if it ends up not being needed in some cases. Having BOOTP retry quickly applies the fix/WAR to every possible Ethernet device, and is quite simple to implement, so seems a better solution. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Joe Hershberger <joe.hershberger@ni.com> |
||
---|---|---|
.. | ||
arp.c | ||
arp.h | ||
bootp.c | ||
bootp.h | ||
cdp.c | ||
cdp.h | ||
dns.c | ||
dns.h | ||
eth.c | ||
link_local.c | ||
link_local.h | ||
Makefile | ||
net.c | ||
net_rand.h | ||
nfs.c | ||
nfs.h | ||
ping.c | ||
ping.h | ||
rarp.c | ||
rarp.h | ||
sntp.c | ||
sntp.h | ||
tftp.c | ||
tftp.h |