Hi,
On Mon, Jan 02, 2017 at 09:15:29PM +0100, Linus Walleij wrote:
> On Mon, Jan 2, 2017 at 4:00 PM, Russell King - ARM Linux
> <linux at armlinux.org.uk> wrote:
> > On Mon, Jan 02, 2017 at 03:34:32PM +0100, Linus Walleij wrote:
> >> in the first line of arch_hw_breakpoint_init() in
> >> arch/arm/kernel/hw_breakpoint.c
> >>
> >> I suspect that is not an accepable solution ...
> >>
> >> It hangs at PC is at write_wb_reg+0x20c/0x330
> >> Which is c03101dc, and looks like this in objdump -d:
> >>
> >> c031020c: ee001eba mcr 14, 0, r1, cr0, cr10, {5}
> >> c0310210: eaffffb3 b c03100e4 <write_wb_reg+0x114>
> >
> > ... and this is several instructions after the address you mention above.
> > Presumably c03101dc is accessing a higher numbered register?
>
> Ah sorry. It looks like this:
>
> c03101dc: ee001ed0 mcr 14, 0, r1, cr0, cr0, {6}
> c03101e0: eaffffbf b c03100e4 <write_wb_reg+0x114>
> c03101e4: ee001ebf mcr 14, 0, r1, cr0, cr15, {5}
> c03101e8: eaffffbd b c03100e4 <write_wb_reg+0x114>
> c03101ec: ee001ebe mcr 14, 0, r1, cr0, cr14, {5}
> c03101f0: eaffffbb b c03100e4 <write_wb_reg+0x114>
> c03101f4: ee001ebd mcr 14, 0, r1, cr0, cr13, {5}
> c03101f8: eaffffb9 b c03100e4 <write_wb_reg+0x114>
FWIW, I was tracking an issue in this area before the holiday.
It looked like DBGPRSR.SPD is set unexpectedly over the default idle
path (i.e. WFI), causing the (otherwise valid) register accesses above
to be handled as undefined.
I haven't looked at the patch in detail, but I guess that it allows idle
to occur between reset_ctrl_regs() and arch_hw_breakpoint_init().
Reading DBGPRSR should clear SPD; but I'm not sure if other debug state
is affected.
Thanks,
Mark.