| Age | Commit message (Collapse) | Author |
|---|
|
This patch adds another cache invalidation stub to the x86 arch to
make it usable in common code. This whole stuff should probably be
redesigned anyway but I just want to get it working and unblock my CL
for now... more cleanups coming later.
Change-Id: I2e8bdd8aa0e6723209384c24042f053f2e993fe6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182534
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit cafce5182a7a2a9ce17ad40d9d893a40ebd5aafd)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6919
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
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>
|
|
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)
|
|
Change-Id: I3c4b8a9eeb6c4b2bcc58ccff091b4c997b2da923
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/4034
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3058
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
There were a number of type issues in libpayload that sneaked in
with 903f8e0.
- size_t and ssize_t were conflicting with gcc builtins
- some stdint types were used in libpayload but not defined
in our stdint.h
With this patch it's possible to compile libpayload with the
reference toolchain again.
Change-Id: Idd5ccfdd9f3536b36bceca2d101e7405883b10bc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2903
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some new TPM drivers in depthcharge require that type. I added it to
arch/types.h which seemed appropriate, but I'm not sure that's exactly the
right header to use, or in other words if you'd get that type from libpayload
the same way you'd get it if you were building a standard Linux program.
Also, I attempted to determine what underlying types gcc would use, and while
I think I picked the right ones I'm not 100% certain of that either.
Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2669
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Change-Id: Ia9170bd3d04e76dbf9321ca7ea4be23b5e468d21
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2033
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
