On Donnerstag, 2. August 2018 15:31:56 CEST Antonio Borneo wrote:
> On Thu, Aug 2, 2018 at 8:24 AM, Michael Schwingen <mich...@schwingen.org>
wrote:
> > On Wed, 01 Aug 2018 22:25:18 +0200
> >
> > Matthias Welwarsky <matth...@welwarsky.de> wrote:
> >> Hi,
> >>
> >> I'm very much wondering if this feature is worth maintaining. Is it
> >> so useful that it's worth the considerable additional complexity for
> >> keeping the caches coherent? Flushing the caches is a very invasive
> >> action by a debugger and will considerably change the context under
> >> debug. If there isn't a compelling argument to keep it I'm much more
> >> in favor of removing it completely instead of trying fixing it.
> Hi Matthias,
> I was questioning myself about this point too.
> Let me split the topic in:
> - CPU debugging (I mean focusing on the code running on one CPU core),
> - system debugging.
>
> From CPU debugging point of view, we probably do not need it; I don't see
> a use case that requires changing the memory through AHB while debugging
> armv7a.
Performance for image uploading could be one possible use case, but I have not
been able to demonstrate a significant gain using AHB access vs CPU access.
I vaguely remember one particular, IMHO obscure platform where you actually
have to bang some registers through AHB in order to being able to reset it (or
actually debug it?).
> What Michael report is correct, but AHB access is not required in that
> case either; the current code in OpenOCD uses the CPU to write the SW
> breakpoints, keeps cache in sync and by-passes the MMU access protection
> through dacrfixup command (maybe the command name is questionable, hard to
> guess if you are not aware of it).
Well, the command is documented in openocd.pdf... But you're right, this
_might_ be a valid use case, for bypassing access protection when setting
software breakpoints.
> Nevertheless, the direct AHB access is extremely useful for system
> debugging, at least for:
> - inspection of memory/peripheral without halting the cores
> - dump log and/or traces from memory while system is running
"mem_ap" pseudo target.
> - in multi-processor environment without HW cache coherency, to debug
> communication and synchronization issues; take a view of the "real"
> content of the shared memory and compare it with the same view got from
> each of the processors
Here however, fiddling with the caches is counter-productive.
> - to debug power management issues, when a core is power-off or its clock
> is frozen
"mem_ap"
> - at platform start/boot, to load the memory faster, knowing that MMU and
> cache are not started yet
Maybe, maybe not, I've tested this on one or two platforms and wasn't able to
demonstrate a noticeable performance gain when using AHB instead of the CPU.
But anyway: "mem_ap"
> Please notice that in all these cases the cache coherence between AHB
> access and the cores is not required! It would even change the system
> status preventing some of the activities above.
Yep.
> Probably all the direct access through the bus should be moved away from
> the specific CPU target; the bus is a "system" resource, not core
> specific.
> In this context your pending gerrit change [1] seams going in the right
> direction and could be a step in the path to remove AHB from
> target/cortex_a.c
> On this change [1] I was arguing if the approach of a virtual/fake target
> was the right choice for a bus access (but let's go ahead).
There is currently nothing in the openocd framework that would allow memory
access through something not a "target". You would anyway want to attach gdb
to have a high-level view of e.g. system-wide data structures, which is only
possible with a "target".
> What I see difficult, at the moment, is to get GDB participating in the use
> cases above.
> GDB does not have a way to specify if the memory access should go through
> the CPU or through the AHB.
Also, it doesn't particularly play well with any form of "background"
debugging. Maybe, if openocd supported "non-stop" mode, but I'm not sure.
> Another of you pending gerrit change [2] aims at presenting OpenOCD
> targets as GDB threads. Today it (seams) targets SMP cores only.
> Do you think this can evolve for supporting generic multi-processing (non
> SMP) in GDB and, eventually, including the memory target in [1] ?
> Such approach would clearly open the door for asymmetric multi-processing
> with GDB. It would also provide an easy access to the AHB bus; select the
> thread corresponding to the memory target, then inspect or load/dump the
> memory.
If gdb properly supported multiple remote inferiors, it should already be
possible. But I have no access to such a system to actually try this. What do
you have in mind anyway when you say "generic" multi-processing?
The "hwthread" rtos anyway only makes sense for debugging OS kernels or
single-system images.
> I'm looking for weaknesses in this approach; comments are welcome!
> Of course, to use the AHB memory target, all the side operations of
> virt2phys translation or cache flush and invalidate should be controlled
> by the user through OpenOCD commands ("monitor ..." in GDB) only if he/she
> really need it, and under its/her responsibility.
Last time I looked gdb didn't care a lot about virtual vs physical addresses.
It knows and understands only the virtual address space its inferior lives in.
>
> Antonio
>
> [1] http://openocd.zylin.com/4002 ("target/mem_ap: generic mem-ap target")
> [2] http://openocd.zylin.com/3999 ("rtos/hwthread: add hardware-thread
> pseudo rtos")
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
