LibBSD | Cannot make if_stmac.c work with stm32h7 and data in SDRAM (#2)
Cedric Berger (@cedric)
gitlab at rtems.org
Thu Aug 15 12:38:18 UTC 2024
Cedric Berger created an issue: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/2
## Summary
At least with data in SDRAM (FMC) on a stm32h747, the if_stmac.c driver is not working properly. it might be due to stm32h747 not supporting unaligned access on FMC (see stm32h7 errata) or for some other reason, like the many erratas for the ethernet IP on this chip.
I spent a day trying to understand what is going on, without success.
When trying to ping from another host, the reception path got OK:
- I could receive a proper ARP packet
- The ARP response was correctly generated by the stack.
- No packet (or a corrupted packet) was received on the other side (transmission problem).
## Steps to reproduce
Configure a stm32h7 eval board using SDRAM for data/bss/heap.
Try networking with something like like media01.exe.
## Minor issues:
During testing, I found out two minor problems, and came up with the following patch, included here in case it helps:
```
--- a/rtemsbsd/sys/dev/stmac/if_stmac.c
+++ b/rtemsbsd/sys/dev/stmac/if_stmac.c
@@ -50,6 +50,8 @@
#include <net/if_types.h>
#include <net/if_var.h>
+#include <net/bpf.h>
+
#include <machine/bus.h>
#include <dev/mii/mii.h>
@@ -115,9 +117,9 @@ stmac_new_mbuf(struct ifnet *ifp)
m = m_getcl(M_NOWAIT, MT_DATA, M_PKTHDR);
if (m != NULL) {
+ rtems_cache_invalidate_multiple_data_lines(m->m_ext.ext_buf, m->m_ext.ext_size);
m->m_data = mtod(m, char *) + ETHER_ALIGN;
m->m_pkthdr.rcvif = ifp;
- rtems_cache_invalidate_multiple_data_lines(m->m_data, m->m_len);
}
return m;
@@ -793,6 +795,8 @@ stmac_tx_enqueue(struct stmac_softc *sc, struct ifnet *ifp, struct mbuf *m)
_ARM_Data_synchronization_barrier();
regs = sc->heth.Instance;
WRITE_REG(regs->DMACTDTPR, (uint32_t)&desc_ring[new_head_idx]);
+
+ ETHER_BPF_MTAP(sc->ifp, m);
return (0);
}
```
- The `rtems_cache_invalidate_multiple_data_lines` call was doing nothing, since `m_len` is 0 for a new mbuf.
- ETHER_BPF_MTAP was missing to see the output packet with tcpdump.
## Fun read
No idea if this is relevant, but the following blog is pretty fun (or horrifying)
https://www.mattkeeter.com/blog/2023-10-31-dma/
--
View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-libbsd/-/issues/2
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240815/d8d236e9/attachment.htm>
More information about the bugs
mailing list