d42ee150a0
1. There is a mis-understanding to calculate the value of TD Size in Normal TRB. For MTK's xHCI controller it defines a number of packets that remain to be transferred for a TD after processing all Max packets in all previous TRBs, that means don't include the current TRB's. 2. To minimize the scheduling effort for synchronous endpoints in xHC, the MTK architecture defines some extra SW scheduling parameters for HW. According to these parameters provided by SW, the xHC can easily decide whether a synchronous endpoint should be scheduled in a specific uFrame. The extra SW scheduling parameters are put into reserved DWs in Slot and Endpoint Context. But in coreboot synchronous transfer can be ignored, so only two fields are set to a default value 1 to support bulk and interrupt transfers, and others are set to zero. 3. For control transfer, it is better to read back doorbell register or add a memory barrier after ringing the doorbell to flush posted write. Otherwise the first command will be aborted on MTK's xHCI controller. 4. Before send commands to a port, the Port Power in PORTSC register should be set to 1 on MTK's xHCI so a hook function of enable_port in generic_hub_ops_t struct is provided. Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41 Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Original-Reviewed-on: https://chromium-review.googlesource.com/265362 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com> Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com> Reviewed-on: http://review.coreboot.org/10389 Reviewed-by: Patrick Georgi <pgeorgi@google.com> Tested-by: build bot (Jenkins) |
||
|---|---|---|
| .. | ||
| arch | ||
| bin | ||
| configs | ||
| crypto | ||
| curses | ||
| drivers | ||
| gdb | ||
| include | ||
| libc | ||
| libcbfs | ||
| liblzma | ||
| libpci | ||
| sample | ||
| tests | ||
| util | ||
| Config.in | ||
| Doxyfile | ||
| LICENSES | ||
| LICENSE_GPL | ||
| 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.