Hi experts,
Based on the manual of TZC-400, we could set up at most 8 regions with different security settings.
However, I'm wondering, when a normal world(non-secure) application read or write a specific address, how does the TZC-400 decide whether the address is secure or not?
I think region 1-8 could overlap addresses with each other so I'm confused about how to decide the security of an address.
Any suggestion or discussion is welcomed.
Thank you.
Simon
Hi ashwildingarm,
Thank you for the replying. I did read this section before.
However, based on the document I read, the filters only check the operations from those "master" like GPU, USB and so on.
So I'm wondering does the filter also check the operations from the CPU? If it does, is there any document describe how the filter output the signals about CPU read/write?
Thank you again for your help.
Shengye
Hello,
No problem
Regarding your question; the TZC-400 can be conceptually split into two separate bits of functionality.
The first is being able to define whether a region of memory sitting behind the TZC-400 is Secure or Non-secure. When an AXI master makes an access the AXPROT signal will be asserted or deasserted to indicate whether that access is Secure or Non-secure, with Non-secure accesses being blocked to Secure regions of memory. Note that the TZC-400 can also be configured to block Secure accesses to Non-secure regions.
The second bit of TZC-400 functionality only applies when the region being accessed is Non-secure, whereby the TZC-400 can filter accesses based on the master making that access. This is achieved using a Non-secure Access IDentity (NSAID) input signal that must match the NSAID(s) specified by the corresponding filter.
As an example on the ARM Juno development board:
Where, I believe, NSAID 9 (AP) corresponds to the applications processors, i.e. the Cortex-A53 and Cortex-A57 (or Cortex-A72 on Juno r2) cores.
Hope that helps,
Ash.
Thank you so much ashwildingarm!
My understanding about your explanation is that all processors' NSAID outputs would be 9, is this correct?
If it is correct, can I configure the output signal of NSAID? For example, can I configure Cortex-A53 and Cortex-A57 with different number?
I want to know this because I think NSAID signals could be up to 15 while you only show the number 0-12.
Also, about the part
TZC-400 can also be configured to block Secure accesses to Non-secure regions
, there is one thing unclear for me in the TZC-400 document about secure access.
I know each region has an attribute register where I could configure the secure R/W bits, however I don't know how does the TZC-400 map one secure R/W to the related region.
Is the secure access mapping also done by the filters?
If it is done by the filters, then I'm wondering how does the TZC-400 pass one access to one of the four filters.
If it is not, then I think 2 regions might contain same address and I don't know how could we find specific region for one secure access.
Sorry I got so many questions. If there is any code about configuring TZC-400 or more documents about TZC-400 like the NSAID part you show above, please share them with me so I could check them by myself and save your time, thank you
Hi Simon,
On the Juno development board, yes, all A-class cores (Cortex-A53 / Cortex-A57 / Cortex-A72) are NSAID 9. This will not necessarily be the case on other systems or in other designs.
can I configure the output signal of NSAID? For example, can I configure Cortex-A53 and Cortex-A57 with different number?I want to know this because I think NSAID signals could be up to 15 while you only show the number 0-12.
can I configure the output signal of NSAID? For example, can I configure Cortex-A53 and Cortex-A57 with different number?
From the Juno SoC Technical Reference Manual (TRM) (ARM DDI0515F) section 2.7.3 under the heading `CoreLink TZC-400 TrustZone Address Space Controller security' you'll see a list of the Juno development board's NSAIDs. That list shows that NSAIDs 7, 8, 13, 14, and 15 and all Reserved. In your own hardware design you would be able to use the 15 available NSAIDs in any way you'd like, but there's no way to change this on the Juno board.
I know each region has an attribute register where I could configure the secure R/W bits, however I don't know how does the TZC-400 map one secure R/W to the related region.Is the secure access mapping also done by the filters?If it is done by the filters, then I'm wondering how does the TZC-400 pass one access to one of the four filters.
This is controlled by the region's corresponding REGION_ATTRIBUTES_<n> register, specifically bits [31] s_wr_en (Secure global write enable) and [30] s_rd_en (Secure global read enable).
Quoting the TZC-400 TRM again, specifically from section 2.2.1:
For region 1 and higher, any enabled region in a filter unit must not overlap memory areas from another enabled region in the same filter unit.Regions 1 and higher can have address regions that overlap with each other, but only if they are set for different filters.The behavior of the TZC-400 is UNDEFINED for configurations where Regions 1 and higher overlap when enabled on the same filter unit. When an access to an overlapping region occurs, the TZC-400 sets a status bit to indicate an overlapping access. The TZC-400 can generate an interrupt when this occurs. Interrupt generation is a programmable feature of the TZC-400.
The reason the spec mentions "in the same filter unit" is best explained by Figure 1-2 of the TRM; note how each master's accesses to DRAM pass through exactly one filter unit. So using that example system, you could have a region that is specificed as Secure R/W on filter unit 0, overlapping with a region that is specified as Secure no-access on filter unit 1 and this is OK; Secure accesses passing through filter unit 0 (i.e. from one of the A-class processors or GPU) can read and write the region, while Secure accesses passing through filter unit 1 (i.e. from the DMA or LCD) cannot access the region.
No problem Yes, ARM Trusted Firmware has a TZC-400 driver that is configured here for the Juno development board.
Note that the older less generic ARM Trusted Firmware code in tag v1.1-Juno-0.1 may be a bit easier to learn from. Here's the TZC-400 driver in that tag, and here's where it's configured for the Juno platform.
Hi Ash,
I think you already answered all my questions very clearly above so I marked the above answer as the correct one. Hope it could help other users too!
I just got last question based on your reply, when you mentioned
Secure accesses passing through filter unit 0 (i.e. from one of the A-class processors or GPU) can read and write the region, while Secure accesses passing through filter unit 1 unit 1 (i.e. from the DMA or LCD) cannot access the region.
How does the board configure the filter unit 0 for AP / GPU while filter unit 1 for DMA/LCD? I tried to search the firmware code while I don't get where it is.
I really appreciate your answer and patient, hope you have a wonderful thanksgiving!
It doesn't; that diagram is from the TZC-400 Technical Reference Manual as an example system using a TZC-400, not from the Juno documentation.
In practice on most systems you'll configure all filter units to have the same configuration, which is what happens on Juno. You can see here that each region is configured using PLAT_ARM_TZC_FILTERS, which equates to TZC_400_REGION_ATTR_FILTER_BIT_ALL, which in turn collapses to (0xF << 0), i.e. 4b1111. This mask is written to the filter_en field (bits [3:0]) of the corresponding region's REGION_ATTRIBUTES_<n> register. In other words, all configured regions are enabled for all 4 filter units.
Hope that helps.
You too
Ash
Oh I understand the part about connecting filters with regions. Sorry I don't make the question clear.
My question is how to configure the relationship between CPU/GPU/DMA/LCD with those filters. Is there any configuration like CPU needs to connect with filter 0 or DMA needs to connect with filter 3?
In what context?
If you mean something along the lines of "does the TZC-400 mandate that CPUs are connected to filter 0 while DMA engines are connected to filter 3", then no; the 4 filter units are identical in terms of functionality and system designers are free to wire them up however they want.