Re: [OpenOCD-user] Cortex-M7 cache versus debugging

[Matthias W. <mat...@we...>]

On Donnerstag, 22. Februar 2018 11:19:55 CET Tomas Vanek wrote:
> On 22.02.2018 11:05, Matthias Welwarsky wrote:
> > On Donnerstag, 22. Februar 2018 10:39:29 CET Tomas Vanek wrote:
> >> On 22.02.2018 9:58, Matthias Welwarsky wrote:
> >>> On Donnerstag, 22. Februar 2018 09:29:26 CET Tomas Vanek wrote:
> >>>> On 22.02.2018 9:10, Matthias Welwarsky wrote:
> >>>>> On Donnerstag, 22. Februar 2018 08:55:46 CET Thomas Dörfler wrote:
> >>>>>> Hi Matthias,
> >>>>>> 
> >>>>>> using the single-stepping support wouldn't solve the caching issue.
> >>>>>> Even
> >>>>>> if
> >>>>>> you use single-stepping support will once again execute the
> >>>>>> breakpoint
> >>>>>> instruction, which is still in i-cache, AFAIK...
> >>>>> 
> >>>>> I looked into the cortex-m7 trm and the ARMv7-M architecture reference
> >>>>> manual, looks like we need to add at least some level of cache support
> >>>>> also for the cortex_m target. The registers are fortunately all memory
> >>>>> mapped and so it's likely quite straight forward "copy" of the
> >>>>> cortex_a
> >>>>> code, keeping in mind that we do memory accesses through the AHB
> >>>>> interface and not through the CPU core.
> >>>>> 
> >>>>> That means, when setting or removing a breakpoint we need to
> >>>>> 1 - flush the affected cacheline out of the dcache. since code is
> >>>>> read-only, we might even get away with a d-cache invalidate but I
> >>>>> think
> >>>>> it's safer to just flush the line out.
> >>>>> 2 - set/remove the breakpoint
> >>>>> 3 - invalidate the instruction cache
> >>>>> 
> >>>>> We don't need to identify the cacheline size, but we may need to check
> >>>>> if
> >>>>> we have caches enabled or not. All in all, maybe 20 lines of code.
> >>>> 
> >>>> Please be aware that there is another Cortex-M7 cache issue besides
> >>>> broken RAM breakpoints.
> >>>> As memory is accessed through AHB, a debugger needs to flush whole data
> >>>> cache at debug mode enter
> >>>> to see actual value of memory variables/stack. And similarly data cache
> >>>> invalidate is needed
> >>>> at resume to ensure CPU will use values changed by the debugger.
> >>> 
> >>> Yes, you're correct, didn't think of that. That will slow down debug
> >>> entry
> >>> and exit quite a bit :-( Does the debug unit allow memory access through
> >>> the CPU? That will need quite some code to be ported from armv7a.
> >> 
> >> I'm not aware of any possible way to memory access through CPU - it
> >> still Cortex-M only.
> >> On the other hand
> >> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489b/BABE
> >> FHA>> 
> >> D.html reads:
> >>    *
> >>    
> >>      The instruction cache is not accessible to a debugger. Therefore
> >>      debugger accesses to cacheable, executable regions of memory might
> >>      not be coherent with the instructions visible to the instruction
> >>      side of the processor.
> >>    
> >>    *
> >>    
> >>      The data cache must be enabled by setting the CCR.DC to 1 to read
> >>      and write data to the cache. If CCR.DC is set to 0 all debug
> >>      requests to memory regions outside the TCM and peripheral address
> >>      space will access only the external memory on AXIM even if the debug
> >>      request is marked as cacheable on the AHBD interface.
> >> 
> >> 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!
> 
> Yes, looks like setting bit 27 (cacheable) in CSW would do the trick on
> AMBA 3 AHB-Lite
> The question is if we can do all access with "cacheable" or it'll break
> something...

A "dap hprot" command that you only use in target files for cortex-m7?
Or a variant of the mem_ap_read/write commands that carry access protection 
info?
 
> > The section about instruction caches just means that we need to maintain
> > coherency in software when we set software breakpoints.
> > 
> >> Or am I missing something?
> >> 
> >> Tomas