Instead of cleaning the data cache to the PoU by virtual address and
subsequently invalidating the entire I-cache, invalidate only the
range that we just cleaned. This way, we don't invalidate other
cachelines unnecessarily.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
This patch updates the ArmPkg variant of InvalidateInstructionCacheRange to
flush the data cache only to the point of unification (PoU). This improves
performance and also allows invalidation in scenarios where it would be
inappropriate to flush to the point of coherency (like when executing code
from L2 configured as cache-as-ram).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Added AARCH64 and ARM/GCC implementations of the above.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19174 6f19259b-4bc3-4df7-8a09-765794883524
In SVN 18756 ("disallow whole D-cache maintenance operations")
InvalidateInstructionCache was modified to remove the full data cache
clean but left the full instruction cache invalidate. The change was
made to address issues in the set/way clean methodology but the
resulting code could lead someone to a painful debug. If a component
called this function, the proper code would not be flushed to the PoU,
since the intent of this function is not only to invalidate the I-cache
but to provide coherency after code loading / modification. This change
simply places an ASSERT(FALSE) in this function to avoid this hazard.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19084 6f19259b-4bc3-4df7-8a09-765794883524
The ARM architecture provides no reliable way to clean or invalidate
the entire data cache at runtime. The reason is that such maintenance
requires the use of set/way maintenance operations, which are suitable
only for the kind of maintenance that is carried out when the cache is
taken offline entirely.
So ASSERT () when any of the CacheMaintenanceLib whole data cache routines
are invoked rather than pretending we can do anything meaningful here.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18756 6f19259b-4bc3-4df7-8a09-765794883524
There is no need to issue a full data synchronization barrier and an
instruction synchronization barrier after each and every set/way or
MVA cache maintenance operation. For the set/way case, we can simply
remove them, since the set/way outer loop already issues the required
barriers after completing its traversal over all the cache levels.
For the MVA case, move the data synchronization barrier out of the
loop, and add the instruction synchronization barrier to the I-cache
invalidation by MVA routine.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18755 6f19259b-4bc3-4df7-8a09-765794883524
This removes the range size threshold for virtual address based cache
maintenance instructions that operate on VA ranges to be 'promoted' to
use set/way instructions.
Doing so is unsafe: set/way operations are fundamentally different
from VA operations, and really only suitable for cleaning or invalidating
a cache when turning it on or off.
To quote the ARM ARM (DDI0487A_d G3.4):
"""
Since the set/way instructions are performed only locally, there is no
guarantee of the atomicity of cache maintenance between different PEs,
even if those different PEs are each performing the same cache maintenance
instructions at the same time. Since any cacheable line can be allocated
into the cache at any time, it is possible for [a] cache line to migrate
from an entry in the cache of one PE to the cache of a different PE in a
manner that the cache line avoids being affected by set/way based cache
maintenance. Therefore, ARM strongly discourages the use of set/way
instructions to manage coherency in coherent systems.
"""
Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Olivier Martin <Olivier.Martin@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17176 6f19259b-4bc3-4df7-8a09-765794883524
Cache maintenance operations by Set/Way require that the Write Buffer
be drained before the cache is flushed. Without that, the flush can
miss the most recent values written as they are still "pipelined".
That has unfortunate consequences, especially where code is being
copied to RAM.
The fix is to add DSB instructions before the affected operations.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15551 6f19259b-4bc3-4df7-8a09-765794883524
This patch adds support to invalidate Instruction Cache to the Point of Unification (PoU).
Signed-off-by: eugenecohen
Reviewed-by: oliviermartin
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13012 6f19259b-4bc3-4df7-8a09-765794883524
ArmPkg - Supoprt for ARM specific things that can change as the architecture changes. Plus semihosting JTAG drivers.
EmbeddedPkg - Generic support for an embeddded platform. Including a light weight command line shell.
BeagleBoardPkg - Platform specifics for BeagleBoard. SD Card works, but USB has issues. Looks like a bug in the open source USB stack (Our internal stack works fine).
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@9518 6f19259b-4bc3-4df7-8a09-765794883524
Michael D Kinney
Ard Biesheuvel
Eugene Cohen
Ronald Cron
Olivier Martin
oliviermartin
hhtian
AJFISH