AM6422: AM64x CBASS Errors and Firewall Violation Registers

Hello Dmitri,

Thank you for your query !

Dmitri Verechtchiagine said:

Please confirm that CBASS global registers (TRM Rev J) 
     Table 14-4. CBASS0_GLB Registers, Base Address=45B0 8000h, Length=1024
     Table 14-3887. CBASS_INFRA1_GLB Registers, Base Address=45B0 1000h, Length=1024
are used by the DMSC and software running on A53 and R5F should not use these registers.

A1: 
The AM64x/243x TRM (Rev J / SPRUIM2J) does not contain an explicit statement that the registers within these two CBASS instances - CBASS0_GLB and CBASS_INFRA1_GLB are exclusively reserved for DMSC use, nor does it directly prohibit A53 or R5F software to access them.
What the documentation does establish in related context:
• DMSC controls CBASS infrastructure: The AM64x uses a DMSC (Device Management and Security Controller), a dedicated M3-based controller that manages system-level infrastructure including firewalls, CBASS configuration, and power/clock management. The CBASS GLB registers (exception logging control, destination ID) are system-infrastructure-level MMRs naturally under DMSC's supervision.
• DMSC Firewall protects its own region (Errata i2245): The AM64x errata (SPRZ457J) confirms that by default, DMSC's internal ECC aggregator (DMSC0_ECC_AGGR) firewall blocks all transactions except from the M3 core inside DMSC, meaning access from A53/R5F to DMSC-managed regions is explicitly firewalled unless software explicitly reconfigures the firewall.
• CBASS GLB registers are not application-software registers: The CBASS_GLB_DESTINATION_ID register is R/W (readable and writable as per its bitfield descriptions), but there is no documented use case in the TRM for A53 or R5F software to write to these registers. They are exception-logging infrastructure registers that DMSC and the system controller would manage.

Dmitri Verechtchiagine said:

When the software running on A53/R5F experience a synchronous load/store exception should it examine error registers in the exception handler: 
    CBASS0              Table 14-1. CBASS0_ERR Registers, Base Address=3A00 0000h, Length=1024
    CBASS_FW0        Table 14-3844. CBASS_ERR Registers, Base Address=0022 0000h, Length=1024
    CBASS_INFRA1   Table 14-3884. CBASS_INFRA1_ERR Registers, Base Address=0021 0000h, Length=1024
    CBASS_DBG0      Table 14-4429. CBASS_ERR Registers, Base Address=0020 0000h, Length=1024

A2:
These registers are part of the asynchronous error interrupt path (default_err_intr), as described in the AM64x TRM / Section, Register MMR for default_err_intr. When a CBASS decode error occurs, the EXCEPTION_LOGGING_* registers in the relevant ERR block are updated and the default_err_intr interrupt is asserted toward the interrupt controller (GIC for A53 / VIM for R5F). This is a separate, asynchronous event from the synchronous load/store exception that the processor core takes.
Therefore, the correct place to read and service these CBASS ERR registers is inside the dedicated default_err_intr interrupt handler, not inside the synchronous load/store exception handler. Attempting to poll the CBASS ERR registers from within the synchronous exception handler is not recommended, as the CBASS logging may not yet be complete at the point the synchronous exception handler executes, and doing so conflates two separate error-reporting paths.

I hope this helps clarify.

Best Regards,

Anastas Yordanov

Hello Dmitri,

I am just checking if you had the chance to review the answers.

Let me know if you have any comments/questions ?

Thank you !

Best Regards,

Anastas Yordanov

Hello Anastas,

1. I found two additional blocks of the GLB registers undocumented in TRM: DMSC0_CBASS_GLB (0x45b0_0000) and DMASS0_CBASS_DMSC_GLB (0x45b0_3000). What are their purpose?

2. I found an example of triggering a CBASS error exception in the Jacinto SDK:

github.com/.../main_baremetal.c

In this example the CBASS error registers are read in the external data abort data handler.

I implemented a similar test on a AM64x platform. Also, I added the handler for VIM interrupt 133 mapped to the CBASS default_err_intr. I implemented the interrupt acknowledgment suggested in erratum i2235 "CBASS Null Error Interrupt Not Masked By Enable Register".

When I executed the code after hitting the offending read instruction my code was stuck in the interrupt 133 handler, when I placed a breakpoint inside the interrupt handler the breakpoint was hit all the time. The external data abort interrupt was never reached in this case. Without the breakpoint inside the interrupt 133 handler the code failed and could not be stopped with the debugger.

Interestingly, when I placed a breakpoint on the offending instruction and then did a "step into" the program behavior became normal: first I got the external data abort, then interrupt 133 and then the code continued without issues.

In summary, using default_err_intr appears to be problematic while collecting diagnostic data in the external data abort handler seems to work.

Thank you,

Dmitri