[Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Yunseong Kim]

Hi CIX team,

I'm working on vock (https://github.com/yskzalloc/vock), a tool that maps
userspace programs to the exact kernel code they exercise using hardware
trace. On arm64, this relies on CoreSight ETM (--mode hw, for non-kcov
enabled kernel) to collect kernel coverage without requiring CONFIG_KCOV.
Without firmware enabling TRBE or exposing TMC/ETR, I cannot verify or test
the arm64 CoreSight code path on the Orion O6 at all.

I've been testing on a CIX Orion O6 board running Debian sid latest generic kernel
and found that CoreSight trace is not functional due to firmware-level restrictions.

Test environment running Debian sid arm64 kernel:

  Board:    CIX Orion O6
  Kernel:   Debian arm64 generic (7.1+unreleased-arm64, CONFIG_CORESIGHT=m)
  CPU:      Cortex-A520 (0xd81) + Cortex-A720 (0xd80), 12 cores
  Firmware: UEFI/ACPI (no device tree)

What works:

  - coresight_etm4x module loads successfully
  - cs_etm PMU appears at /sys/bus/event_source/devices/cs_etm (type=12)
  - nr_addr_filters = 8

  $ lsmod | grep coresight
  coresight_etm4x       118784  0
  coresight             110592  1 coresight_etm4x

  $ ls /sys/bus/event_source/devices/cs_etm/type
  12

What fails:

  1. No CoreSight bus devices are registered:

     $ ls /sys/bus/coresight/devices/
     (empty)

  2. perf AUX mmap fails (no trace sink available):

     $ perf record -e cs_etm// -- ls
     intel_pt: aux mmap: Cannot allocate memory

  3. TRBE module loads but registers no devices (firmware blocks access):

     $ sudo modprobe coresight-trbe
     $ ls /sys/bus/coresight/devices/
     (empty)

  4. dmesg shows only configuration manager, no ETM/TRBE device probes:

     [ 4479.881313] cs_system_cfg: CoreSight Configuration manager initialised

  5. DSDT has no CoreSight ACPI devices (no ARMHC500/ARMHC501/ARMHC97C HIDs)

Root cause:

  The Cortex-A520 and Cortex-A720 cores support both ETM and TRBE in
  hardware, but the firmware (TF-A/EL3) does not enable OS-level access:

  - TRBE: MDCR_EL3.NSTBE is likely not set, preventing non-secure
    trace buffer access
  - TMC/ETR: No MMIO-mapped trace sinks are described in the ACPI DSDT
  - Self-hosted trace: MDCR_EL3.NSTB / CPTR_EL3.TTA may not be configured


Can you check enabling CoreSight trace support in the Orion O6 firmware by either:

  (1) (Preferred) Enable TRBE access from non-secure EL1/EL2:
     - Set MDCR_EL3.NSTBE = 1 in TF-A
     - This allows the per-CPU Trace Buffer Extension to work as a sink
       without any additional MMIO hardware

  (2) Or expose the full CoreSight topology in ACPI:
     - Add ARMHC97C (TMC-ETR) device with MMIO base address
     - Add ARMHC502 (funnel) devices if applicable
     - Reference: ARM DEN0067 (CoreSight Architecture ACPI bindings)

(1) is simpler and doesn't require ACPI table changes, it's a single register
bit in the secure firmware.


Thank you!

Best regards

Re: [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Yunseong Kim]

I wrote the wrong output:

>      $ perf record -e cs_etm// -- ls
>      intel_pt: aux mmap: Cannot allocate memory

Current output:

     $ perf record -e cs_etm// -- ls
     cs_etm: Not found on CPU 0. Check hardware and firmware support and that all Coresight drivers are loaded 

Re: [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Gary Yang]

On 2026-06-09 10:40, Yunseong Kim wrote:

> [Some people who received this message don't often get email from yunseong.kim@est.tech. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> EXTERNAL EMAIL
> 
> CAUTION: Suspicious Email from unusual domain.
> 
> Hi CIX team,
> 
> I'm working on vock (https://github.com/yskzalloc/vock), a tool that maps
> userspace programs to the exact kernel code they exercise using hardware
> trace. On arm64, this relies on CoreSight ETM (--mode hw, for non-kcov
> enabled kernel) to collect kernel coverage without requiring CONFIG_KCOV.
> Without firmware enabling TRBE or exposing TMC/ETR, I cannot verify or test
> the arm64 CoreSight code path on the Orion O6 at all.
> 
> I've been testing on a CIX Orion O6 board running Debian sid latest generic kernel
> and found that CoreSight trace is not functional due to firmware-level restrictions.
> 
> Test environment running Debian sid arm64 kernel:
> 
>   Board:    CIX Orion O6
>   Kernel:   Debian arm64 generic (7.1+unreleased-arm64, CONFIG_CORESIGHT=m)
>   CPU:      Cortex-A520 (0xd81) + Cortex-A720 (0xd80), 12 cores
>   Firmware: UEFI/ACPI (no device tree)
> 
> What works:
> 
>   - coresight_etm4x module loads successfully
>   - cs_etm PMU appears at /sys/bus/event_source/devices/cs_etm (type=12)
>   - nr_addr_filters = 8
> 
>   $ lsmod | grep coresight
>   coresight_etm4x       118784  0
>   coresight             110592  1 coresight_etm4x
> 
>   $ ls /sys/bus/event_source/devices/cs_etm/type
>   12
> 
> What fails:
> 
>   1. No CoreSight bus devices are registered:
> 
>      $ ls /sys/bus/coresight/devices/
>      (empty)
> 
>   2. perf AUX mmap fails (no trace sink available):
> 
>      $ perf record -e cs_etm// -- ls
>      intel_pt: aux mmap: Cannot allocate memory
> 
>   3. TRBE module loads but registers no devices (firmware blocks access):
> 
>      $ sudo modprobe coresight-trbe
>      $ ls /sys/bus/coresight/devices/
>      (empty)
> 
>   4. dmesg shows only configuration manager, no ETM/TRBE device probes:
> 
>      [ 4479.881313] cs_system_cfg: CoreSight Configuration manager initialised
> 
>   5. DSDT has no CoreSight ACPI devices (no ARMHC500/ARMHC501/ARMHC97C HIDs)
> 
> Root cause:
> 
>   The Cortex-A520 and Cortex-A720 cores support both ETM and TRBE in
>   hardware, but the firmware (TF-A/EL3) does not enable OS-level access:
> 
>   - TRBE: MDCR_EL3.NSTBE is likely not set, preventing non-secure
>     trace buffer access
>   - TMC/ETR: No MMIO-mapped trace sinks are described in the ACPI DSDT
>   - Self-hosted trace: MDCR_EL3.NSTB / CPTR_EL3.TTA may not be configured
> 
> 
> Can you check enabling CoreSight trace support in the Orion O6 firmware by either:
> 
>   (1) (Preferred) Enable TRBE access from non-secure EL1/EL2:
>      - Set MDCR_EL3.NSTBE = 1 in TF-A
>      - This allows the per-CPU Trace Buffer Extension to work as a sink
>        without any additional MMIO hardware
> 
>   (2) Or expose the full CoreSight topology in ACPI:
>      - Add ARMHC97C (TMC-ETR) device with MMIO base address
>      - Add ARMHC502 (funnel) devices if applicable
>      - Reference: ARM DEN0067 (CoreSight Architecture ACPI bindings)
> 
> (1) is simpler and doesn't require ACPI table changes, it's a single register
> bit in the secure firmware.
> 

Thank you for your interest in the Radxa O6 board and for the detailed report 
on the CoreSight trace support.

The firmware (TF-A) for the Radxa O6 is provided and maintained by Radxa. We 
will forward your request to the Radxa firmware team and ask them to evaluate 
enabling TRBE access from non-secure EL1/EL2 (i.e. setting MDCR_EL3.NSTBE = 1 
in TF-A), as you suggested.

We will notify you via email once there is a firmware update available.

Best Regards
Gary
> 
> Thank you!
> 
> Best regards

Re: [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Leo Yan]

On Wed, Jun 10, 2026 at 03:42:25PM +0800, Gary Yang wrote:

[...]

> >   (2) Or expose the full CoreSight topology in ACPI:
> >      - Add ARMHC97C (TMC-ETR) device with MMIO base address
> >      - Add ARMHC502 (funnel) devices if applicable
> >      - Reference: ARM DEN0067 (CoreSight Architecture ACPI bindings)

The CPUs on O6 support ETE + TRBE, you don't need to use ETR or funnel
modules.

> The firmware (TF-A) for the Radxa O6 is provided and maintained by Radxa. We 
> will forward your request to the Radxa firmware team and ask them to evaluate 
> enabling TRBE access from non-secure EL1/EL2 (i.e. setting MDCR_EL3.NSTBE = 1 
> in TF-A), as you suggested.

The issue is caused by ACPI: the APIC table does not contain a TRBE
interrupt, and the SSDT is missing ETE nodes (ETE node should be
present for each CPU):

  Device (CPU0)
  {
    ...

    Device ( ETE0 ) {
        Name (_UID, Zero)
        Name (_HID , "ARMHC500")
    }
  }

Thanks,
Leo

Re: [Question] Enabling CoreSight TRBE in firmware on CIX Orion O6

[Yunseong Kim]

Hi,

> On Wed, Jun 10, 2026 at 03:42:25PM +0800, Gary Yang wrote:
> 
> [...]
> 
>>>   (2) Or expose the full CoreSight topology in ACPI:
>>>      - Add ARMHC97C (TMC-ETR) device with MMIO base address
>>>      - Add ARMHC502 (funnel) devices if applicable
>>>      - Reference: ARM DEN0067 (CoreSight Architecture ACPI bindings)
> 
> The CPUs on O6 support ETE + TRBE, you don't need to use ETR or funnel
> modules.
> 
>> The firmware (TF-A) for the Radxa O6 is provided and maintained by Radxa. We 
>> will forward your request to the Radxa firmware team and ask them to evaluate 
>> enabling TRBE access from non-secure EL1/EL2 (i.e. setting MDCR_EL3.NSTBE = 1 
>> in TF-A), as you suggested.
> 
> The issue is caused by ACPI: the APIC table does not contain a TRBE
> interrupt, and the SSDT is missing ETE nodes (ETE node should be
> present for each CPU):
> 
>   Device (CPU0)
>   {
>     ...
> 
>     Device ( ETE0 ) {
>         Name (_UID, Zero)
>         Name (_HID , "ARMHC500")
>     }
>   }
> 
> Thanks,
> Leo


Thanks, Gary and Leo.                                                                           

I'm looking forward to adding arm64 CoreSight usage on CIX Orion O6 board.

If the board supports CoreSight, I'll make sure to write on the perf tools Wiki:

  https://perf.wiki.kernel.org/index.php/Main_Page

Best regards,
Yunseong