imxrt lwip cache issue (bug report?)

[dmarples]

Folks,

On the current version of the imxrt SDK (2.4.2) in ethernetif.c around lines 1133 or so (in ethernetif0_init) I think the transit buffers need to be declared in non-cached memory as follows;

From;

    SDK_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
    SDK_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);

To;

    AT_NONCACHEABLE_SECTION_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
    AT_NONCACHEABLE_SECTION_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);

...at least for me this reduces my flood ping losses from 70% to 0% ...please let me know if I've misunderstood something.

Regards

DAVE

[jamesk]

Simply doing this does not seem to be enough for lwip to work properly:

AT_NONCACHEABLE_SECTION_ALIGN(static rx_buffer_t rxDataBuff_0[ENET_RXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);
AT_NONCACHEABLE_SECTION_ALIGN(static tx_buffer_t txDataBuff_0[ENET_TXBD_NUM], FSL_ENET_BUFF_ALIGNMENT);

I am trying to run lwip_mqtt_freertos demo from NXP, which I modified to put the heap on the SDRAM
(instead of SRAM_DTC).
Even with the suggested solution above(move the ethernet tx/rx buffers to non-cacheable SDRAM area),
the code still gets memory for the buffers from cacheable SDRAM area.

I am still trying to figure out what other configurations/code must be corrected.
Any help will be appreciated.

[yosri_c]

hello ,

I am running into the same thing with lwip .  Do you remember what fixes you had to make?

i added the buffers to NON CACHE regions but no improvement 

anything about heap allocation 

[w2vy]

I wonder if these bits are set that the transactions will be cachable (not needing uncached memory)

IOMUXC_GPR_GPR13 CACHE_USB, CACHE_ENET, AWCACHE_USDHC etc

It seems the reset default is with the Cacheable Attribute OFF

Tom

[dmarples]

I am now seeing similar issues with the SD card driver, which I have been able to resolve in a similar manner by using non-cacheable memory...but it confuses me why you guys haven't seen these issues? Are your samples only running from close coupled memories that don't have caches (I can/will go look, but I really need to get some sleep after fighting this all day)?

Regards

DAVE

[jackking]

I am running into the same thing with sdmmc.  Do you remember what fixes you had to make?

I think the samples are all using DTCM (non-cached), so the problem doesn't present itself with the samples.

[dmarples]

Hi Jack,

It's a long time ago, I'd like to think the drivers have been updated since then!

However, I have taken a quick look, and I see AT_NONCACHEABLE_SECTION_ALIGN definitions added in the following places;

fsl_sdmmc_host.c:112: AT_NONCACHEABLE_SECTION_ALIGN(uint32_t g_usdhcAdma2Table[USDHC_ADMA_TABLE_WORDS], USDHC_ADMA2_ADDR_ALIGN);

fsl_usdhc.c:59: AT_NONCACHEABLE_SECTION_ALIGN(uint32_t s_usdhcBootDummy, USDHC_ADMA2_ADDRESS_ALIGN);‍‍‍

Hope this lot is some use. Personally, I'm playing with NuttX at the moment which gives me a whole OS and driver stack where these kinds of issues are dealt with inside the OS.

Good luck!

DAVE

[Bio_TICFSL]

Hi Dave,

Yes  it reduces a lot, but is non-cache, I will mention to developer to make both functions and the costumer choose.

Regards

[dmarples]

Hi,

I'm sorry, but I'm afraid I don't understand your reply ... are you saying that this is indeed a bug, or that there is some other configuration possibility that I haven't considered?

Regards

DAVE