Skip to contentSkip to conversation

Forced HW_BREAKPOINT

DISCUSSION Cyril Chemparathy 2 participants 8 messages Nov 30, 2010 – Dec 2, 2010

Subsystems (2)
Arm (32-bit) Arm PMU profiling and debugging
lore
Share & tools
lore

Cyril Chemparathy

author
#0 lore raw

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

Quoted 1 line

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

#1 lore raw

Hi Cyril,

Quoted 2 lines

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.

Quoted 9 lines

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

Quoted 1 line

+ 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

author
#2 lore raw

Hi Will,

Quoted 8 lines · Will Deacon

Hi Cyril,

Quoted 2 lines

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.

Quoted 10 lines
Quoted 9 lines

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

Quoted 1 line

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

Quoted 6 lines

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.

#3 lore raw
Quoted 11 lines
Quoted 6 lines
Quoted 2 lines

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?

Quoted 3 lines

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

author
#4 lore raw

Hi Will,

On 12/01/2010 11:28 AM, Will Deacon wrote:
[...]

Quoted 8 lines
Quoted 4 lines

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.

#5 lore raw

Cyril,

Quoted 3 lines

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?

arch/arm/kernel/hw_breakpoint.c +7 -8
index 21e3a4a..bcf8437 100644
@@ -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

author
#6 lore raw

Hi Will,

Quoted 8 lines · Will Deacon

Cyril,

Quoted 3 lines

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?

[...]

Quoted 4 lines

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.

#7 lore raw
Quoted 9 lines
Quoted 2 lines

Please can you try this patch?

[...]

Quoted 4 lines

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