Dear Marek, > From: Patrick DELAUNAY > Sent: lundi 6 avril 2020 17:11 > > Dear Marek, > > > From: Marek Vasut <ma...@denx.de> > > Sent: lundi 23 mars 2020 02:45 > > > > The RX descriptor field 3 should contain only OWN and BUF1V bits > > before being used for receiving data by the DMA engine. However, right > > now, if the descriptor was already used for receiving data and is > > being cleared, the field 3 is only modified and the aforementioned two > > bits are ORRed into the field. This could lead to a residual dirty > > bits being left in the field 3 from previous transfer, and it generally > > does. Fully > set the field 3 instead to clear those residual dirty bits. > > > > Signed-off-by: Marek Vasut <ma...@denx.de> > > Cc: Joe Hershberger <joe.hershber...@ni.com> > > Cc: Patrice Chotard <patrice.chot...@st.com> > > Cc: Patrick Delaunay <patrick.delau...@st.com> > > Cc: Ramon Fried <rfried....@gmail.com> > > Cc: Stephen Warren <swar...@nvidia.com> > > --- > > For the series, > Tested-by: Patrick Delaunay <patrick.delau...@st.com> (on STM32MP15C-DK2, > manual test: dhcp and run bootcmd_pxe)
To complete my test and to check the cache management in the driver, I test the sequence (CONFIG_SYS_NONCACHED_MEMORY is activated): 1) ping with dcache ON: Always OK STM32MP> dhcp STM32MP> ping 91.162.57.93 2) ping with dcache OFF : Always OK STM32MP> dcache off STM32MP> ping 91.162.57.93 3) ping with dcache ON : Failed STM32MP> dcache on STM32MP> ping 91.162.57.93 Failed with "eqos_send: TX timeout" and after "eqos_recv: RX packet not available" 4) ping with dcache OFF : Always OK STM32MP> dcache on STM32MP> ping 91.162.57.93 I don't sure this sequence is really valid or if this issue show a problem in cache management. As I don't see any obvious issue in eqos_send, do you idea on reason of this issue ? > Regards > > Patrick
