GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
coreboot-kgpe-d16/payloads/libpayload/include/x86/arch/cache.h

46 lines
1.9 KiB
C
Raw Normal View History

libpayload: Have similar cache api on ARM and x86 So far this is used by the USB driver, and instead of having ifdefs all throughout that code, implement the same API on x86 and ARM. Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/56105 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/4320 Tested-by: build bot (Jenkins)
2013-05-21 21:43:09 +02:00
/*
*
* Copyright 2013 Google Inc.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. The name of the author may not be used to endorse or promote products
* derived from this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* cache.h: Cache maintenance API for x86
*/
#ifndef __ARCH_CACHE_H__
#define __ARCH_CACHE_H__
libpayload: Make EHCI driver cache-aware This patch makes the EHCI driver work on ARM platforms which usually do not support automatic cache snooping. It uses the new DMA memory mechanism (which needs to be correctly set up in the Coreboot mainboard code) to allocate all EHCI-internal communication structures in cache-coherent memory, and cleans/invalidates the externally supplied transfer buffers in Bulk and Control functions with explicit calls as necessary. Old-Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167339 (cherry picked from commit 322338934add36a5372ffe7d2a45e61a4fdd4a54) libpayload: ehci: Cache management is hard, let's go copying... It turns out that my previous commit to make the EHCI stack cache aware on ARM devices wasn't quite correct, and the problem is actually much trickier than I thought. After having some fun with more weird transfer problems that appear/disappear based on stack alignment, this is my current worst-case threat model that any cache managing implementation would need to handle correctly: Some upper layer calls ehci_bulk() with a transfer buffer on its stack. Due to stack alignment, it happens to start just at the top of a cache line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line. ehci_bulk() calls dcache_clean() and initializes the USB transfer. Between that point and the call to dcache_invalidate() at the end of ehci_bulk(), any access to the stack variables in that cache line (even a speculative prefetch) will refetch the line into the cache. Afterwards any other access to a random memory location that just happens to get aliased to the same cache line may evict it again, causing the processor to write out stale data to the transfer buffer and possibly overwrite data that has already been received over USB. In short, any dcache_clean/dcache_invalidate-based implementation that preserves correctness while allowing any arbitrary (non cache-aligned) memory location as a transfer buffer is presumed to be impossible. Instead, this patch causes all transfer data to be copied to/from a cache-coherent bounce buffer. It will still transfer directly if the supplied buffer is already cache-coherent, which can be used by callers to optimize their transfers (and is true by default on x86). Old-Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169231 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 702dc50f1d56fe206442079fa443437f4336daed) Squashed the initial commit and a follow up fix. Change-Id: Idf7e5aa855b4f0221f82fa380a76049f273e4c88 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6633 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-08-28 21:29:28 +02:00
/* NOOPs mirroring ARM's cache API, since x86 devices usually cache snoop */
libpayload: Have similar cache api on ARM and x86 So far this is used by the USB driver, and instead of having ifdefs all throughout that code, implement the same API on x86 and ARM. Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/56105 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/4320 Tested-by: build bot (Jenkins)
2013-05-21 21:43:09 +02:00
#define dmb()
#define dsb()
libpayload: Make EHCI driver cache-aware This patch makes the EHCI driver work on ARM platforms which usually do not support automatic cache snooping. It uses the new DMA memory mechanism (which needs to be correctly set up in the Coreboot mainboard code) to allocate all EHCI-internal communication structures in cache-coherent memory, and cleans/invalidates the externally supplied transfer buffers in Bulk and Control functions with explicit calls as necessary. Old-Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167339 (cherry picked from commit 322338934add36a5372ffe7d2a45e61a4fdd4a54) libpayload: ehci: Cache management is hard, let's go copying... It turns out that my previous commit to make the EHCI stack cache aware on ARM devices wasn't quite correct, and the problem is actually much trickier than I thought. After having some fun with more weird transfer problems that appear/disappear based on stack alignment, this is my current worst-case threat model that any cache managing implementation would need to handle correctly: Some upper layer calls ehci_bulk() with a transfer buffer on its stack. Due to stack alignment, it happens to start just at the top of a cache line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line. ehci_bulk() calls dcache_clean() and initializes the USB transfer. Between that point and the call to dcache_invalidate() at the end of ehci_bulk(), any access to the stack variables in that cache line (even a speculative prefetch) will refetch the line into the cache. Afterwards any other access to a random memory location that just happens to get aliased to the same cache line may evict it again, causing the processor to write out stale data to the transfer buffer and possibly overwrite data that has already been received over USB. In short, any dcache_clean/dcache_invalidate-based implementation that preserves correctness while allowing any arbitrary (non cache-aligned) memory location as a transfer buffer is presumed to be impossible. Instead, this patch causes all transfer data to be copied to/from a cache-coherent bounce buffer. It will still transfer directly if the supplied buffer is already cache-coherent, which can be used by callers to optimize their transfers (and is true by default on x86). Old-Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169231 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 702dc50f1d56fe206442079fa443437f4336daed) Squashed the initial commit and a follow up fix. Change-Id: Idf7e5aa855b4f0221f82fa380a76049f273e4c88 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6633 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2013-08-28 21:29:28 +02:00
#define dcache_clean_all()
#define dcache_clean_by_mva(addr, len)
#define dcache_invalidate_all()
#define dcache_invalidate_by_mva(addr, len)
libpayload: Have similar cache api on ARM and x86 So far this is used by the USB driver, and instead of having ifdefs all throughout that code, implement the same API on x86 and ARM. Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/56105 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/4320 Tested-by: build bot (Jenkins)
2013-05-21 21:43:09 +02:00
#define dcache_clean_invalidate_all()
#define dcache_clean_invalidate_by_mva(addr, len)
arm: Redesign, clarify and clean up cache related code This patch changes several cache-related pieces to be cleaner, faster or more correct. The largest point is removing the old arm_invalidate_caches() function and surrounding bootblock code to initialize SCTLR and replace it with an all-assembly function that takes care of cache and SCTLR initialization to bring the system to a known state. It runs without stack and before coreboot makes any write accesses to be as compatible as possible with whatever state the system was left in by preceeding code. This also finally fixes the dreaded icache bug that wasted hundreds of milliseconds during boot. Old-Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183890 (cherry picked from commit 07a35925dc957919bf88dfc90515971a36e81b97) nyan_big: apply cache-related changes from nyan This applies the same changes from 07a3592 that were applied to nyan. Old-Change-Id: Idcbe85436d7a2f65fcd751954012eb5f4bec0b6c Reviewed-on: https://chromium-review.googlesource.com/184551 Commit-Queue: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 4af27f02614da41c611aee2c6d175b1b948428ea) Squashed the followup patch for nyan_big into the original patch. Change-Id: Id14aef7846355ea2da496e55da227b635aca409e Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> (cherry picked from commit 4cbf25f8eca3a12bbfec5b015953c0fc2b69c877) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/6993 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-01-22 05:11:22 +01:00
#define cache_sync_instructions()
libpayload: Have similar cache api on ARM and x86 So far this is used by the USB driver, and instead of having ifdefs all throughout that code, implement the same API on x86 and ARM. Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/56105 Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: http://review.coreboot.org/4320 Tested-by: build bot (Jenkins)
2013-05-21 21:43:09 +02:00
#endif