Fix DCache not being invalidated after erasing/writing to flash on i.MX RT10xx

[MulattoKid]

We've encountered issues where erasing/writing to sectors in flash wasn't visible to the application when reading from flash afterwards. We've narrowed it down to being due to reads happening through the memory mapped flash region, which are cached in the DCache. Reads after erases/writes are therefore at risk of being outdated.

Also, it's stated in NXPs documentation that global interrupts should be disabled when erasing/writing to flash when running with XIP.

See https://wolfssl.zendesk.com/hc/en-us/requests/18238 for more details.

This PR shows the changes needed to fix this, but shouldn't necessarily be merged as-is, as I see you have already added hal_cache_invalidate, but it's not implemented for the i.MX platform yet.

[danielinux]

@MulattoKid thanks for the contribution, always appreciated.

It looks like the linker cannot find the DCACHE_InvalidateByRange symbol while linking, in our build tests. Is it necessary to add more .o files in arch.mk for imx_rt* targets?

[dgarske]

Hi @MulattoKid ,

imx_rt.c:(.text.hal_flash_erase+0x26): undefined reference toDCACHE_InvalidateByRange'`

You may just need to include fsl_cache.h, since it appears to be a static inline. You may need to adjust the arch.mk CFLAGS -I for drivers/cm4 and drivers/cm7, etc.

Let me know if you need help. I could push a fix to your PR.

Thanks, David Garske, wolfSSL

[MulattoKid]

Hmm, I'm a bit confused as to where this issue comes from:

multiple definition of `DCACHE_InvalidateByRange'

Perhaps you'll be able to fix this quicker than me @dgarske? :)

Edit: I'll also be going on vacation after this week, so feel free to take over the PR as I won't be able to respond for a while.

[dgarske]

Hi @MulattoKid ,

I am working on the fixes and will push to your branch. I can reproduce the build errors (only with PKA=1).

Thanks, David Garske, wolfSSL