Bureaucrats, dave_user, Administrators
8,220
edits
Changes
no edit summary
{{Applies To Bora}}
{{Applies To BoraX}}
{{AppliesToBORA_TN}}
{{AppliesToBORA_Xpress_TN}}
{{InfoBoxBottom}}
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0]]
|Internal draft
|-
|1.0.0
|November 2015
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|2.2.0, 3.0.0]]
|First public release
|-
|}
[[AN-BELK-001:_Asymmetric_Multiprocessing_(AMP)_on_Bora_–_Linux_FreeRTOS|Traditional AMP]]<ref name="AN-BELK-001"></ref> configuration satisfies [[#REQ1|REQ1]] through [[#REQ4|REQ4]]. [[#REQ5|REQ5]] through [[#REQ8|REQ8]] are not satisfied instead. About integrity, for example, an application with ''root'' privileges could access memory regions that are supposed to be exclusively accessed by code executed in W1. This may lead to unpredictable behaviors and to potentially catastrophic consequences. This is where TrustZone technology comes to help: it establishes a sort of barrier between the two worlds and prevents W2 code from unauthorized accesses to certain regions of the processor's addressing space.
==TrustZone-based approach==
** a shared memory area, marked as non-trusted
These choices lead to the configuration depicted in the following figure. [[File:Bora-wp001 01.png|thumb|center#L2 cache usage|400px|DAVE Embedded Systems' TrustZone-enabled AMP solutionhere]].
===System memory partitioning===
# monitor code
#* initializes TrustZone subsystem
#* enables core #1 and AMP configurationboth cores, setting up all the data structure required by TrustZone
#* gives trusted code the control of the machine.
# FreeRTOS kernel is initialized and real-time tasks are started. <u>Under the control of the tasks running on top of the RTOS kernel</u>, the non-trusted (NT for short) code is started{{efn|This is done via a Secure Monitor Call (referred as SMC in the rest of the document) that is handled by the monitor.}}.
===Inter-world communication===
Even if it is technically possibly possible to implement a system where W1 and W2 are completely isolated, the majority of real applications need a communication mechanism between the two worlds{{efn|From a different point of view, this is a sort of break in the barrier between the two worlds. As such it poses non-trivial issues in term of integrity and timeliness in the Trust world. This matter will be covered in more detail in following sections.}}.
Several options are available to implement such a mechanism, each of which having different pros and cons. Exhaustive comparison of all of them is beyond the scope of this paper. Nevertheless some aspects will be briefly discussed and some useful links will be provided to study this notable subject in more depth.
<ref name="XAPP1078"> John McDougall, ''XAPP1078 (v1.0) Simple AMP Running Linux and Bare-Metal System on Both Zynq SoC Processors'', 14th February 2013</ref> and
<ref name="XAPP1079">John McDougall, ''XAPP1079 (v1.0.1) Simple AMP: Bare-Metal System Running on Both Cortex-A9 Processors'', 24th January 2014</ref>,
L2 cache - in contrast to L1 - is a shared resource in Zynq implementation. As such, in case both cores have to use it, specific techniques have to be implemented to handle it properly in dual-OS AMP configuration. The solution here described In principle the approach that has been adopted allows to flexibly enable and configure implement different strategies related to L2cache management. By carefully configuring MMU The actual configuration that has been used to conduct the tests described in [[#Characterization and performance tests|this section]] assigns the whole L2 cache initialization, is possible to use it in the W2 onlyworld, the final setup is described as depicted in the following picture.
<span id="L2 cache usage"></span>
[[File:Bora-wp001 01 v2-L2cache.png|thumb|center|400px|L2 cache usage]]
* Linux performance are not affected by this dual-OS solution when accessing it's private memory
* FreeRTOS determinism is granted, because is using only non-shared resources (excluding the SOC L3 bus)
* access to shared memory is uncached or only L1 cached (the latter forces SCU SMP mode usage).For sake of completeness, it is recalled that it is also possible to enable L2 cache in W1 too, without breaking [[#REQ5|REQ5]] , because ARM PL310 L2 cache controller support the TrustZone technology and does not allow the non-trusted OS (W2) to access trusted OS (W1) cached data. Enabling However, enabling L2 cache for W1, highly may improve its computational performance but also reduce , in general, reduces real time determinismas well. In case L2 cache unavailability on W1 side is unacceptable, on-chip memory (OCM) can come to help to mitigate this issue.
====Leveraging OCM====
The use of L1 and L2 is strictly related to performance of ARM cores. There's also another precious resource that can increase core performance without affecting determinism, which is the OCM.
In SOCs, usually OCM is placed very close usually tightly coupled to the ARM core and has , providing access performance performances that can be compared with are comparable to L2 cache. This allows to leverage it to compensate for the unavailability of L2 memory.
The most common scenario is to:
* restrict OCM access to W1 only (again, this can be done with TrustZone)
* move the most ''latency sensitive'' code{{efn|- usually vectors and ISRs}} - inside its memory ranges* prevent this memory range to be L1-cached (because this usually does not increase the performance so much and significantly but may waste precious L1 memory lines).
==Characterization and performance tests==
==Conclusions and future work==
===Future work===
==References==
{{reflist}}