This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How the PE accesses peripherals registers and memories?


I was reading this document and found that figure A.11 describes that platform can have on-chip devices connected to the SMMU and peripherals connected through a non-coherent interconnect.

I thought that PE can access all peripherals on the platform through the SMMU, but what is the difference between those two different device types? 

If anyone can provide examples of the peripheral and on-chip devices, it would be really helpful to understand those two different types of devices.



How the memory-mapped devices/registers can be accessible by the PE on ARM architecture?

When It comes to the SMMU, the physical registers of the SMMU for example page 0 registers (e.g., SMMU_IDR0) can be read/written just as exactly same as accessing any other memories with ldr/str instruction. 

Or another example would be frame buffer. It seems that PE can access frame buffer addresses which is pre-configured on the board as exactly same as accessing SMMU registers with generic ldr/str instructions.

In the above figure what would be the path from PE to the memories or registers of the memory transactions? Does it go through the SMMU? or directly goes to the peripherals without going through the SMMU??


Also, it seems that pre-configured physical addresses are used for accessing the peripheral's registers and memories. Does it also mean that the memory transactions of the PE for accessing peripherals registers and memories will be governed by the GPT?



Parents Reply Children
  • I have one follow-up question about is the accessed PAS? Does it mean that the PAS of the requester? 

    Yes, although strictly it's the PAS of the transaction that the requester issued.

    So what I understand based on your answer is GIC have multiple registers exposed to the PE, but they should not be accessible regardless of the world that PE runs on. For example, there are GIC registers designed to be used by only the TZ for providing secure interrupt, and it should not be configurable by the REALM. To enforce it the GIC has internally checks the accessed PAS (PAS specified on the transaction) and deny the accesses if the pre-set PAS of the destination registers does not match with the PAS of the transaction? 

    Let's take a concrete example - GICD_ISPENDR<n>.  On reads this register returns the pending state of SPIs (Shared Peripheral Interrupts).  Writes to this register sets the pending state of SPIs.

    The GIC allows interrupts to be assigned to different Security states, this is done via what the GIC calls "Groups".  On a read of GICD_ISPENDRn the PAS of the transactions is used by the GIC to control what information it exposes.  A Non-secure read will only return information on Non-secure (NS.G1) interrupts.  While the same read using the Secure PAS would return information on Non-secure (NS.G1) and Secure (S.G1 & G0) interrupts.

    We'd call this completer-side filtering.  The GPC check on the Requester allows through accesses with any PAS, and we put the burden on the target completer to use the PAS information appropriately.  In the GIC case, to control which interrupts you can/can't see.  Other peripherals/devices might use information in slightly different ways.