|
From: Matthias W. <mat...@we...> - 2018-02-22 10:18:53
|
On Donnerstag, 22. Februar 2018 11:05:28 CET Matthias Welwarsky wrote: > On Donnerstag, 22. Februar 2018 10:39:29 CET Tomas Vanek wrote: > > The second paragraph looks like if CCR.DC = 1 debug mem access goes > > through dcache. But it's obviously not true based on experience with > > real HW. > > That's how I read it, too, but: you need to make sure that the memory access > is marked as "cacheable", which I'm not sure openocd supports yet. If it > works, it means that we don't need to flush the cache on debug entry. That > would be very nice! > > The section about instruction caches just means that we need to maintain > coherency in software when we set software breakpoints. The section 9.2 explicitly states: The 32-bit AHB debug (AHBD) interface implements the AMBA 3 AHB-Lite protocol. It can be used with a CoreSight AHB-AP to provide debugger access to: • A view of memory that is consistent with that observed by load/store instructions acting on the processor. There you go, no d-cache flush needed, but also cache maintenance for software breakpoints will now have to clean the data cache to make sure that the changed instruction is visible. Just the sequence will change a little: 1- cacheable read to save the original instruction 2- cacheable write to install the bp 3- d-cache clean to PoU so that i-cache can see it 4- invalidate i-cache and btb BR, Matthias |