Accessing coresight debug and trace memory region in EL3 leads to stuck.

The manual tells that I can use ETM in both self-host debugging and external debugging. With DStream and DS-5, the ETM works well. However, i find that i can not modify the tracing registers in DS-5, the command always leads to "verify error on memory operation".

Moreover, can i use ETM without JTAG and DStream? I mean i want to enable the tracing and read the ETB from the EL3, i guess it should be feasible as it supports self-host debugging. However, after i plug out the JTAG, I can not read the memory region CSS_DEVICE in trusted firmware. I checked the manual, all the debugging related (CTI, ETM, trace) components are mapped to this region (0x20000000-0x2e000000), but the read operation to this region in EL3 leads to stuck. I am really confused about it. I have checked the MMU page tables and even tried to disable MMU, but i still got stuck.

Really appreciate for any help!

-------------------------------------------------

Edit 09/02/2016: Not only the ETM, if i try to read from the coresight debug and trace memory region (0x20000000-0x23350000) in EL3 without plugging in JTAG, the system just stuck there. I think it is not caused by memory mapping as i got the same result even if i temporarily disabled the MMU. Did i miss something special?

Parents
  • Hi meteor67,

    It is certainly possible to use the ETM and TMC within Juno, from a self-hosted perspective. The issue you might be facing is that the debug logic for both the "big" and "LITTLE" cores is in the power domain for the big "cluster" (i.e. the L2 and coherency logic). When the "big" cluster powers down, you lose access to that memory region.

    There are controls in the core and ETM logic which signal the power controller (SCP) to prevent or emulate power down of components, which is what the debugger does when it connects. If you don't reproduce this in software (and it's difficult if they're not powered up in the first place) then you may find you never get a successful access.

    If you're in EL3 then the possibility is you didn't run ARM Trusted Firmware yet or exited while still only a single core (Cortex-A53) was powered. That makes the problem quite difficult to solve - you probably don't want to write a full power management driver for SCP just to see trace.

    Regarding "verify error on memory operation" - some ETM registers may not be 'verifiable' even if they're accessible, due to status bits and sticky bits. You should access them with EL3<verify=0>:0x2000xxxx or APB_0<verify=0>:0x2000xxxx to prevent the errors in this case.

    Note also that accessing the debug logic from the core vs. over the APB bus from the debugger means you are at the mercy of the CoreSight Lock and OS Lock -- please look up the documentation on the use of LAR/LSR (0xFB) and 0xFB4 offset) and OSLAR/OSLSR (0x300 and 0x304 offset) registers for each CoreSight component you need to access, otherwise the components may not react correctly even if they are powered. How they react is usually documented quite well in the component documentation, and sometimes (particularly with the ETMv4 and core debug logic) also require the component to be "powered up" (not just applied externally, but programmatically - see the ETMv4 TRCPDCR and TRCPDSR, and core EDPRSR and EDPRCR via the memory-mapped interface).

    Ta,

    Matt

Reply
  • Hi meteor67,

    It is certainly possible to use the ETM and TMC within Juno, from a self-hosted perspective. The issue you might be facing is that the debug logic for both the "big" and "LITTLE" cores is in the power domain for the big "cluster" (i.e. the L2 and coherency logic). When the "big" cluster powers down, you lose access to that memory region.

    There are controls in the core and ETM logic which signal the power controller (SCP) to prevent or emulate power down of components, which is what the debugger does when it connects. If you don't reproduce this in software (and it's difficult if they're not powered up in the first place) then you may find you never get a successful access.

    If you're in EL3 then the possibility is you didn't run ARM Trusted Firmware yet or exited while still only a single core (Cortex-A53) was powered. That makes the problem quite difficult to solve - you probably don't want to write a full power management driver for SCP just to see trace.

    Regarding "verify error on memory operation" - some ETM registers may not be 'verifiable' even if they're accessible, due to status bits and sticky bits. You should access them with EL3<verify=0>:0x2000xxxx or APB_0<verify=0>:0x2000xxxx to prevent the errors in this case.

    Note also that accessing the debug logic from the core vs. over the APB bus from the debugger means you are at the mercy of the CoreSight Lock and OS Lock -- please look up the documentation on the use of LAR/LSR (0xFB) and 0xFB4 offset) and OSLAR/OSLSR (0x300 and 0x304 offset) registers for each CoreSight component you need to access, otherwise the components may not react correctly even if they are powered. How they react is usually documented quite well in the component documentation, and sometimes (particularly with the ETMv4 and core debug logic) also require the component to be "powered up" (not just applied externally, but programmatically - see the ETMv4 TRCPDCR and TRCPDSR, and core EDPRSR and EDPRCR via the memory-mapped interface).

    Ta,

    Matt

Children
More questions in this forum