Ensure the physical_bar parameter passed to xhci_init is not NULL, else
return NULL. This may occur when an XHCI controller is disabled and no resources are allocated for it.
BUG=b:284213001
Change-Id: I05c32612606793adcba3f4a5724092387a215d41
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75645
Reviewed-by: Jon Murphy <jpmurphy@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This fixes format string mismatch errors in the USB subsystem found by
the compiler's format string checker.
BUG=b:167517417
TEST=enabled all USB controllers on volteer and fixed resulting
compiler errors when USB_DEBUG is enabled.
Change-Id: I4dc70baefb3cd82fcc915cc2e7f68719cf6870cc
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45024
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This fixes a logic bug in how timeouts are reported back. In the
timeout case, the original code would return -1 instead of 0. All call
sites expect a return value of 0 as the timeout indicator.
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Change-Id: I81a888aa0a1544e55e6a680be8f3b7f6e0d87812
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41854
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Stefan thinks they don't add value.
Command used:
sed -i -e '/file is part of /d' $(git grep "file is part of " |egrep ":( */\*.*\*/\$|#|;#|-- | *\* )" | cut -d: -f1 |grep -v crossgcc |grep -v gcov | grep -v /elf.h |grep -v nvramtool)
The exceptions are for:
- crossgcc (patch file)
- gcov (imported from gcc)
- elf.h (imported from GNU's libc)
- nvramtool (more complicated header)
The removed lines are:
- fmt.Fprintln(f, "/* This file is part of the coreboot project. */")
-# This file is part of a set of unofficial pre-commit hooks available
-/* This file is part of coreboot */
-# This file is part of msrtool.
-/* This file is part of msrtool. */
- * This file is part of ncurses, designed to be appended after curses.h.in
-/* This file is part of pgtblgen. */
- * This file is part of the coreboot project.
- /* This file is part of the coreboot project. */
-# This file is part of the coreboot project.
-# This file is part of the coreboot project.
-## This file is part of the coreboot project.
--- This file is part of the coreboot project.
-/* This file is part of the coreboot project */
-/* This file is part of the coreboot project. */
-;## This file is part of the coreboot project.
-# This file is part of the coreboot project. It originated in the
- * This file is part of the coreinfo project.
-## This file is part of the coreinfo project.
- * This file is part of the depthcharge project.
-/* This file is part of the depthcharge project. */
-/* This file is part of the ectool project. */
- * This file is part of the GNU C Library.
- * This file is part of the libpayload project.
-## This file is part of the libpayload project.
-/* This file is part of the Linux kernel. */
-## This file is part of the superiotool project.
-/* This file is part of the superiotool project */
-/* This file is part of uio_usbdebug */
Change-Id: I82d872b3b337388c93d5f5bf704e9ee9e53ab3a9
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41194
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The latest Intel FSP advertises xHCI v1.2 chipset support, so update
libpayload to include that version. No critical changes were identified
in review of the xHCI v1.2 spec, and booting from USB works with the
included change as expected.
BUG=b:155315876
TEST=booting from multiple USB sticks/hubs with the latest Intel FSP
that advertises xHCI v1.2
Change-Id: I236fed9beef86ff5e1bf7962d882fdae5817a1ff
Signed-off-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41039
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
I rushed CB:40895 in to fix a bug only to introduce another. xhci_init()
no longer crashes, but it doesn't correctly initialize the XHCI
controller either, and unfortunately the error messages are all hidden
behind USB_DEBUG. This patch fixes the incorrect address calculation to
what it was before CB:39838.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I14293e2135108db30ba6fd2efea0573fe266fa37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40956
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
The QEMU XHCI driver does not implement the Port Change Detect bit
in the USBSTS register. As a result no devices are attached without
looking at each port individually.
Detect this as a quirk based on the QEMU XHCI controller PCI ID,
and apply it to the root hub quirk list so it can get used by the
generic hub driver to skip this check.
With this change an attached USB mass storage device is detected and
able to boot when supplied to qemu:
-drive if=none,id=usbmsc,format=raw,file=/tmp/disk.img
-device qemu-xhci,id-xhci
-device usb-storage,bus=xhci.0,drive=usbmsc
Change-Id: I6689cb1dbb24c93d45f5c5ef040b713925d07588
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39839
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
memcpy() is meant to be used on normal memory and often implemented with
architecture-specific optimizations to make that as performant as
possible. MMIO registers often have special access restrictions that may
be incompatible with whatever memcpy() does. For example, on arm64 it
uses the LDP (load pair) to load 16 bytes at a time, which makes 4-byte
MMIO registers unhappy.
This patch removes the caching of the XHCI capreg registers and changes
it back to a pointer. The CAP_GET() macro is still accessing a full
(non-bitfield) uint32_t at the end so this should still generate a
4-byte access (which was the goal of the original change in CB:39838).
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Id058c8813087a8e8cb85f570399e07fb8a597108
Reviewed-on: https://review.coreboot.org/c/coreboot/+/40895
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The QEMU XHCI controller does not support byte/word reads from the
capability register and it expects dword reads only.
In order to make this work move the access of the capability
register fields to use macros instead of a packed struct bitfield.
This issue was filed upstream:
https://bugs.launchpad.net/qemu/+bug/1693050
The original fix attempt in 2012 was not effective:
6ee021d410
With this change the controller is detected properly by the libpayload
USB drivers.
Change-Id: I048ed14921a4c9c0620c10b315b42476b6e5c512
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39838
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This patch is a raw application of
find payloads/ -type f | \
xargs sed -i -e 's/IS_ENABLED\s*(CONFIG_/CONFIG(/g'
Change-Id: I883b03b189f59b5d998a09a2596b0391a2d5cf33
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31775
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=none
TEST=compiled on grunt and made sure USB still works in depthcharge
Change-Id: I972f4604bb5ff3838cb15f323c5a579ad890ecf5
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27883
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Make it obvious that the command has failed.
BUG=b:76831439
TEST=Verified on grunt
Change-Id: Ifa0b2fb087f5f0a36ba017a774fc98b33ab035a4
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Reviewed-on: https://review.coreboot.org/27478
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
1. Make the xHCI driver to support xHCI controller v1.1
2. And a new function xhci_ring_doorbell(), it aims to
add a memory barrier before ringing the doorbell, to ensure
all TRB changes are written to memory.
BRANCH=none
BUG=chrome-os-partner:52684
TEST=boot from USB on Kevin rk3399 platform
Change-Id: Ife1070d1265476d0f5b88e2acf3299fc84af5832
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0c21e92
Original-Change-Id: I4e38e04dc3c7d32ee4bb424a473c70956a3c3ea9
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/346831
Original-Commit-Ready: Brian Norris <briannorris@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/15111
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Existing Intel xHCI controllers require a delay of 1 ms,
after setting the CMD_RESET bit in command register, before
accessing any HC registers. This allows the HC to complete
the reset operation and be ready for HC register access.
Without this delay, the subsequent HC register access,
may result in a system hang, very rarely.
Verified CherryView / Braswell platforms go through over
1000 warm reboot cycles (which was not possible without
this patch), without any xHCI reset hang in depthcharge.
BRANCH=None
BUG=None
TEST=Verified CherryView / Braswell platforms go through
over 1000 warm reboot cycles, without any xHCI reset hang
in depthcharge.
Change-Id: I8eff5115ca52738bdcf8bc65fbfb2a5f60a0abe1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3e7ea70df36e3bf35a6ee1297640900ee76bfdac
Original-Change-Id: Id681a19d0eedb0e2c29e259c5467bcde577e3460
Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/310022
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/12325
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The 1.1 revision of the XHCI specification added an extra 5 bits to the
Max Scratchpad Bufs field of HCSPARAMS2 that newer controllers make use
of. Not honoring these bits means we're not allocating as many
scratchpad buffers as the controller expects, which means it will
interpret some uninitialized values from the end of the pointer array as
scratchpad buffer pointers, which obviously doesn't end well. Let's fix
that.
BRANCH=none
BUG=chrome-os-partner:42279
TEST=Makes a USB-related memory corruption issue disappear.
Original-Change-Id: I7c907492339262bda31cdd2b5c0b588de7df8544
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/291681
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Iba1007bfebffe1f564f78bb875fff9ba0fe11a38
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11189
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will make the code work with the different styles
of Kconfig (emit unset bools vs don't emit unset bools)
Roughly, the patch does this, and a little bit of fixing up:
perl -pi -e 's,ifdef (CONFIG_LP_.+?)\b,if IS_ENABLED\($1\),g' `find . -name *.[ch]`
perl -pi -e 's,ifndef (CONFIG_LP_.+?)\b,if !IS_ENABLED\($1\),g' `find . -name *.[ch]`
Change-Id: Ib8a839b056a1f806a8597052e1b571ea3d18a79f
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10711
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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)
Make the XHCI driver compile on ARM again. The Panther Point
specific shutdown handler is certainly _not_ necessary there.
Change-Id: I470afd4d82d101902b119b3ead4381e2b36a94b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10091
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
If a TD is comprised of one or more Normal TRBs and terminated with an
Event Data TRB, then the transition to the Idle state (and associated
Stream state save) could occur after all the data for the TD has been
moved (e.g. after Transfer Event TRBs have been executed), but before the
Event Data TRB is executed. Under these conditions, the execution of the
Event Data TRB is necessary to complete the TD, otherwise it does not
occur until the next time the Stream is scheduled. This could lead to the
lock up.
The Evaluate Next TRB(ENT) flag provides a means of forcing the execution
of a terminating Event Data TRB. Setting ENT flag in last Normal TRB makes
the xHC to evaluate the Even Data TRB.
BUG=chrome-os-partner:29375
TEST=Verified kernel boot-up on storm from previously failing USB stick.
USB stick model: Sandisk Ultra USB 3.0 Pen Drive 32 GB
Strontium Jet USB 3.0 Pen Drive 32 GB
Change-Id: I092e2109c55c2274239c493cb67b47d730304ed2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7eefb3b2858c841165ae839d349d2a0be50fbcc8
Original-Change-Id: I4e123577ec5a5996d87d2fc52cb6cf5c571c9fae
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/220123
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/8736
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Fix pointer related casts since this can create a problem for 64-bit systems.
BUG=None
BRANCH=None
TEST=Compiled successfully for link, nyan using emerge-* libpayload
Original-Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Original-Reviewed-on: https://chromium-review.googlesource.com/199564
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 914b118a64b0691aeca463dff24252db9c24109e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I11f070ed5d3eddd8b9be30c428cb24c8439e617b
Reviewed-on: http://review.coreboot.org/7905
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
xHCI Spec says TD Size (5 bits) field shall be forced to 31,
if the number of packets to be scheduled is greater than 31.
BUG=chrome-os-partner:27837
BRANCH=rambi,nyan
TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks
works fine without any babble errors.
Original-Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Original-Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Original-Reviewed-on: https://chromium-review.googlesource.com/202330
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ae58b99370df3a86bf15d84b97db858a968b1dbd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9668b947f676c109fad9297e5efde91bf7f796fd
Reviewed-on: http://review.coreboot.org/7913
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
There were a few build warnings in the USB driver to clean
up before -Werror may be enabled.
Change-Id: I220cfcf0ee926912a184a91d3ced3ba61259130e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7921
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This patch combines a few minor fixes and refactoring to the various
host controller and root hub drivers to ensure they all do the right
thing on a call to usb_exit(). It puts a usb_detach_device(0) call
into detach_controller() so that the HCD doesn't need to remember to
tear down the root hub itself, and makes sure all root hubs properly
detach the subtree of devices connected to their ports first (as
generic_hub and by extension XHCI had already been doing).
It also fixes up some missing free() calls and replaces most 'ptr =
malloc(); if (!ptr) fatal()' idioms with the new x(z)alloc().
BUG=chromium:343415
TEST=Tested EHCI on Big and OHCI, EHCI, and XHCI on Snow. Could not test
UHCI (unless anyone volunteers to port coreboot to a ZGB? ;) ), but the
changes are really tame.
Original-Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193731
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 5791b546e5a21a360d0c65888a5b92d5f48f8178)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I00138f0aeceb12ed721f7368c7788c9b6bee227d
Reviewed-on: http://review.coreboot.org/7222
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
- Remove the call to clear_stall in xhci_reset_endpoint because we will
call clear_stall from the mass-storage driver.
- Remove the xhci_reset_endpoint call from xhci_bulk on STALL since we
will reset on the next transfer anyway.
- Remove the clear_halt parameter from xhci_bulk since it's now unused.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I852b87621861109e596ec24b78a8f036d796ff14
Reviewed-on: https://chromium-review.googlesource.com/192866
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e67e4f0545cbdc074328c83c7edccf9e712cd7be)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This patch fixes a bug in the XHCI stack that occurs when a multi-TRB TD
times out before the last TRB is processed. The driver will correctly
issue a Stop Endpoint command in that case, but the xHC will still
preserve the transfer state and just pick up right after that on the
next doorbell ring. It will then process the leftover TRBs from the old
TD the next time a transfer is issued. (cf. XHCI 4.6.9)
We fix this by changing the existing xhci_reset_endpoint() calls in
transfer functions to not only trigger on Halted (2) and Error (4), but
also on Stopped (3). That function will not actually issue a Reset
Endpoint command in this case, but it will nuke the whole transfer ring
and issue a Set TR Dequeue Pointer command, which is sufficient (though
slightly overkill) to solve our problem.
Change-Id: I3abbe30ff9d4911a8af1f792324e018d427019e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170833
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit f12424af0e29ac12963e8e5a7970fadcc0bb6cee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6787
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch updates the libpayload XHCI stack to run on ARM CPUs (tested
with the DWC3 controller on an Exynos5420). Firstly, it adds support for
64-byte Slot/Endpoint Context sizes. Since the existing context handling
code represented the whole device context as a C struct (whose size has
to be known at compile time), it was necessary to refactor the input and
device context structures to consist of pointers to the actual contexts
instead.
Secondly, it moves all data structures that the xHC accesses through DMA
to cache-coherent memory. With a similar rationale as in the ARM patches
for EHCI, using explicit cache maintenance functions to correctly handle
the actual transfer buffers in all cases is presumably impossible.
Instead this patch also chooses to create a DMA bounce buffer in the
XHCI stack where transfer buffers which are not already cache-coherent
will be copied to/from.
Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169453
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6643
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Updated the patch to support XHCI as well.
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
(cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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>
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Setting of `controller->reg_base` is of no use here, as it is never read
(in another function) later. Looks like this pattern originated from uhci.c
where it makes sense.
By removing the indirection through `reg_base` we also fix a possible
truncation to u32.
Change-Id: I5c99c5bf1f5b1d6c04bd84d87fd3e275fd7d0411
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6251
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Fix a possible null-pointer dereference (hopefully) before anyone runs
into this. Also don't switch ports to xHCI if initialization failed.
Change-Id: I5dbaeb435a98ead0b50d27fde13c9f1433ea3e81
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6245
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As the controller structure is never fully cleared, this one wasn't
initialized for non-pci controllers (but checked for non-null later).
Change-Id: I852671c5f55650bdb6cd97f4ec74b1f95ee894c7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6246
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Using void* for physical addresses leads to much casting and confuses
developers when to convert from physical to virtual addresses or
the other way around. When using plain integers for physical addresses
and pointers for virtual addresses things become much cleaner and we
won't ever end up dereferencing a physical address.
Change-Id: I24cd53b81c7863b6d14f0cbb4ce8937728b37c1c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6244
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Remove a redundant phys_to_virt() that sneaked in the initialization of
PCI xHCI controllers. The use of casts from void* to u32 (and vice versa)
prompts for things going wrong here. That will be addressed in a later
commit.
Change-Id: Ibc71ed6ee7016529c0e3a51559aaec07aaaba315
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6243
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
being a good citizen on the box, libpayload tries to return to EHCI
mode on shutdown, so a non-XHCI capable USB driver after it (eg. in
the OS) finds something to work with.
Change-Id: Id227d646e08a258b841c644263112f0815dd486c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
Reviewed-on: http://review.coreboot.org/4175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
On Intel's Panther Point the xHCI ports are shared with an EHCI
controller. Our xHCI driver switches them to xHCI, naturally. But
we forgot to switch them back on shutdown, which left them
unusable by a non-xHCI aware operating system.
Change-Id: I70ef08655a603b42ee939935d50cf77ea97878a3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3791
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Well, it turned out to be more as some gaps ;)
but we finally have xHCI running. It's well tested against a QM77 Ivy
Bridge board.
We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not
advertised and USB 3 devices will just work at HighSpeed.
There are still some bit fields in xhci_private.h, so this might need
little more work to run on ARM.
Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Previously printf()'s were used to show USB messages
which results in lots of USB information being shown
when it isn't needed. This will now use the usb_debug()
printing funtion that already exists in usb.h.
Change-Id: I2199814de3327417417eb2e26a660f4a5557cb9f
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/2044
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
uhci_reset() differs in semantics compared to the other HCI's reset()
implementations. uhci_reset() does some initialization work after a
controller reset. So move the initialization part to a new function,
uhci_reinit(), which get's exported through a new entry in hci_t:
hci_t.init().
Warning: This breaks code that relies on the current, special,
counterintuitive behaviour of uhci_reset(). If one wants a working host
controller after calling hci_t.reset(), he should call hci_t.init()
afterwards.
Change-Id: Ia7ce80865d12d11157645ce251f77f349f8e3c34
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1851
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When ohci_reset() was implemented, OHCI controllers stopped working
since the stub ohci_reset() is called at the end of ohci_init().
This is fixed by removing the call. To prevent further problems the call
to the xhci_reset() stub is removed, too.
Change-Id: If89825c8e6caf40f7f4fe078e8b2e90054a54ba2
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/1850
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The "debug" macro used internally in the libpayload USB subsystem was very
generically named and would leak into consumers of the library that included
usb.h directly or indirectly. This change turns that #define from a macro into
a static inline function to move away from the preprocessor, and also renames
it to usb_debug so it's less likely to collide with something unrelated.
Change-Id: I18717df111aa9671495f8a2a5bdb2c6311fa7acf
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/1738
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Tested-by: build bot (Jenkins)
Add controller type (UHCI, OHCI, EHCI or XHCI)
into usbdev_hc (hci_t) struct, so now we know
which type selected controller have. It needed
to access controller specific data, if access
usb tree outside of libpayload (e.g. in payload
intself)
Change-Id: I7df947bbb56a50d0d792ccd4d3a6b021ee95e2ea
Signed-off-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-on: http://review.coreboot.org/1145
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We have fatal(), which is just as good.
Coccinelle script:
@@
expression E;
@@
-usb_fatal(E)
+fatal(E)
Change-Id: Iabecbcc7d068cc0f82687bf51d89c2626642cd86
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/395
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Improve scanning for USB controllers.
Limitations:
- OHCI doesn't support interrupt transfers yet (ie. no keyboards)
- xHCI just does initialization and device attach/detach so far
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Acked-by: Peter Stuge <peter@stuge.se>
git-svn-id: svn://svn.coreboot.org/coreboot/trunk@5691 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1
Fred Reitberger