From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: Forced HW_BREAKPOINT
Date: Wed, 1 Dec 2010 16:28:27 -0000 [thread overview]
Message-ID: <004d01cb9174$c8d83ec0$5a88bc40$@deacon@arm.com> (raw)
In-Reply-To: <4CF67525.2010304@ti.com>
> >> I am running an ARM1176JZ-S based SoC, on which HW breakpoints do not
> >> seem to function for some reason.
> >
> > What are the symptoms that you are seeing? The 1176 has debug architecture
> > v6.1 so it should be supported by the code.
> >
>
> Yes, this CPU has a trustzone capable v6.1 debug (DIDR reads
> 0x15121004). The problem I am facing is that DSCR bit 15 (monitor
> debug-mode enable bit) cannot be set, it always reads back 0x2. As a
> result the hw_breakpoint code spews a WARN_ON() at boot.
That's unfortunate. Is there a hardware debugger connected, or does
the core disallow monitor debug full-stop?
> I understand hw_breakpoint's dependency on perf, as well as oprofile's
> dependency on perf. However, if perf does not depend on hw_breakpoint
> (on v6/v7), isn't the select above incorrect?
I was hoping not to give people the option to turn this off in Kconfig
because it will inevitably lead to GDB bug reports complaining that
hardware breakpoints don't work because the option has been misconfigured
in a distro kernel. How about I fix the initcall so that it always succeeds
and prints a helpful message instead of WARNing?
Russell, do you have any thoughts on this (Kconfig vs runtime detection)?
Will
next prev parent reply other threads:[~2010-12-01 16:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-30 23:56 Forced HW_BREAKPOINT Cyril Chemparathy
2010-12-01 9:54 ` Will Deacon
2010-12-01 16:17 ` Cyril Chemparathy
2010-12-01 16:28 ` Will Deacon [this message]
2010-12-01 16:48 ` Cyril Chemparathy
2010-12-01 17:32 ` Will Deacon
2010-12-01 20:14 ` Cyril Chemparathy
2010-12-02 9:37 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='004d01cb9174$c8d83ec0$5a88bc40$@deacon@arm.com' \
--to=will.deacon@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).