coresight: cpu-debug: PC sampling via PMPCSR (FEAT_PCSRv8p2)?

coresight: cpu-debug: PC sampling via PMPCSR (FEAT_PCSRv8p2)?

[Igor Velkov]

Hi,

Cortex-A55 (Amlogic S905X3) reports EDDEVID.PCSample = 0, so
coresight-cpu-debug cannot use it. The PC is available through PMPCSR
in the external PMU frame (debug frame + 0x20000, PMDEVID.PCSample = 1).
A lab module reading PMPCSR caught the PC of a CPU stuck on a PCIe bus
access with IRQs off; on this GICv2 SoC the stop IPI never reaches it.

Two observations:
- A panic notifier samples too late: the other CPUs are stopped by
  then, and on this SoC reading the PMU frame of a stopped CPU raises a
  synchronous external abort. Sampling on entry to smp_send_stop()
  works.
- Marvell has an out-of-tree patch, "coresight: cpu-debug: Add support
  to dump PMPCSR" (2023, carried in linux-yocto); I could not find it
  on the lists.

Is PMPCSR support in coresight-cpu-debug planned or welcome? And how
should such a PMU frame be described in DT: arm,coresight-cpu-debug or
a new compatible?

Thanks,
Igor

Re: coresight: cpu-debug: PC sampling via PMPCSR (FEAT_PCSRv8p2)?

[Suzuki K Poulose]

Hi Igor

On 13/11/2026 05:46, Igor Velkov wrote:
> Hi,
> 
> Cortex-A55 (Amlogic S905X3) reports EDDEVID.PCSample = 0, so
> coresight-cpu-debug cannot use it. The PC is available through PMPCSR
> in the external PMU frame (debug frame + 0x20000, PMDEVID.PCSample = 1).
> A lab module reading PMPCSR caught the PC of a CPU stuck on a PCIe bus
> access with IRQs off; on this GICv2 SoC the stop IPI never reaches it.
> 
> Two observations:
> - A panic notifier samples too late: the other CPUs are stopped by
>    then, and on this SoC reading the PMU frame of a stopped CPU raises a
>    synchronous external abort. Sampling on entry to smp_send_stop()
>    works.
> - Marvell has an out-of-tree patch, "coresight: cpu-debug: Add support
>    to dump PMPCSR" (2023, carried in linux-yocto); I could not find it
>    on the lists.
> 
> Is PMPCSR support in coresight-cpu-debug planned or welcome? And how

Patches are definitely welcome, as such I don't know of anyone working
on it from within Arm. So, please go ahead and post it.

> should such a PMU frame be described in DT: arm,coresight-cpu-debug or
> a new compatible?

If the support can be detected using the "standard" cpu-debug frame,
via the DEVID registers, I don't think we need a new compatible.

But we can debate on it with the patch review.

Cheers
Suzuki

> 
> Thanks,
> Igor

Re: coresight: cpu-debug: PC sampling via PMPCSR (FEAT_PCSRv8p2)?

[Leo Yan]

Hi,

On Fri, Nov 13, 2026 at 07:46:41AM +0200, Igor Velkov wrote:
> Hi,
> 
> Cortex-A55 (Amlogic S905X3) reports EDDEVID.PCSample = 0, so
> coresight-cpu-debug cannot use it. The PC is available through PMPCSR
> in the external PMU frame (debug frame + 0x20000, PMDEVID.PCSample = 1).
> A lab module reading PMPCSR caught the PC of a CPU stuck on a PCIe bus
> access with IRQs off; on this GICv2 SoC the stop IPI never reaches it.
> 
> Two observations:
> - A panic notifier samples too late: the other CPUs are stopped by
>   then, and on this SoC reading the PMU frame of a stopped CPU raises a
>   synchronous external abort. Sampling on entry to smp_send_stop()
>   works.

Arm ARM, section I5.3.48 PMPCSR mentions "PMPCSR is in the Core power
domain". The challenge is ensuring that the target core remains powered
_throughout_ the access; checking its power state beforehand still
leaves a race.

For example, with CPUidle enabled, a CPU can be powered off any time so
it still race even move sampling in smp_send_stop().

This seems to be the main challenge. I'll check a bit if any guidance
for safely accessing PMPCSR.

> - Marvell has an out-of-tree patch, "coresight: cpu-debug: Add support
>   to dump PMPCSR" (2023, carried in linux-yocto); I could not find it
>   on the lists.
> 
> Is PMPCSR support in coresight-cpu-debug planned or welcome? And how
> should such a PMU frame be described in DT: arm,coresight-cpu-debug or
> a new compatible?

Would it make sense to describe external PMU frames in the PMU node
and have cpu-debug reference its phandle? As Suzuki mentioned, this
can be reviewed on patch.

Thanks,
Leo