summaryrefslogtreecommitdiff
path: root/payloads/libpayload/libc/malloc.c
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2013-08-28 12:29:28 -0700
committerIsaac Christensen <isaac.christensen@se-eng.com>2014-08-14 23:40:25 +0200
commit509c37e7507c6d68019abb096df0374858f541f5 (patch)
tree3c198ba3c5f9d2bb841bfd0ffbdaff7b0c93d658 /payloads/libpayload/libc/malloc.c
parente8eb86f570723cc6becf7712b815c41e305bee5a (diff)
downloadcoreboot-509c37e7507c6d68019abb096df0374858f541f5.tar.xz
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>
Diffstat (limited to 'payloads/libpayload/libc/malloc.c')
-rw-r--r--payloads/libpayload/libc/malloc.c17
1 files changed, 14 insertions, 3 deletions
diff --git a/payloads/libpayload/libc/malloc.c b/payloads/libpayload/libc/malloc.c
index 618d8b3b93..11dfeefadd 100644
--- a/payloads/libpayload/libc/malloc.c
+++ b/payloads/libpayload/libc/malloc.c
@@ -83,7 +83,7 @@ static int minimal_free = 0;
void init_dma_memory(void *start, u32 size)
{
#ifdef CONFIG_LP_DEBUG_MALLOC
- if (dma != heap) {
+ if (dma_initialized()) {
printf("WARNING: %s called twice!\n");
return;
}
@@ -97,6 +97,17 @@ void init_dma_memory(void *start, u32 size)
dma->align_regions = NULL;
}
+int dma_initialized()
+{
+ return dma != heap;
+}
+
+/* For boards that don't initialize DMA we assume all locations are coherent */
+int dma_coherent(void *ptr)
+{
+ return !dma_initialized() || (dma->start <= ptr && dma->end > ptr);
+}
+
static void setup(hdrtype_t volatile *start, int size)
{
*start = FREE_BLOCK(size);
@@ -120,7 +131,7 @@ static void *alloc(int len, struct memory_type *type)
/* Make sure the region is setup correctly. */
if (!HAS_MAGIC(*ptr))
- setup(ptr, (int)((&_eheap - &_heap) - HDRSIZE));
+ setup(ptr, (int)((type->end - type->start) - HDRSIZE));
/* Find some free space. */
do {
@@ -470,6 +481,6 @@ void print_malloc_map(void)
if (free_memory && (minimal_free > free_memory))
minimal_free = free_memory;
printf("Maximum memory consumption: %d bytes\n",
- (unsigned int)(&_eheap - &_heap) - HDRSIZE - minimal_free);
+ (unsigned int)(heap->end - heap->start) - HDRSIZE - minimal_free);
}
#endif