Re: [lwip-users] Problem running lwip on cortex M7 with D cache enabled

[Jan Menzel]

Hi Jochen!
        Please recap where the D-cache is located, what its intended to provide
and how it effects the memory content. If the CPU and some hardware
(GPDMA/GMAC) are accessing the memory for Ethernet transmission and
reception, you've to make sure, that each sees the correct information.
Buffer descriptors are usually used by hardware. With D-Cache in place,
you've to make sure hardware sees what you configured (drain d-cache and
wait until finished before you allow the hardware to access it) and make
sure to read what hardware reports back (invalidate d-cache before
read). On my (ARMv4) hardware, d-cache can only be accessed in 32word
lines. This makes addressing the descriptors inefficient (descriptors
are 2 words per entry, each read through cache reads a full cache line,
invalidation only works on full cache lines). Therefore I put the
descriptors in uncached memory (you get penalty for not using burst-mode
when addressing the memory but the overall result was still faster).
        For transmit/receive operation I'd keep the buffers in cached memory
and drain/invalidate it between driver and application. Invalidating
works for full cache lines only and can cause serious trouble if data
that was intended to be written back to memory is not there because of
the invalidation. I'd suggest to align (position and size) all receive
buffers to d-cache lines so that invalidation does not cause any side
effects.
        Good look!

        Jan

On 30.11.2017 13:10, Jochen Strohbeck wrote:
> Hello,
> 
> I'm using lwip 1.4.1 and FreeRTOS on a SAME70 custom board with success
> if D-cache is disabled. If I enable the D-cache no more packets are
> received. If I place the RX descriptor into a non-cacheable region I get
> packets again but the received data is corrupt. Here is the lwip output:
> 
>  Checksum (0xa5fd) failed, IP packet dropped.
>  IP (len 96) is longer than pbuf (len 50), IP packet dropped.
> 
> I understand that I have to move the receive (and send) buffers which
> are used by the GMAC DMA to a non-cacheable region too. And here is
> where my problem starts. In my understanding these buffers are by
> default in an lwip memory pool. If I simply place the entire memory pool
> to non-cacheable region the CPU hangs up. I guess this is due to the
> D-cache requirements that the (GMAC) DMA buffer must be aligned to
> 32bytes but I don't know how to modify the lwip code in such a way that
> the receive buffer (pbuf->payload?) is 32byte aligned. The other (and
> better?) way would be to separate the receive buffer (or pbuf->payload)
> from the lwip memory pool so I can place it everywhere I want but I
> don't know how to manage this. Probably there is a better way to do so
> in lwip ?
> 
> Any help is welcome.
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>