Closed sohil7987 closed 2 months ago
Memory-mapped access (even from the same core) counts as external debug, so this would normally work. Having a core read its own TRC registers is quite normal, this is done not only in CSAL but in the Linux CoreSight device drivers.
What chip is this? It may be that there is some additional access control forcing the abort.
By performing writes to the TRCLAR i could access TRCIDR register. But, the TRCCLAIMSET register is Unknown for the Cortex-A55 processor - reading unknown register is not recommanded by ARM and can lead to unexpected abort.
TRCCLAIMSET is documented for the Cortex-A55 processor, see Cortex-A55 TRM r2p0 section 5.8.15.
Are you able to provide more details about the target that you are using?
The register is UNKNWON at reset - which means the register should be written first prior to read operation to it.
Reading TRCCLAIMSET will return a mask indicating which claim bits are implemented. I believe the "UNK" in Table 5-12 the Cortex-A55 TRM might be inappropriate and should read 0x000000FF. The actual claim tags reset to 0x000000000. I cannot see that reading TRCCLAIMSET before writing to it would cause an abort.
Hi,
I am running a test cs_register_romtable (as a discovery test) from a ARM processor A55. During function cs_device_or_romtable_register, The processor gets abort when it accesses register offset 0xFA0 and 0xFA4 - which are TRCCLAIMSET and TRCCLAIMCLR registers.
As per the Cortex-A55 TRM these register can be accessed only by the external debugger.
Furthermore, The register access to TRCIDR1 (offset 0x1e4) also aborts - due to same reason, this register can be accessed through the external debug interface, offset 0x1E4.
Please advice on how to fix this issue? with some flag ? to indicate that its the processor SW executing this romtable walk test.
Thanks, Sohil