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). CQ-DEPEND=CL:169170 BUG=chrome-os-partner:21969 TEST=Make sure Snow still boots from the USB 2.0 port. 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> |
||
|---|---|---|
| .. | ||
| arch | ||
| bin | ||
| configs | ||
| crypto | ||
| curses | ||
| drivers | ||
| include | ||
| libc | ||
| libcbfs | ||
| liblzma | ||
| libpci | ||
| sample | ||
| tests | ||
| util | ||
| Config.in | ||
| Doxyfile | ||
| LICENSES | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
-------------------------------------------------------------------------------
libpayload README
-------------------------------------------------------------------------------
libpayload is a minimal library to support standalone payloads
that can be booted with firmware like coreboot. It handles the setup
code, and provides common C library symbols such as malloc() and printf().
Note: This is _not_ a standard library for use with an operating system,
rather it's only useful for coreboot payload development!
See http://coreboot.org for details on coreboot.
Installation
------------
$ git clone http://review.coreboot.org/p/coreboot.git
$ cd coreboot/payloads/libpayload
$ make menuconfig
$ make
$ sudo make install (optional, will install into /opt per default)
As libpayload is for 32bit x86 systems only, you might have to install the
32bit libgcc version, otherwise your payloads will fail to compile.
On Debian systems you'd do 'apt-get install gcc-multilib' for example.
Usage
-----
Here's an example of a very simple payload (hello.c) and how to build it:
#include <libpayload.h>
int main(void)
{
printf("Hello, world!\n");
return 0;
}
Building the payload using the 'lpgcc' compiler wrapper:
$ lpgcc -o hello.elf hello.c
Please see the sample/ directory for details.
Website and Mailing List
------------------------
The main website is http://www.coreboot.org/Libpayload.
For additional information, patches, and discussions, please join the
coreboot mailing list at http://coreboot.org/Mailinglist, where most
libpayload developers are subscribed.
Copyright and License
---------------------
See LICENSES.