---
**[tickets:#438] Software breakpoints on m4k broken.**
**Status:** new
**Milestone:** 0.11.0
**Created:** Thu Oct 03, 2024 05:04 PM UTC by Siggi
**Last Updated:** Thu Oct 03, 2024 05:04 PM UTC
**Owner:** nobody
I've been setting up to debug an Edgerouter-X, which uses the mt7621 SoC, which
in turn is a dual-core, 4 thread m4k.
I found that software breakpoints were badly broken when attempting to debug
the Linux kernel. While the mt7621 has hardware breakpoints, it only has two,
and the brokenness in the software breakpoints makes it awkward to even
continue from a hardware breakpoint.
There are two issues:
1. The writes that insert the SDBBP instruction or restore the original
instruction don't flush the cache. Apparently the m4k has some caching modes
that weren't foreseen by the code.
2. The debug entry cause on SDBBP instruction was not derived correctly. It
seems in order to identify the breakpoint cause on SDBBP exception, it's
necessary to look at the Bp bit of the Debug register (CP0, 23,0). I did try
and get this from the Cause register (CP0,13,0), which according to the m4k
docs should have a distinct code in the Exc Code field, but this didn't work in
testing, so I guess under EJTAG debugging this cause is only indicated in the
Debug register.
I have a [small patch
prepared](https://github.com/sigurasg/openocd/tree/m4k-breakpoints) that fixes
both issues, which I will upload it to gerrit and see about getting it landed.
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
