Forced HW_BREAKPOINT

Forced HW_BREAKPOINT

[Cyril Chemparathy]

Hi,

I am running an ARM1176JZ-S based SoC, on which HW breakpoints do not
seem to function for some reason.

Unfortunately the current Kconfig forces HW_BREAKPOINT if PERF_EVENTS is
enabled on ARMV6 (commit 19852e59002fbba1c2c6ba0f154095a37ad2ac03):

> +       select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V7))

As a result, I am unable to use the PMU for OProfile, without having hw
breakpoints barf at boot.  Is there any dependency between h/w
breakpoints and PMU that I am missing?  If not, does H/W breakpoints
have be forced here?

Regards
Cyril.

Forced HW_BREAKPOINT

[Will Deacon]

Hi Cyril,

> 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.
 
> Unfortunately the current Kconfig forces HW_BREAKPOINT if PERF_EVENTS is
> enabled on ARMV6 (commit 19852e59002fbba1c2c6ba0f154095a37ad2ac03):
> 
> > +       select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V7))
> 
> As a result, I am unable to use the PMU for OProfile, without having hw
> breakpoints barf at boot.  Is there any dependency between h/w
> breakpoints and PMU that I am missing?  If not, does H/W breakpoints
> have be forced here?

The hw_breakpoint code depends on 1.) perf and 2.) hardware debug capabilities.
Since all v6 and v7 cores are supported (at least, everything should fail
gracefully if something is awry) then I don't see the point in not having it
enabled. However, if this is causing your board to break during boot we
should either fix it or allow it to be turned off.

Can you give me some more details about how it breaks please as I don't
have an 1176 that I can get my hands on?

Thanks,

Will

Forced HW_BREAKPOINT

[Cyril Chemparathy]

Hi Will,

On 12/01/2010 04:54 AM, Will Deacon wrote:
> Hi Cyril,
> 
>> 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.

>> Unfortunately the current Kconfig forces HW_BREAKPOINT if PERF_EVENTS is
>> enabled on ARMV6 (commit 19852e59002fbba1c2c6ba0f154095a37ad2ac03):
>>
>>> +       select HAVE_HW_BREAKPOINT if (PERF_EVENTS && (CPU_V6 || CPU_V7))
>>
>> As a result, I am unable to use the PMU for OProfile, without having hw
>> breakpoints barf at boot.  Is there any dependency between h/w
>> breakpoints and PMU that I am missing?  If not, does H/W breakpoints
>> have be forced here?
> 
> The hw_breakpoint code depends on 1.) perf and 2.) hardware debug capabilities.
> Since all v6 and v7 cores are supported (at least, everything should fail
> gracefully if something is awry) then I don't see the point in not having it
> enabled. However, if this is causing your board to break during boot we
> should either fix it or allow it to be turned off.
> 

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?

Regards
Cyril.

Forced HW_BREAKPOINT

[Will Deacon]

> >> 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

Forced HW_BREAKPOINT

[Cyril Chemparathy]

Hi Will,

On 12/01/2010 11:28 AM, Will Deacon wrote:
[...]
>> 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?
> 

This was without a debugger connected.  It is possible that I have
missed some top level debug enable in the SoC (haven't traced through
the entire logic yet).

Regards
Cyril.

Forced HW_BREAKPOINT

[Will Deacon]

Cyril,

> This was without a debugger connected.  It is possible that I have
> missed some top level debug enable in the SoC (haven't traced through
> the entire logic yet).

Please can you try this patch?


diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 21e3a4a..bcf8437 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -268,9 +268,6 @@ static u8 get_max_wp_len(void)
        if (debug_arch < ARM_DEBUG_ARCH_V7_ECP14)
                goto out;
 
-       if (enable_monitor_mode())
-               goto out;
-
        memset(&ctrl, 0, sizeof(ctrl));
        ctrl.len = ARM_BREAKPOINT_LEN_8;
        ctrl_reg = encode_ctrl_reg(ctrl);
@@ -784,15 +781,18 @@ static void __init reset_ctrl_regs(void *unused)
 
 static int __init arch_hw_breakpoint_init(void)
 {
-       int ret = 0;
        u32 dscr;
 
        debug_arch = get_debug_arch();
 
        if (debug_arch > ARM_DEBUG_ARCH_V7_ECP14) {
                pr_info("debug architecture 0x%x unsupported.\n", debug_arch);
-               ret = -ENODEV;
-               goto out;
+               return 0;
+       }
+
+       if (enable_monitor_mode()) {
+               pr_warning("unable to activate monitor debug mode.\n");
+               return 0;
        }
 
        /* Determine how many BRPs/WRPs are available. */
@@ -829,8 +829,7 @@ static int __init arch_hw_breakpoint_init(void)
        hook_ifault_code(2, hw_breakpoint_pending, SIGTRAP, TRAP_HWBKPT,
                        "breakpoint debug exception");
 
-out:
-       return ret;
+       return 0;
 }
 arch_initcall(arch_hw_breakpoint_init);


This should cause the hw_breakpoint stuff to give up if monitor-mode
cannot be enabled.

Will

Forced HW_BREAKPOINT

[Cyril Chemparathy]

Hi Will,

On 12/01/2010 12:32 PM, Will Deacon wrote:
> Cyril,
> 
>> This was without a debugger connected.  It is possible that I have
>> missed some top level debug enable in the SoC (haven't traced through
>> the entire logic yet).
> 
> Please can you try this patch?
> 
[...]
> 
> 
> This should cause the hw_breakpoint stuff to give up if monitor-mode
> cannot be enabled.

Could we also scale down the WARN_ONs in enable_monitor_mode?

Regards
Cyril.

Forced HW_BREAKPOINT

[Will Deacon]

> > Please can you try this patch?
> >
> [...]
> >
> >
> > This should cause the hw_breakpoint stuff to give up if monitor-mode
> > cannot be enabled.
> 
> Could we also scale down the WARN_ONs in enable_monitor_mode?

That was my next step, I just wanted to make sure that those
changes allow you to get to a prompt (since I don't have any
1176 hardware). I have a bunch of changes pending in this area
so I'll add this to the stack.

Will