[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