lwIP | stm32h7: Add Ethernet driver for STM32H743ZI Nucleo (!37)

[Claudio Grasso (@ClaudioGrasso)]

Claudio Grasso commented on a discussion on stm32h7/include/lwipbspopts.h: https://gitlab.rtems.org/rtems/pkg/rtems-lwip/-/merge_requests/37#note_152265

 > +#define ETH_PAD_SIZE 2
 > +
 > +/* Strongly byte-by-byte MEMCPY for STM32H7 to avoid all hardware traps.
 > + * Optimized library versions of memcpy() may use word-aligned instructions (LDR/STR)
 > + * even on byte-access paths, which can trigger usage faults in certain memory regions.
 > + */
 > +static inline void stm32h7_byte_memcpy(void *dst, const void *src, size_t len) {
 > +    uint8_t *d = (uint8_t *)dst;
 > +    const uint8_t *s = (const uint8_t *)src;
 > +    while (len--) {
 > +        *d++ = *s++;
 > +    }
 > +}
 > +#define MEMCPY(dst, src, len)  stm32h7_byte_memcpy(dst, src, len)
 > +#define SMEMCPY(dst, src, len) stm32h7_byte_memcpy(dst, src, len)
 > +#define MEMMOVE(dst, src, len) stm32h7_byte_memcpy(dst, src, len)

_One correction to my last comment before it causes confusion: I described the buffer region as non-cacheable Device memory — that's wrong for the MR as submitted. MPU_Config() sets the D2 SRAM region (0x30000000) to TEX=1/C=1/B=1, i.e. Normal cacheable memory (with explicit SCB_CleanDCache/InvalidateDCache maintenance around DMA ownership transfers), and clears CCR.UNALIGN_TRP. So unaligned ldr.w/str.w there are handled in hardware, and newlib's bulk memcpy() does not fault — which matches our iperf results with standard memcpy() and is why the current version overrides SMEMCPY only. The disassembly remains relevant to the SMEMCPY case for a narrower reason: GCC emits LDRD/LDM for the 4-byte IPADDR_WORDALIGNED_COPY_TO_IP4_ADDR_T copies, and those instructions fault on unaligned addresses regardless of memory type and UNALIGN_TRP. That instruction-level constraint is the entire justification for the byte-by-byte SMEMCPY override._

_With that corrected — is there anything else you'd like me to address on this MR?_

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/pkg/rtems-lwip/-/merge_requests/37#note_152265
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/20260611/b8468bec/attachment-0001.htm>