Tool/software:
Hi,
custter has uncovered an issue present in the am64x MCU plus sdk (09_01_00_41 but still present in 11_00_00_15):
The problem appears when using the MCSPI driver and enabling -flto when linking as does several of the examples in the sdk, such as the enet_layer2_icssg. When this happens, the gMcspiXUdmaRxRingMemCh0 is correctly aligned to the cache alignment (set to 128, though the IC has 32byte cache lines), but any other sections with less strict alignment can follow. In their case, gMcspi1UdmaRxRingMemCh0 is 8 bytes was linked just before an important linked list. The result is that when CacheP_inv is called deep within the sdk udma code, recent changes to a single link in the linked list are lost.
There are some potential solutions and workarounds to the issue
- Pad the gMcspiXUdmaRxRingMemCh0 and any other buffer that eventually gets passed to CacheP_* functions to the length of a cache line, to ensure regardless of whether fdata-sections or flto are enabled the code will be correct. This requires patching the sdk!
- Disabling -flto which increases overall binary size and memory consumption.
- Ensure the syscfg generated files do not participate in flto, in this case manually adding entries in the linker that the syscfg generated files are kept together. Seems to work but it can’t prove it’s sound since that still results in other symbols potentially being partially cache invalidated.
Is there is a better workaround available?
May be that other drivers have similar potential issues as well.
Regards, Holger
