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

[Jochen Strohbeck]

Hi Jan,

for a quick test I tried to put all related buffers into non-cached
memory. In my understanding doing so buffer alignment and padding to
cache line size is obsolete in this case.

As already written in my previous posts I can place the buffer
descriptors to non-cache memory. I checked the address in the debugger.
But if I try to place 'memp_memory' (which seems to be the data buffer
for the lwip pool and is used to hold the RX payload ?) to non-cache
memory the address of the gs_gmac_dev struct is to my surprise in
internal flash memory....

It seems to me that there is a problem in my linker script or somewhere
related to that. I calculated the size of all buffers moved to
non-cached memory and everything should fit into non-cached memory.
Unfortunately the .map file does not list the buffers as it does if
everything is in normal SRAM. Guess I have to dig into that. Any idea ?

Regards,
Jochen

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
>>
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>