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: Id86a289bc587653b85227c1d50f7a4f476f37983
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/220125
Reviewed-by: Julius Werner <jwerner@chromium.org>
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: If52ddc43ebd5d509c19f104928dced5bd09b1706
Signed-off-by: Jim Lin <jilin@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/218403
Reviewed-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: Idad1ad165fd44df635a0cb13bfec6fada1378bc8
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/211053
Reviewed-by: Julius Werner <jwerner@chromium.org>
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: Ic05d47422312a1cddbebe3180f4f159853604440
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://chromium-review.googlesource.com/213917
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.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.
Change-Id: I016afb01a77cd14764f0176f6bf144fb29796c2f
Signed-off-by: Yogesh Lal <ylal@codeaurora.org>
Reviewed-on: https://chromium-review.googlesource.com/209512
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Add support board veyron:
1)Support driver rktimer
2)Support driver rkserial
3)Support config.veyron
BUG=chrome-os-partner:29778
TEST=emerge-veyron libpayload
Change-Id: I2cccedf3b62883dd372842a7972e93f2ebbfb282
Signed-off-by: huang lin <hl@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/206184
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Julius Werner <jwerner@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...
storm:
Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202045
Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
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.
Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Reviewed-on: https://chromium-review.googlesource.com/202330
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.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
Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/201342
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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.
Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198021
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Seems that the 'if (cursor_enabled)' check in
video_console_fixup_cursor() that was removed in commit 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.
Change-Id: I1b9f09d49dc70dacf20621b19e081c754d4814f7
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200688
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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.
Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196323
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
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
Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Reviewed-on: https://chromium-review.googlesource.com/199564
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198101
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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).
Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/198100
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
Change-Id: I9b522dd8cbcd441e8c3b8781fcecd2effa0f23ee
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/197420
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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.
Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/196384
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
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
Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194058
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@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
Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/194057
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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).
Change-Id: Ie1e4d4d2d70fa4abf8b4dabd33b10d6d4012048a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193732
Reviewed-by: Stefan Reinauer <reinauer@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.
Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193731
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
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.
BUG=chromium:343415
TEST=Works on Snow.
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>
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.
Change-Id: Idd3329ae6d7e5e1c07a84a5475549b3459836b31
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189872
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Jim Lin <jilin@nvidia.com>
Reviewed-by: Hung-Te Lin <hungte@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.
BUG=chrome-os-partner:26687
TEST=Manual on Rambi w/ USB_DEBUG enabled in libpayload. Boot with SanDisk
Extreme USB 3.0 drive in USB 3.0 port, verify that after STALL is
encountered reset succeeds and device is initialized without extra
delay.
BRANCH=Rambi
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>
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
Change-Id: I9feda35a50a3488fc504d1561444161e0889deda
Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/187020
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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.
BUG=chrome-os-partner:24090
TEST=Manual on Rambi:
- Boot Chromium OS from USB 3.0 drive
- Issue 'reboot' on command line
- Boot from USB 3.0 drive again successfully
Also --
- Boot Chromium OS from USB 3.0 drive
- Issue 'reboot' on command line
- Boot Chromium OS from eMMC
- Issue 'reboot' on command line
- Boot from USB 3.0 drive again successfully
Also, verify that USB ports continue to function correctly, and USB 3.0
device is always detected in Chromium OS as a superspeed device.
BRANCH=Rambi
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>
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.
BUG=chrome-os-partner:24090
TEST=Manual on Rambi. Verify that USB 3.0 media is found + bootable on
cold boot.
BRANCH=Rambi.
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>
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
You might want to use the serial hardware for something other than a console,
or you might want to intercede in the serial stream to wrap it in another
protocol. This is what you'd do to send output to GDB while using it to debug
the payload.
BUG=None
TEST=Built and booted on nyan and saw that there was serial output. Built for
pit.
BRANCH=None
Change-Id: I2218c0dbb988dacb64e5bdaf5d92138828eff8b6
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179559
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
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.
BUG=None
TEST=None
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>
Forgot an asterisk and everything goes to hell. Sorry about that.
BUG=chrome-os-partner:23396
TEST=Make sure keyboards work in depthcharge.
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>
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.
BUG=chrome-os-partner:22139
TEST=Manual
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>
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.
BUG=chrome-os-partner:21969
TEST=Manual
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>
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.
BUG=chrome-os-partner:21969
TEST=Manual
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>
This patch fixes the following minor bugs in the USB stack:
1. Ensure that all dynamically allocated device structures are cleaned
on detachment, and that the device address is correctly released again.
2. Make sure MSC and HID drivers notice missing endpoints and actually
detach the device in that case (to prevent it from being used).
3. Make sure XHCI-specific set_address() cleans up all data structures
on failure.
4. Fix broken Slot ID range check that prevented XHCI devices from being
correctly cleaned up.
BUG=chrome-os-partner:22139
TEST=Manual
Change-Id: I7b2b9c8cd6c5e93cb19abcf01425bcd85d2e1f22
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170665
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
This patch removes the confusing concept of a special "xhci_speed" with
a different numeric value from the usual speed used throughout the USB
core (except for the places directly interacting with the xHC, which are
explicitly marked). It also moves the MPS0 decoding function into the
core and moves some definitions around in preparation of later changes
that will make the stack SuperSpeed-ready. It makes both set_address
implementations share a constant for the specification-defined
SetAddress() recovery delay and removes pointless additional delays from
the non-XHCI version.
BUG=chrome-os-partner:22139
TEST=Manual
Change-Id: I422379d05d4a502b12dae183504e5231add5466a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170664
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
While the 8250 compatible serial port driver is primarily useful on x86
systems because it works with the legacy x86 com ports, some devices which
aren't x86 based have 8250 compatible UARTs as well. This change renames the
CONFIG_X86_SERIAL_CONSOLE option to the more general and direct
CONFIG_8250_SERIAL_CONSOLE and fixes up the dependencies so that non-x86
systems can enable the driver, although it will default to on on x86 and off
otherwise.
Also, the default IO port address that's added to the sysinfo structure on x86
and which is intended to be overwritten by a value in the coreboot tables is
not used on ARM. That variable is adjusted so that it's more clear it's a
default value, and made dependent on x86 since that's the only place its value
is actually used.
BUG=None
TEST=With this and other changes, built for an ARM board which has an ns16550
(and essentially 8250) compatible UART. Built for pit and for link.
BRANCH=None
Change-Id: Ifeaade0e7bd76d382426e947275a9c933da4930e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/170834
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
The USB MSC device structure contains a "ready" state that can be either
"ready", "not ready" or "detached". The last one can only be assigned
when the device is completely unresponsive and gets forcefully logically
detached via usb_detach_device(). This call (at least in the current
version) also calls all destructors and frees the complete usbdev_t
structure (including the MSC specific part), which unfortunately makes
storing the "detached" state in that very structure a little pointless.
This patch reduces the "ready" value to a simple boolean and makes sure
that all detachment cases immediately return from the MSC driver,
carefully avoiding any use-after-free opportunities.
BUG=None
TEST=Unplug a USB stick from a Pit/Kirby in depthcharge and make sure
the machine doesn't crash.
Change-Id: Iff1c0849f9ce7c95d399bb9a1a0a94469951194d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170667
The readwrite_chunk was private to the usb mass storage driver, but wasn't
marked as static which was upsetting the compiler.
BUG=None
TEST=Built for kirby, snow and pit.
BRANCH=None
Change-Id: I0ef5c5f96a29f793dd43ff672a939902bad13c45
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169816
Reviewed-by: Julius Werner <jwerner@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Currently, we wait for up to 30 seconds for a device to become ready to
respond to a TEST_UNIT_READY command. In practice, all media devices become
ready much sooner. But, certain devices do not function with libpayload's
USB driver, and always timeout. To provide a better user experience when
booting with such devices, reduce the timeout to 5 seconds.
BUG=chrome-os-partner:22345
TEST=Manual on Peppy w/ FCR-HS3 SD card reader. Verify that timeout is
reduced to ~5 seconds. Also verify that various external media devices
continue to boot.
Change-Id: Icceab99fa266cdf441847627087eaa5de9b88ecc
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169209
When bringing up media, we claim to wait for up to 30 seconds for a
device to respond to our TEST_UNIT_READY command. Actually, we can wait
far longer because we do not take into account execution delay.
To improve timeout accuracy, make use of gettimeofday(), which calculates
time based upon a CPU counter. This improves the user experience
slightly when certain non-working USB devices are used.
BUG=chrome-os-partner:22345
TEST=Manual on Peppy w/ FCR-HS3 SD card reader. Verify that command
timeout occurs in ~30 seconds, rather than ~10,000 seconds.
Change-Id: Id9605ecfc0a522d7a0b039fd8eac541232605082
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169208
Reviewed-by: Julius Werner <jwerner@chromium.org>
The existing USB_MEMORY mechanism to instantiate non-PCI host
controllers is clunky and inflexible... most importantly, it doesn't
allow multiple host controllers of the same kind. This patch replaces it
with a function that allows payloads to directly instantiate as many
host controllers of whatever type they need.
CQ-DEPEND=CL:169541
BUG=chrome-os-partner:21969
TEST=Manual
Change-Id: Ic21d2016a4ef92c67fa420bdc0f0d8a6508b69e5
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169454
Reviewed-by: Stefan Reinauer <reinauer@google.com>
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.
BUG=chrome-os-partner:21969
TEST=Snow/Pit/Kirby correctly boot from XHCI ports.
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>
The current USB hub code always clears the port status change after
checking it, regardless of whether it was set in the first place. Since
this check runs on every poll, it might create a race condition where
the port status changes right between the GET_PORT_STATUS and the
CLEAR_FEATURE(C_PORT_CONNECT), thus clearing the statrus change flag
before it was ever read. Let's add one extra if() to avoid that possible
headache.
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Idd46c2199dc6c240bd9ef068fbe70cccc88bac42
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168098
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.
Original-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>
(cherry picked from commit 9029265cf5)
Cherry-picked from upstream/master, resolved conflicts with 95b7b79c3
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I413283bea0b2482b284d03bbab750ffc88ea6acf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168097
This is mostly a rewrite, don't even try to read a diff.
Tested with an internal rate matching hub on a QM77 board and three hubs
integrated into DELL monitors.
Original-Change-Id: Ib12fa2aa90af4e0f37143d2ed92c4a1705b6d774
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3451
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 5736fab4be)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Idec16258a5b7286de48b5d3974eeefcab45a7e50
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168096
The current drivers for external usb hubs and root hubs all follow
the same pattern. Before adding another one with 90% of the same code,
extract the common parts and rewrite them with a simple interface.
This also adds debouncing of new attachments. Current drivers just
waited 100ms before they reset the device. However, we should check
if the device becomes disconnected and reconnected during this period.
Porting of the current hub drivers will take place in separate
commits (when I have time to test the older HCIs).
Original-Change-Id: I0c0ce0ac1b1cc51fb4cd009b3f9fcd1b9d2ba8fe
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3450
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit 0b78de2ee9)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: I97b97c310a59b400cff8c9c245b5b24cfec3a109
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168095
Read bInterval from endpoint descriptors and store it in our endpoint_t
struct. The interval is encoded dependently on the device' speed and the
endpoint's type. Therefore, it will be normalized to the binary logarithm
of the number of microframes, i.e.
t = 125us * 2^interval
The interval attribute will be used in the xHCI driver.
Original-Change-Id: I65a8eda6145faf34666800789f0292e640a8141b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3449
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry picked from commit aee44fa37d)
BUG=chrome-os-partner:21969
TEST=None
Change-Id: Ic42ad3c193390d5838b563346604b1ef9f385b52
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/168094
