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

[Tomas V. <to...@us...>]

See
http://openocd.zylin.com/4429

With this change applied you can use hw breakpoints in Cortex-M7 RAM 
with ICache enabled.
To do so set
     cortex_m maskisr auto_hard_bp (also 'on' or 'off' can be used)
and either
     gdb_breakpoint_override hard
or use hbreak in gdb.

Tomas


On 22.02.2018 18:57, Tomas Vanek via OpenOCD-user wrote:
> The bad news is both hbreak handling and gdb_breakpoint_override 
> command are broken on Cortex-M.
> Looks like a soft bp is always used for RAM region.
>
> The good news is that CSW bit 27 really enables debug access though 
> dcache.
>
> Tomas
>
> On 22.02.2018 12:03, Matthias Welwarsky wrote:
>> 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
>>
>>
>> ------------------------------------------------------------------------------ 
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> OpenOCD-user mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openocd-user
>>
>
>
> ------------------------------------------------------------------------------ 
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> OpenOCD-user mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openocd-user
>