ARMv8 manual says that we can make system register access to trace registers and PMU registers trap to EL3. However, ETM and PMU in Juno can be accessed through memory-mapping interface. Is there anyway to make the memory-mapping access also trapping to EL3 or secure only?
Also, I found that TrustZone Protection Controller should be able to control the accessibility of peripherals, does Juno contain TZPC?
Hi Zhenyu,
Architecturally, no - the sane default is that if Secure debug is enabled then Non-Secure debug is enabled, too. What the architecture (and implementation on Juno) offers is a way to prevent the ETM and PMU emitting trace or performance data while in Secure state, and also nominally in EL2 for Non-Secure.
If there is some kind of protection controller in the system that allows ETM and PMU access from the Secure world but not the Non-Secure world then it would have to be integrated at the cluster level or at a higher level placed between the APB interconnect inside the DAP and the system interconnect. It might be possible to prevent access to the entire debug APB since they'll all share a master port on the system interconnect (which a TZPC might be able to reconfigure access to), but I'm not sure that is implemented on Juno. If it is, then the effect is loss of access to all the debug components in the Non-Secure world, not just the ETM and PMU, which might not be what you want.
Ta,
Matt
Hi Matt,
Thanks for your reply. I checked the SoC manual of Juno, but it seems that Juno does not contain TZPC. However, your explain remind me another problem. Did you remember the issue that accessing to CoreSight memory region leads to stuck? Is it possible that when DS-5 connects to the board, it enables the debug components by some other kind of protection controller?
Regards,
Zhenyu
Zhenyu,
I remember the issue, I think we decided that SCP firmware (possibly combined with Linux kernel support for knowing which power domain is which) is the likely culprit. I believe Sudeep asked which SCP firmware version you had?
The absolute most likely situation is a powered-off component. None of ARM's TZPC or TZASC controllers will "hang" a transaction due to a security policy -- that in and of itself would be a denial of service.
You should continue that line of investigation in that thread, so we're not answering the same questions twice..
Thanks for your reply! I will reply to Sudeep soon.
Now i think Juno should have implemented some kind of protection control on the debug APB. I noticed that on the SoC manual of Juno r1, Section 3.3.5 describes the whole application memory map. In the section, the memory regions of ETM and PMU are marked as "Programmable access security", which indicates they could be configured as secure access only through NIC-400. However, I did not get how to configure the two NIC-400s in Juno at this moment, but I think that should be feasible.
I don't think we clearly document exactly what that programmable access security actually means. It could be referencing the SPIDEN/SPNIDEN authentication signals, which aren't easily modified from the AP.
Thanks for your reply. In the Section 3.3, page 3-10 of the Juno r1 SoC manual, it says that,
Programmable access security, also called securable
Components or regions that are defined to be independently
software-configurable. Trusted software can change them between the ‘always
Secure access’ and ‘Secure and Non-secure access’ access. You can configure
these in the NIC-400, or in the component itself, and the default state is ‘Secure
access only’ from reset.
I guess that means it should be configureable through NIC-400. However, I am not sure i got the real meaning of the paragraph.
I wouldn't guess that at all. The paragraph is, at best, entirely ambiguous.
View all questions in Arm Development Platforms forum