Changes

Jump to: navigation, search
L2 cache management
===L2 cache management===
 
As specified by [[#REQ8|REQ8]], L2 cache must be able to be enabled (at least) on W2 side. As stated in
<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 allows to flexibly enable and configure L2.
The solution here described allows to flexibly enable By carefully configuring MMU and configure L2. cache initialization, is possible to use it in W2 only, the final setup is described in the following picture
[[File:Bora-wp001 01 v2-L2cache.png|thumb|center|400px|L2 cache usage]]
In this way:
* 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, 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 L2 cache for W1, highly improve its computational performance but also reduce real time determinism.
TBD
ripartizione L2 tra W1 e W2
utilizzo OCM???
====Leveraging OCM====
 The use of L1 and L2 is strictly related to performance of ARM cores. Th euse of onThere'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 to the ARM core and has access performance that can be compared with L2 cache. 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 waste precious L1 memory lines)
==Characterization and performance tests==
747
edits

Navigation menu