83da50173c
The current XHCI code only sets IOC on the last TRB of a TD, and doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this won't generate an event at all when we have a short transfer that is not on the last TRB of a TD, resulting in event ring desync and everyone having a bad time. However, just setting ISP on other TRBs doesn't really make for a nice solution: we then need to do ugly special casing to fish out the spurious second transfer event you get for short packets, and we still need a way to figure out how many bytes were transferred. Since the Short Packet transfer event only reports untransferred bytes for the current TRB, we would have to manually walk the rest of the unprocessed TRB chain and add up the bytes. Check out U-Boot and the Linux kernel to see how complicated this looks in practice. Now what if we had a way to just tell the HC "I want an event at exactly *this* point in the TD, I want it to have the right completion code for the whole TD, and to contain the exact number of bytes written"? Enter the Event Data TRB: this little gizmo really does pretty much exactly what any sane XHCI driver would want, and I have no idea why it isn't used more often. It solves both the short packet event generation and counting the transferred bytes without requiring any special magic in software. Change-Id: Idab412d61edf30655ec69c80066bfffd80290403 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170980 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit e512c8bcaa5b8e05cae3b9d04cd4947298de999d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6516 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> |
||
|---|---|---|
| .. | ||
| arch | ||
| bin | ||
| configs | ||
| crypto | ||
| curses | ||
| drivers | ||
| include | ||
| libc | ||
| libcbfs | ||
| liblzma | ||
| libpci | ||
| sample | ||
| tests | ||
| util | ||
| Config.in | ||
| Doxyfile | ||
| LICENSES | ||
| Makefile | ||
| Makefile.inc | ||
| README | ||
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.