Extended the 32bit CPU counter to 64bit by adding a static
variable that takes into account CPU counter overflow.
The varibale is updated everythime the timer_raw_value
function is called so I assume that the function is called
often enought to not miss an overflow of the CPU counter.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio bring up board; works as expected
BRANCH=none
Change-Id: I98bcc56e600dcff0c6da7c140dd34faec5e00885
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 972b105f950d800fa44f27bce090f6b89a5a84b9
Original-Change-Id: Id67b14e9d9c2354bc417b6587b615d466690c9b7
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/247642
Original-Reviewed-by: Daniel Ehrenberg <dehrenberg@chromium.org>
Reviewed-on: http://review.coreboot.org/9672
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The address of the output buffer sent to the device should be
the bus address and not the virtual address.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA and bring up board;
USB works properly after this change
BRANCH=none
Change-Id: I5c9d199e17c3f4303095ad73f4980d32d04c6118
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 942c385c112c2a4e409da806548081d3e2f8f438
Original-Change-Id: I0c06196501a968a72cb3f2c7dd1027bb22cdaada
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/245387
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9455
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Total FIFO length is split into 512 byte blocks.
Allocate these blocks to GRXFSIZ and GNPTXFSZ evenly.
This method avoids hardcoding and makes the FIFO size value
work for dwc2 controllers that have a different FIFO ram size.
BUG=chrome-os-partner:32634
BRANCH=None
TEST=Boot kernel from USB
Change-Id: I78ce0fa4c4600fb56c991874a93bdd6674e648c2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5645a25e95f84359cd10fc9fcf56e1f73fd6ce87
Original-Change-Id: Ib50a08c193f7f65392810ca3528a97554f2c3999
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233119
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9454
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I33f312a939e600b8f4e50a092bb61c5d6bc6d741
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 39ffe53336a2a3b2baa067cdd3dccca5ae93f68e
Original-Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/211053
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9453
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
We have two drivers for a 100%-identical peripheral right now, mostly
because we couldn't come up with a good common name for it back when we
checked it in. That seems like a pretty silly reason in the long run.
Both Tegra and Rockchip SoCs contain UARTs that use the common 8250
register interface (at least for the very basic byte-per-byte transmit
and receive parts we care about), memory-mapped with a 32-bit register
stride. This patch combines them to a single 8250_mmio32 driver (which
also fixes a problem when booting Rockchip without serial enabled, since
that driver forgot to check for serial initialization when registering
its console drivers). The register accesses are done using readl/writel
(as Rockchip did before), since the registers are documented as 32-bit
length (with top 24 bits RAZ/WI), although the Tegra SoC doesn't enforce
APB accesses to have the full word length. Also fixed checkpatch stuff.
A day may come when we can also merge this driver into the (completely
different, with more complicated features and #ifdefs) 8250 driver for
x86 (which has MMIO support for 8-bit register stride only), both here
and in coreboot. But it is not this day. This day I just want to get rid
of a 99% identical file without expending too much effort.
BUG=None
TEST=Booted on Veyron_Pinky and Nyan_Blaze with and without serial
enabled, both worked fine (although Veyron has another kernel issue).
Change-Id: I85c004a75cc5aa7cb40098002d3e00a62c1c5f2d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e7959c19356d2922aa414866016540ad9ee2ffa8
Original-Change-Id: Ib84d00f52ff2c48398c75f77f6a245e658ffdeb9
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225102
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Don't attempt to scan the PCI bus if the bridge is disabled. When
the PCI bridge is not setup and enabled, it is possible for the
secondary bus register to contain the value zero (0). In this case
the usb_scan_pci_bus routine gets into an infinite recursive loop
which ends only when the heap or stack is exhausted. This patch
verifies that the PCI bridge is enabled by verifying that it is
enabled for either memory or I/O operations. When enabled, the
secondary bus is scanned.
BRANCH=none
BUG=None
TEST=Build and run on Samus
Change-Id: I6826dc1d73b7c24729de5ac7c4d3534922ca73c5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 63d04b47934761351b54c847a2692bdef81ce54f
Original-Change-Id: I855240c52fa3eba841e6754816ebbcb824abc4cd
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/236382
Original-Commit-Queue: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/8734
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
If EHCI controller has TT (Transaction Translator) support in
root-hub, then we need to keep control over this controller when
USB keyboard (low-speed device) is connected to root-hub port.
Need to add "CONFIG_LP_USB_EHCI_HOSTPC_ROOT_HUB_TT=y" to config file
(e.g. payloads/libpayload/configs/config.nyan_big) to support this
feature.
BUG=chrome-os-partner:32355
TEST=Tested on nyan_big platform.
Press ESC+REFRESH+POWER keys on internal keyboard to power up.
Press Left Arrow or Right Arrow on USB keyboard to switch between
"English" and "Default Locale" in coreboot UI. Or unplug and plug
in device and try again.
Root hub <- low-speed USB keyboard
Root hub <- full-speed hub <- low-speed USB keyboard
Root hub <- high-speed hub <- low-speed USB keyboard
Change-Id: Iaa2823f64c8769fc808ee7a316c378f18f004e63
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ad57fd673d6dc8814fe99a4ac420566bb17e77b
Original-Change-Id: Id86a289bc587653b85227c1d50f7a4f476f37983
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/220125
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8737
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
timer_raw_value must return the number of CPU ticks, and not
the time obtained by dividing the ticks by the CPU frequency.
The CPU counter is increased at every 2 CPU clocks
and therfore the number of ticks will be the counter value
multiplied by 2.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA; it works properly.
BRANCH=none
Change-Id: Iae62cb328e882f84822250bdf72146321ca9bbe0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7ab25ce7dcaffb453ee774d870963a56444d46af
Original-Change-Id: I74408950900463a2c054d5aebd3edb005a325adb
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/242393
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/8744
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add the basic build infrastructure and architectural support
required to build for targets using the MIPS architecture.
This will require the addition of cache maintenance.
BUG=chrome-os-partner:31438
TEST=tested on Pistachio FPGA with Depthcharge as payload;
successfully executed payload.
BRANCH=none
Change-Id: I75cfd0536860b6d84b53a567940fe6668d9b2cbb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 758c8cb9a6846e6ca32be409ec5f7a888ac9c888
Original-Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Original-Change-Id: I0b9af983bf5032335a519ce2510a0b3aca082edf
Original-Reviewed-on: https://chromium-review.googlesource.com/219740
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8741
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Chapter 3.1 "Periodic Frame List" of EHCI 1.0 specification says
"Frame List Link pointers always reference memory objects that are
32-byte aligned."
jwerner@chromium.org suggests setting it to be 64-byte aligned for
consistency with other EHCI queue structures.
BUG=chrome-os-partner:31993
TEST=Tested on nyan platform. Before adding patch, USB keyboard behind
an external hub is not working to switch between "Default Locale" and
"English" (after pressing ESC+REFRESH+POWER on embedded keyboard and
later Left/Right-Arrow key on USB keyboard).
Change-Id: Ie6259f2df20ae2618c2074e831fad087f227091d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 23fc02e6ba3b17be4eaf18810ec6fc0d9c0e0b9a
Original-Change-Id: If52ddc43ebd5d509c19f104928dced5bd09b1706
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/218403
Original-Reviewed-by: Tom Warren <twarren@nvidia.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8738
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Data toggle should be running like 0, 1, 0, 1, ...
In the failed case (where a low-speed USB keyboard or km232 device
is installed), data toggle will be running as 0, 1, 0, 1, ..., 1, 1.
Therefore causing Halted or Transaction Error bit to be set in qTD
Status field.
BUG=None
BRANCH=None
TEST=Tested on nyan_kitty platform, firmware-kitty-5771.61.B branch.
Attached USB keyboard or km232 device to root-hub port (same side as
SD card slot).
Made sure no transaction error after doing interrupt transfer.
Change-Id: I576f3c583dae4c279a6e0e8ffdfce5abe463277d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64b0428aaab869e20f6720669e953acf82ecb846
Original-Change-Id: Ic2c0f95cff2ae6e314967b0b82231a962255f1a7
Original-Signed-off-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/233857
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/8747
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some USB sticks seem to send a NAK at a place where they mustn't
by spec, leading to a controller side error condition.
To avoid it, wait a millisecond which is enough to get past the
NAK condition. That delay only happens on device discovery so it
won't affect boot time by more than 1ms per device.
BUG=chromium:414959
BRANCH=none
TEST=depthcharge recognizes a Lexar 16GB USB stick after applying
this change.
Change-Id: I0e385702a5259b16fda0a253fc121d8f66e6705c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 10bbfda8395af009e7f910cc503f50c2ad969ae8
Original-Change-Id: I6dd5ca34e9f3767003ccb0ca9daaf16116f4a2df
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/228791
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-on: http://review.coreboot.org/8735
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
EHCI driver accesses mmio space using regular struct pointers. In order to avoid
any CPU re-ordering, memory barrier is required in async_set_schedule,
especially for arm64. Without the memory barrier, there seems to be re-ordering
taking place which leads to USB errors with some flash drives as well as
transfer errors in netboot.
BUG=chrome-os-partner:31533
BRANCH=None
TEST=With the memory barrier introduced, netboot for ryu completes transfer
without any error and finishes within 6-7 seconds.
Change-Id: Ib6d29dc79fd5722c27284478e8da316929e86bff
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 561bdd746c4d4446ce0a6d21337d354625d85ddc
Original-Change-Id: Ic05d47422312a1cddbebe3180f4f159853604440
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/213917
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/8732
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The serial driver hangs in cases when FIFO has more than single word to be
processed. Easiest way to reproduce is to paste a string of greater than 4
characters in cli.
Clearing the RXSTALE interrupt without draining all the characters from FIFO
leads to the issue as the driver is dependent on msm_boot_uart_dm_read
function to reinitialize for next transfer.
Logically the driver is organized in such a manner that next transfer never
gets initiated till rx_data_read < total_rx_data. Clearing the RXSTALE without
consideration of total number of characters (or words) unprocessed makes the
msm_boot_uart_dm_read to return on the first if conditional. Thus the driver is
stuck forever.
A quick fix is to avoid clearing the stale interrupt. Reset is handled whenever
a new transfer is initialized in msm_boot_uart_dm_init_rx_transfer.
BUG=chrome-os-partner:29542
TEST=manual
-Paste a string greater than 4 characters in cli.
Original-Change-Id: I016afb01a77cd14764f0176f6bf144fb29796c2f
Original-Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/209512
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit 61528884ad2c0a8e146054bbfeb01a3bc73b9692)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I936af5daa52a25f62133bdf9fb44f0b68cf34e88
Reviewed-on: http://review.coreboot.org/8667
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
`di` points to a single item in xhci->dev[], which is malloc'd
collectively. Trying to free() leads to pain.
Change-Id: Ibd99eda905d43cbf2d2c111dfd0186ed6b119329
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/8515
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Test for devno != -1 before trying to access array[devno]
(which may be array[-1]).
Change-Id: Ia69cc7eba0335f02bb0efec003a320a3c0646acb
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/8509
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add support:
1)Support driver rktimer
2)Support driver rkserial
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Original-Change-Id: I2cccedf3b62883dd372842a7972e93f2ebbfb282
Original-Signed-off-by: huang lin <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/206184
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 387450d7c36b201bd177d46eb9f1d280fc043aab)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia6b7a8ee2439a6f2bf7577df822d3f4f3a1e441c
Reviewed-on: http://review.coreboot.org/8127
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
Original-Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202045
Original-Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 4499318fb9a4e663c504d7c41380ccf2aa89da29)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3e07d7568c20c0e570222971ff219de3a6d9b7cc
Reviewed-on: http://review.coreboot.org/8061
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Original-Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/201342
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 466a59967b13986099106f8b44924648c1e6e6cd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I113689191db70710e7a45ccd02d672f482343e35
Reviewed-on: http://review.coreboot.org/8004
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Original-Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198021
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 8f49f752ab8f84b7c5dc189238732360e8d2aae2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia150c974e5b66939de0b007cf7c1308c187f3289
Reviewed-on: http://review.coreboot.org/8002
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With commands typically shorter than the buffer they're
copied to, copy cmdlen bytes, cut off by the buffer limit.
Change-Id: Ia9d2663bd145eff4538084ac1ef8850cfbcea924
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/7977
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in chromium.org 1f880bca0 really
meant to check for 'if (console)'. Looks like the whole video console
driver is built extra robust to not fail no matter how screwed up the
console is, so let's add this missing check here as well. Also fixed up
a few other missing 'if (!console)' checks while I'm at it.
However, what payloads should really be doing is check the return value
of video_(console_)init() and not call the other video functions if that
failed. This also adapts video_console_init() to correctly pass through
the return value for that purpose (something that seems to have been
overlooked in the dd9e4e58 refactoring).
BUG=chrome-os-partner:28494
TEST=None. I don't know what Dave did to trigger this in the first
place, but it's pretty straight-forward.
Original-Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200688
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3f01d1dc0974774f0b3ba5fc4e069978f266f2fc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I98c1d8360539b457e6df07cbcf799acaf6c4631b
Reviewed-on: http://review.coreboot.org/7910
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
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>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Original-Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196323
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1f880bca06ed0a3f2c75abab399d32a2e51ed10e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6c67a9efb00d96fcd67f7bc1ab55a23e78fc479e
Reviewed-on: http://review.coreboot.org/7908
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Original-Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198101
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 960534a20e4334772c29355bb0d310b3f41b31ee)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I39909fc96e32c9a5d76651d91c2b5c16c89ace9e
Reviewed-on: http://review.coreboot.org/7904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Original-Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198100
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 88943d9715994a14c50e74170f2453cceca0983b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3097c223248c07c866a33d4ab8f3db1a7082a815
Reviewed-on: http://review.coreboot.org/7903
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We recently changed the USB stack to detach devices aggressively that we
don't intend to use. This alone is not really a problem, but it
exarcerbates the fact that our device detachment itself is not very
good. We destroy any local info about the device, but we don't properly
disable the offending port. The device keeps thinking that it's active,
and if we later try to reuse that device address for another device
things become confused.
The real fix would be to properly disable all ports that we don't intend
to use. Unfortunately, this isn't really possible in our current
device/hub polymorphism structure, and I don't want to hack a new
disable_port() callback into usbdev_t that really doesn't belong there.
We will only be able to fix this cleanly after we ported all root hubs
to the generic_hub interface.
Until then, an easy workaround is to just avoid reusing addresses as
long as possible. This is firmware, so the chance that we'll ever run
through 127 devices is really small in practice. Even if we ever fix the
underlying issue, it's probably a smart precaution to keep.
BRANCH=nyan,rambi
BUG=chrome-os-partner:28328
TEST=Boot from a hub that has an "unknown" device in an earlier port
than the stick you want to boot from, make sure you can still boot.
Original-Change-Id: I9b522dd8cbcd441e8c3b8781fcecd2effa0f23ee
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197420
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 28b48aa69b55a983226edf2ea616f33cd4b959e2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id4c5c92e75d6b5a7e8f0ee3e396c69c4efd13176
Reviewed-on: http://review.coreboot.org/7881
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Original-Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196384
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ab1ef0c07736fe1aa3e0baaf02d258731e6856c0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I78f5aedf6d0c3665924995cdab691ee0162de404
Reviewed-on: http://review.coreboot.org/7880
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If a payload decides not to use a USB device then the device can be
detached. This prevents the device from interfering with normal
operation on some platforms. Also, it aligns the behavior of
usb_generic_init with class-specific init functions such as
usb_msc_init, which will detach unsupported devices.
BUG=None
TEST=Manual on Squawks. Test recovery boot w/ USB 2.0 media, verify
that media boots and no babble error is encountered.
BRANCH=rambi
Change-Id: I8fb30951d273e4144cda214a30a2e86df90f2c1c
Original-Change-Id: Iee522344558749603defb2966e18765aa195dae2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/195401
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit f7778ace68c9bee8dfab2b263e5dd054fc50c3bb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7830
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This creates a new PL011 config variable which avoids the
infinite busy wait on serial_putchar() because the register
mapping is not compatible with current implementation.
BUG=None
BRANCH=none
TEST=printf() works on the PL011 based ARMv8 foundation model
Original-Change-Id: I9feda35a50a3488fc504d1561444161e0889deda
Original-Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/187020
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 85779a34a161c324cc8af995ada4393137275f20)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Conflicts:
payloads/libpayload/Config.in
payloads/libpayload/drivers/serial.c
Change-Id: I23c8b3728cd7d2d7692b3e86a679e061e88f7bb5
Reviewed-on: http://review.coreboot.org/7422
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These drivers are needed right away and never really fit into depthcharge's
driver model anyway.
CQ-DEPEND=CL:194064
BUG=None
TEST=Built and booted nyan, link, and peach_pit and verified that timer values
in cbmem were reasonable. Built for nyan_big, nyan_blaze and daisy.
BRANCH=None
Original-Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/194058
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit f30a410f0a248c93bc34f5868af1596bf8ce3cdd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I782d20f3cd63210a87c712643c7a53753f5ef301
Reviewed-on: http://review.coreboot.org/7225
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We've recently fixed a problem where an external hard drive would choke
due to one too many CLEAR_FEATURE(HALT) commands in the XHCI stack with
"libpayload: usb: xhci: Fix STALL endpoint handling". Clearing stall
conditions from within the transfer function is wrong in general... this
is really something that is host controller agnostic and should be left
to the higher-level driver to decide. The mass storage driver (the only
one that should really encounter stalls right now) already contains the
proper amount of clear_stall() calls... any more than that is redundant
and as we found out potentially dangerous.
This patch removes automatic clear stalls from UHCI and OHCI drivers as
well to make things consistent between host controllers.
BUG=chromium:192866
TEST=None. I could borrow the original hard drive from Shawn and compile
a Snow to only use the OHCI driver to reproduce/verify this, but alas, I
am lazy (and it's really not that important).
Original-Change-Id: Ie1e4d4d2d70fa4abf8b4dabd33b10d6d4012048a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193732
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit d46e183f3e7e0b0130becdefa6fd3ef8097df54b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie8f4ab3db8ec0d9a2d1e91c62967833e59c46700
Reviewed-on: http://review.coreboot.org/7223
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Original-Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/194057
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 26e18f680c93fc990a3d1057c164f19859634a9f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia2233e2bd821d8de8d2d57a9423aeb74be7efd93
Reviewed-on: http://review.coreboot.org/7224
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch adds the 10ms TRSTRCY delay between a reset and the following
Set Address command that is required by the USB 2.0 specification to the
EHCI root hub driver. The generic_hub driver that's used for XHCI and
external hubs already included this delay. This is such a glaring
violation of the spec that I'm really amazed how many USB 2.0 devices
we tested before seemed perfectly fine with responding to a Set Address
within 2 microframes of the reset...
It also increases the port reset hold delay by one millisecond to avoid
an ugly race condition on Tegra SoCs: they decided to time the 50ms
themselves instead of relying on the CPU to do it (fair enough), and to
automatically transition Port Reset to 0 and Port Enable to 1 after that
(bad idea). If the CPU's read-modify-write to clear Port Reset races
exactly with the host controller setting Port Enable, we may end up
clearing the bit again and going into the companion controller handoff
path later on. The added millisecond shouldn't cause any problems for
other host controllers and is not a big deal compared to other delays in
this code path.
BUG=chrome-os-partner:26749
TEST=Run several dozen reboot loops with The USB Stick of Death (TM) (a
blue Patriot XT 13fe:5200 with bcdDevice = 1.00), make sure it always
gets detected correctly.
Original-Change-Id: Idd3329ae6d7e5e1c07a84a5475549b3459836b31
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/189872
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 4deca38e9d79f6373f4418fcaf51a6945232c8b8)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I68a29bfd2e0f30409fbfc330b2575f0f9f61a79d
Reviewed-on: http://review.coreboot.org/7221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch enables the OHCI driver to use DMA memory, which is necessary
for ARM systems where DMA devices are not cache coherent. I really only
need this to test some later OHCI changes, but it was easy enough...
copied almost verbatim from ehci.c.
Change-Id: Ia717eef28340bd6182a6782e83bfdd0693cf0db1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193730
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit e46b6ebc439e86a00e13bf656d60cf6c186a3777)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7010
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- 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>
If a port is connected before and after an xhci controller reset, the
PORTSC CSC bit may not be asserted. Add an additional check in
xhci_rh_port_status_changed for the PRC bit so we can correctly handle
ports in such a state.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2d623aae647ab13711badd7211ab467afdc69548
Reviewed-on: https://chromium-review.googlesource.com/189394
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ee7c3ea182b35bb6ce3c62f301c4515714f6e654)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7002
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The generic roothub reset port function is overly broad and does some
things which may be undesirable, such as issuing multiple resets to a
port if the reset is deemed to have finished too quickly. Remove the
generic function and replace it with a controller-specific function,
currently only implemented for xhci.
Change-Id: Id46f73ea3341d4d01d2b517c6bf687402022d272
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189495
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 54e1da075b0106b0a1f736641fa52c39401d349d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7001
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Forgot an asterisk and everything goes to hell. Sorry about that.
Change-Id: I6b2503ca3ea0f80d4e4e5d8b8c0e986fec5db2c9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173587
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: David James <davidjames@chromium.org>
(cherry picked from commit 2a357560a697b56cc6022a4dd3dda47b33568d83)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The dump_td() debug function in the EHCI stack incorrectly masks the
amount of transferred bytes on output... the actual field is 15 bits
wide (30:16). Let's just use the mask constant we already have for all
the other code.
Change-Id: I28c6f0ec75cc613e38d53b670645d19bf9ffe1b9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174986
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 570077da7f16bbe2204b4a80790e4bd8fe1a2bd7)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch represents a major overhaul of the USB enumeration code in
order to make it cleaner and much more robust to weird or malicious
devices. The main improvement is that it correctly parses the USB
descriptors even if there are unknown descriptors interspersed within,
which is perfectly legal and in particular present on all SuperSpeed
devices (due to the SuperSpeed Endpoint Companion Descriptor).
In addition, it gets rid of the really whacky and special cased
get_descriptor() function, which would read every descriptor twice
whether it made sense or not. The new code makes the callers allocate
descriptor memory and only read stuff twice when it's really necessary
(i.e. the device and configuration descriptors).
Finally, it also moves some more responsibilities into the
controller-specific set_address() function in order to make sure things
are initialized at the same stage for all controllers. In the new model
it initializes the device entry (which zeroes the endpoint array), sets
up endpoint 0 (including MPS), sets the device address and finally
returns the whole usbdev_t structure with that address correctly set.
Note that this should make SuperSpeed devices work, but SuperSpeed hubs
are a wholly different story and would require a custom hub driver
(since the hub descriptor and port status formats are different for USB
3.0 ports, and the whole issue about the same hub showing up as two
different devices on two different ports might present additional
challenges). The stack currently just issues a warning and refuses to
initialize this part of the hub, which means that 3.0 devices connected
through a 3.0 hub may not work correctly.
Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170666
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6780
Tested-by: build bot (Jenkins)
Ionela Voinescu