Peter originally sent a fix, but it breaks a number of other things. This addresses the original reported issue in a different way. That report was: > U-Boot has 1 common buffer to send Ethernet frames, pointed to by > net_tx_packet. When sending to an IP address without knowing the MAC > address, U-Boot makes an ARP request (using the arp_tx_packet buffer) > to find out the MAC address of the IP addressr. When a matching ARP > reply is received, U-Boot continues sending the frame stored in the > net_tx_packet buffer. > > However, in the mean time, if U-Boot needs to send out any network > packets (e.g. replying ping packets or ARP requests for its own IP > address etc.), it will use the net_tx_packet buffer to prepare the > new packet. Thus this buffer is no longer the original packet meant > to be transmitted after the ARP reply. The original packet will be > lost. This instead uses the ARP tx buffer to send async replies in the case where we are actively waiting for an ARP reply. Signed-off-by: Joe Hershberger <joe.hershberger@ni.com> Reported-by: Tran Tien Dat <peter.trantiendat@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Bin Meng <bmeng.cn@gmail.com>lime2-spi
parent
72ff004258
commit
ac3f26cc15
Loading…
Reference in new issue