Jochen Strohbeck wrote:
[..]
For productive system I'm afraid that I have to claim on 1.4.1 for now.
Please be warned again, especially for productive systems: if you have
any focus on security (and for a device with an ethernet connection, you
should), don't use 1.4.1 but use at least 2.0.3
Jan Menzel:
> Did you check the performance for your system? I suppose with buffers in
> non-cached memory you do not have any benefits of the d-cache. If you
> can't get any of the options I suggested to run, you still might use
> dedicated non-cached RX buffers in the driver and copy received dat
On 05.12.2017 8:22, Jochen Strohbeck wrote:
> I found an error in the non-cacheable section declaration in the linker
> configuration file. Fixed that.
>
Did you check the performance for your system? I suppose with buffers in
non-cached memory you do not have any benefits of the d-cache. If you
c
Jan Menzel:
> On 30.11.2017 23:09, Jochen Strohbeck wrote:
>> 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
On 30.11.2017 23:09, Jochen Strohbeck wrote:
> 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 th
On 01.12.2017 17:26, goldsimon wrote:
>> For RX the Ethernet data part has to be aligned to cache line to void
>> issues due to cache invalidation.
>> In my implementations I use pooled memory. From the lwip code I can
>> see, that LWIP_MEM_ALIGN_SIZE() is used to add padding between
>> m
As a quick test I placed descriptors and the entire pool into
non-cacheable SRAM. No further code changes are necessary although it
took some time tweaking the linker and lwipopts.h file. I had to shrink
it a little to fit into a 64kB section but network communication still
seems to be stable. Coul
Jochen Strohbeck wrote:
> - RX/TX descriptors must be in non-cacheable memory to avoid race
> conditions. Alignment and padding is not necessary (?)
You can do with cached memory + flushing if you obey alignment, but it's
probably not worth the work: if the driver is programmed well, you'll acces
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
Jan Menzel wrote:
>For TX there is nothing really needed on the LWIP side. Draining the
>d-cache is always possible without side effects. Its just a question of
>efficiently if a packet content does not start at a cache line.
Unless that buffer would be in the same cache line as an rx buffer, ye
On 30.11.2017 15:58, goldsimon wrote:
>
>
> Jan Menzel wrote:
>> I'd suggest to align (position and size) all receive
>> buffers to d-cache lines so that invalidation does not cause any side
>> effects.
>
> And it's exactly this that lwip does not fully support yet. It doesn't work
> for the tx
Thanks for your posts. I try to summarize what I got so far:
- RX/TX descriptors must be in non-cacheable memory to avoid race
conditions. Alignment and padding is not necessary (?)
- RX/TX buffers must be in non-cacheable memory or can be in cacheable
memory but require explicit cache clean/inva
Jan Menzel wrote:
> I'd suggest to align (position and size) all receive
>buffers to d-cache lines so that invalidation does not cause any side
>effects.
And it's exactly this that lwip does not fully support yet. It doesn't work for
the tx side at all and for the rx side, we only have the work
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.
> We still have a task open to work on fully supporting zero copy tx/rx.
>
To clarify: 2.0.3 supports zero-copy RX:
http://www.nongnu.org/lwip/2_0_x/group__pbuf.html
Section "Detailed Description"
but NOT TX!
Maybe RX is "good enough" for you.
Dirk
__
Jochen Strohbeck wrote:
>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
No surprises so far ;-)
> but the recei
Noam Weissman wrote:
>I am working with STM32F7 with LwIP 2.02 + FreeRTOS 9
>
>D and I cache are enabled.
The drivers supplied by ST, although using DMA transfer, are still copying the
frame payload to/from pbuf payload using memcpy. If you haven't changed this
yourself, you have cache line al
Hi Noam,
thanks for the fast reply. I was hoping not to update lwip (Atmel's ASF
still claims on lwip 1.4.1, CMSIS 4.0 and FreeRTOS 8.3...) but I'll look
into that.
Remaining questions :
- descriptors are hard coded == placed in no cache memory ?
- what about RX/TX buffers: also placed in no
Hi,
I am working with STM32F7 with LwIP 2.02 + FreeRTOS 9
D and I cache are enabled.
TX/RX descriptors are hard coded inside DTCM. We have no problems for now.
Most of the rest of LwIP init is as it was in older projects that used the
STM32F4
I strongly suggest upgrading to LwIP 2.02 or even
19 matches
Mail list logo
