DWC4 ethernet in U-Boot receiving it's own traffic
Hi,
are you aware of any issues with the DWC4 ethernet in U-Boot? I recently ran into oddity where the MAC receives it's own packets upon replying to ARP request.
Test case is as follows: - Assume host PC with IP 192.168.1.1/24 , STM32MP1 board with IP 192.168.1.2/24 - Assume TFTP server has 64MiB file called 64m full of zeroes ($ dd if=/dev/zero of=/tftpboot/64m bs=64M count=1) - Run the following in U-Boot: $ setenv ipaddr 192.168.1.2 $ setenv netmask 255.255.255.0 $ setenv serverip 192.168.1.1 $ tftp 192.168.1.1:64m - In parallel, during the TFTP transfer, run the following on PC: $ arping -c 1 192.168.1.2
Observe 5-second delay while the MAC is trying to recover or complete failure of the transfer.
What happens is that the U-Boot is in netloop, receives the ARP request and sends ARP reply. So far so good. However, the DWC4 receives that ARP reply too for reason that is not clear yet (the packet which arrives in eqos_recv() has source MAC equal to the board MAC address).
Note that this is modeling a real world scenario where the host PC sends ARP request to the board during a TFTP transfer. The same problem does happen then.
Can you try replicating this and see whether this is happening for you too?
Hi Marek
For this issue, can you contact the support by clicking on the "ST Support Center" link on this page: https://wiki.st.com/stm32mpu/wiki/Main_Page ?
Thanks
Patrice
On 1/28/20 10:32 PM, Marek Vasut wrote:
Hi,
are you aware of any issues with the DWC4 ethernet in U-Boot? I recently ran into oddity where the MAC receives it's own packets upon replying to ARP request.
Test case is as follows:
- Assume host PC with IP 192.168.1.1/24 , STM32MP1 board with IP 192.168.1.2/24
- Assume TFTP server has 64MiB file called 64m full of zeroes ($ dd if=/dev/zero of=/tftpboot/64m bs=64M count=1)
- Run the following in U-Boot:
$ setenv ipaddr 192.168.1.2 $ setenv netmask 255.255.255.0 $ setenv serverip 192.168.1.1 $ tftp 192.168.1.1:64m
- In parallel, during the TFTP transfer, run the following on PC:
$ arping -c 1 192.168.1.2
Observe 5-second delay while the MAC is trying to recover or complete failure of the transfer.
What happens is that the U-Boot is in netloop, receives the ARP request and sends ARP reply. So far so good. However, the DWC4 receives that ARP reply too for reason that is not clear yet (the packet which arrives in eqos_recv() has source MAC equal to the board MAC address).
Note that this is modeling a real world scenario where the host PC sends ARP request to the board during a TFTP transfer. The same problem does happen then.
Can you try replicating this and see whether this is happening for you too?
Dear Patrice,
In message 29b76452-5d98-af01-8b85-d1416106a30c@st.com you wrote:
For this issue, can you contact the support by clicking on the "ST Support Center" link on this page: https://wiki.st.com/stm32mpu/wiki/Main_Page ?
Can we please keep U-Boot related discussions here on the U-Boot mailing list?
Redirecting to some vendor forum is not really helpful to the community.
Best regards,
Wolfgang Denk
Hi Wolfgang, Marek
On 1/29/20 10:56 AM, Wolfgang Denk wrote:
Dear Patrice,
In message 29b76452-5d98-af01-8b85-d1416106a30c@st.com you wrote:
For this issue, can you contact the support by clicking on the "ST Support Center" link on this page: https://wiki.st.com/stm32mpu/wiki/Main_Page ?
Can we please keep U-Boot related discussions here on the U-Boot mailing list?
Redirecting to some vendor forum is not really helpful to the community.
I understand your point.
As we are overload, Christophe ( our ethernet expert) doesn't get the
bandwitdth to reproduce Marek's setup in a short term, don't hesitate to ping him
in one week.
Nevertheless, regarding ARP request, dwmac should handle automatically this kind of request if
the ARPEN bit is set in the ETH_MACCR register, which i presume is not the case.
Marek, could you give a try by setting this ARPEN bit in ETH_MACCR ?
Regards
Patrice
Best regards,
Wolfgang Denk
On 1/29/20 1:51 PM, Patrice CHOTARD wrote:
Hi Wolfgang, Marek
Hi,
On 1/29/20 10:56 AM, Wolfgang Denk wrote:
Dear Patrice,
In message 29b76452-5d98-af01-8b85-d1416106a30c@st.com you wrote:
For this issue, can you contact the support by clicking on the "ST Support Center" link on this page: https://wiki.st.com/stm32mpu/wiki/Main_Page ?
Can we please keep U-Boot related discussions here on the U-Boot mailing list?
Redirecting to some vendor forum is not really helpful to the community.
I understand your point.
As we are overload, Christophe ( our ethernet expert) doesn't get the
bandwitdth to reproduce Marek's setup in a short term, don't hesitate to ping him
in one week.
Nevertheless, regarding ARP request, dwmac should handle automatically this kind of request if
the ARPEN bit is set in the ETH_MACCR register, which i presume is not the case.
Marek, could you give a try by setting this ARPEN bit in ETH_MACCR ?
This seems to help. Can you send a patch and document the replicator in the patch commit message, so it's clear what it fixes and how to test it?
Thanks
participants (3)
-
Marek Vasut -
Patrice CHOTARD -
Wolfgang Denk