Now, it really makes sense and it matches what I've seen in Eclipse debugger.I think I have a handle on what is going on. The clean by set/way operation is updating the address tag for the dirty line to whatever address offset was used for the maintenance op. (This is either correct or harmless for the other four operations, just not for clean by set/way.) The next access to that offset in the cached space will get a spurious cache hit that returns the PSRAM cache line (assuming it wasn't evicted in between), because the address tag update remapped the line to the maintenance write's offset.
So, when cleaning let's say at 0x1800:0001
- the cache data it correctly written/flushed in PSRAM if it's 'dirty' (blocking in the meantime)
- but then the address tag is overwritten with one corresponding to 0x1000:0000
and so on, effectively poisoning the cache for the first 16 KB of Flash, with already existing cache data from other addresses.
By using a different address offset, (like 0x1bff:c000), it will poison only that portion, which is fine if not used, the poisoned cache lines will be evicted anyway. And it's safer because it's doing it atomically, blocking the other core or DMA to eventually access wrong data between flush and invalidate. Right ?
Another approach, which leaves the cache populated, would be to clean by address, but you need to know which addresses. Otherwise need to flush the whole 8 MB address space, I profiled it at around 10M processor cycles, compared with 100k cycles to flush by line, or less with LukeW's method (would be great to document it in the datasheet).
Thank you ! Image may be NSFW.
Clik here to view.
Statistics: Posted by gmx — Mon Oct 28, 2024 4:01 pm
