summaryrefslogtreecommitdiff
path: root/payloads/libpayload/drivers
AgeCommit message (Collapse)Author
2015-02-23libpayload: Improve sanity checking in UHCI driverPatrick Georgi
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>
2015-02-23libpayload: avoid use-after-free in OHCI driverPatrick Georgi
Change-Id: I89294c22c57564262e53e36c5ae9ac6eb0ed934a Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Found-by: Coverity Scan Reviewed-on: http://review.coreboot.org/8510 Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2015-01-12libpayload: Add Rock Chip drivershuang lin
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>
2015-01-09libpayload: Fix baseaddr access in serial/tegra.cFurquan Shaikh
Fix baseaddr typecast to allow use in 32- and 64-bit systems BUG=None BRANCH=None TEST=Compiles successfully for rush Original-Change-Id: Ie5ded744d75a0ae4d1428d04ff2478bdfe54d146 Original-Signed-off-by: Furquan Shaikh <furquan@google.com> Original-Reviewed-on: https://chromium-review.googlesource.com/204424 Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org> Original-Tested-by: Furquan Shaikh <furquan@chromium.org> (cherry picked from commit b56814fe5fc7d3a2fdfb324d4baafb27a9d3ffd6) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: Icedc1c819e39b92a0dd92e98f848e15b3039dfbe Reviewed-on: http://review.coreboot.org/8123 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2015-01-06libpayload: ipq808x: introduce uart driverVadim Bendebury
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>
2015-01-04ipq8064: Add work around for slow timer clockVadim Bendebury
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)
2015-01-04libpayload: ipq8064: Add rudimentary timer driverVadim Bendebury
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>
2015-01-03libpayload: don't test for unsigned >= 0Patrick Georgi
Change-Id: Ibeaf6de9505bc6f1e7358a4cfc80228dff7ddb69 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Found-by: Coverity Scan Reviewed-on: http://review.coreboot.org/7978 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2015-01-03libpayload: avoid memory overflowsPatrick Georgi
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>
2014-12-31libpayload: Fix pointer related castsFurquan Shaikh
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)
2014-12-31libpayload: usb: xhci: Fix TD size if it overflows 5 bitsRajmohan Mani
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>
2014-12-30libpayload: video: Check for 'console' pointer before dereferencing itJulius Werner
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)
2014-12-30libpayload: Clean up USB build warningsMarc Jones
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>
2014-12-30libpayload: video: Make cursor fixup independent of visibilityJulius Werner
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>
2014-12-30libpayload: usbmsc: Implement limited LUN supportJulius Werner
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>
2014-12-30libpayload: usbmsc: Set correct allocation length for REQUEST SENSEJulius Werner
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>
2014-12-22libpayload: usb: Try to avoid reusing device addressesJulius Werner
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>
2014-12-22libpayload: console: Allow output drivers to print whole strings at onceJulius Werner
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>
2014-12-17libpayload: usb: Detach unused USB devicesShawn Nematbakhsh
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>
2014-11-13libpayload: Add minimal support for PL011 UARTMarcelo Povoa
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>
2014-11-13libpayload: timer: Move the timer drivers from depthcharge to libpayload.Gabe Black
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)
2014-11-13libpayload: usb: Remove automatic clear_stall() calls from transfersJulius Werner
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>
2014-11-13libpayload: usb: Fix up usb_shutdown() code pathsJulius Werner
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>
2014-11-09libpayload: serial: Move the depthcharge serial drivers into libpayload.Gabe Black
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)
2014-10-29libpayload: usb: ehci: Honor 10ms reset recovery periodJulius Werner
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>
2014-10-22libpayload: usb: Make OHCI work with ARM systemsJulius Werner
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>
2014-10-22libpayload: usb: xhci: Fix STALL endpoint handlingShawn Nematbakhsh
- 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>
2014-10-17libpayload: Fix missed CONFIG_ -> CONFIG_LP_ substitutionsNico Huber
Change-Id: I1c64a9a649398ebe2eda179907c470f99caa9fc3 Signed-off-by: Nico Huber <nico.h@gmx.de> Reviewed-on: http://review.coreboot.org/7056 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-10-02libpayload: usb: xhci: Treat port reset as a port status changeShawn Nematbakhsh
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>
2014-10-02libpayload: usb: Remove generic roothub reset port functionShawn Nematbakhsh
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>
2014-09-10libpayload: usbhid: Fix typo on descriptor parsingJulius Werner
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>
2014-09-10libpayload: ehci: Fix byte count in dump_td()Julius Werner
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>
2014-09-04libpayload: usb: Refactor USB enumeration to fix SuperSpeed devicesJulius Werner
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)
2014-09-04libpayload: usb: Unify USB speed between XHCI stack and USB coreJulius Werner
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. 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> (cherry picked from commit f160d4439c0d7cea1d2e6b97207935d61dcbb2f2) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6776 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-31libpayload: xhci: Ensure to reset dequeue pointer on stopped endpointsJulius Werner
This patch fixes a bug in the XHCI stack that occurs when a multi-TRB TD times out before the last TRB is processed. The driver will correctly issue a Stop Endpoint command in that case, but the xHC will still preserve the transfer state and just pick up right after that on the next doorbell ring. It will then process the leftover TRBs from the old TD the next time a transfer is issued. (cf. XHCI 4.6.9) We fix this by changing the existing xhci_reset_endpoint() calls in transfer functions to not only trigger on Halted (2) and Error (4), but also on Stopped (3). That function will not actually issue a Reset Endpoint command in this case, but it will nuke the whole transfer ring and issue a Set TR Dequeue Pointer command, which is sufficient (though slightly overkill) to solve our problem. Change-Id: I3abbe30ff9d4911a8af1f792324e018d427019e8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170833 Reviewed-by: Ronald Minnich <rminnich@chromium.org> Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit f12424af0e29ac12963e8e5a7970fadcc0bb6cee) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6787 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-08-28libpayload: Change CONFIG_X86_SERIAL_CONSOLE to CONFIG_8250_SERIAL_CONSOLEGabe Black
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. 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> (cherry picked from commit 9a10e39a2da3cb0bfb316c0869cf5025078e287f) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6655 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-08-28libpayload: usb: Allow direct instantiation of MMIO host controllersJulius Werner
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. 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> (cherry picked from commit b6e95c39dd91f654f0a345f17b3196f56adf4891) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6644 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-19libpayload: usb: Fix several minor USB stack bugsJulius Werner
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. 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> (cherry picked from commit 9671472263ddd0c30400ae3b6da780a18cd21ded) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6701 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-18libpayload: usbmsc: Remove DETACHED state from MSC device structureJulius Werner
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. Change-Id: Iff1c0849f9ce7c95d399bb9a1a0a94469951194d Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170667 (cherry picked from commit fd4529f37fdd1c93a8b902488ffeef7001b1a05a) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6654 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-08-14libpayload: xhci: Make XHCI stack usable on ARMJulius Werner
This patch updates the libpayload XHCI stack to run on ARM CPUs (tested with the DWC3 controller on an Exynos5420). Firstly, it adds support for 64-byte Slot/Endpoint Context sizes. Since the existing context handling code represented the whole device context as a C struct (whose size has to be known at compile time), it was necessary to refactor the input and device context structures to consist of pointers to the actual contexts instead. Secondly, it moves all data structures that the xHC accesses through DMA to cache-coherent memory. With a similar rationale as in the ARM patches for EHCI, using explicit cache maintenance functions to correctly handle the actual transfer buffers in all cases is presumably impossible. Instead this patch also chooses to create a DMA bounce buffer in the XHCI stack where transfer buffers which are not already cache-coherent will be copied to/from. Change-Id: I14e82fffb43b4d52d687b65415f2e33920e088de Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169453 Reviewed-by: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 1fa9964063cce6cbd87ba68334806dde8aa2354c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6643 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-14libpayload: Make EHCI driver cache-awareJulius Werner
This patch makes the EHCI driver work on ARM platforms which usually do not support automatic cache snooping. It uses the new DMA memory mechanism (which needs to be correctly set up in the Coreboot mainboard code) to allocate all EHCI-internal communication structures in cache-coherent memory, and cleans/invalidates the externally supplied transfer buffers in Bulk and Control functions with explicit calls as necessary. Old-Change-Id: Ie8a62545d905b7a4fdd2a56b9405774be69779e5 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/167339 (cherry picked from commit 322338934add36a5372ffe7d2a45e61a4fdd4a54) libpayload: ehci: Cache management is hard, let's go copying... It turns out that my previous commit to make the EHCI stack cache aware on ARM devices wasn't quite correct, and the problem is actually much trickier than I thought. After having some fun with more weird transfer problems that appear/disappear based on stack alignment, this is my current worst-case threat model that any cache managing implementation would need to handle correctly: Some upper layer calls ehci_bulk() with a transfer buffer on its stack. Due to stack alignment, it happens to start just at the top of a cache line, so up to 64 - 4 bytes of ehci_bulk's stack will share that line. ehci_bulk() calls dcache_clean() and initializes the USB transfer. Between that point and the call to dcache_invalidate() at the end of ehci_bulk(), any access to the stack variables in that cache line (even a speculative prefetch) will refetch the line into the cache. Afterwards any other access to a random memory location that just happens to get aliased to the same cache line may evict it again, causing the processor to write out stale data to the transfer buffer and possibly overwrite data that has already been received over USB. In short, any dcache_clean/dcache_invalidate-based implementation that preserves correctness while allowing any arbitrary (non cache-aligned) memory location as a transfer buffer is presumed to be impossible. Instead, this patch causes all transfer data to be copied to/from a cache-coherent bounce buffer. It will still transfer directly if the supplied buffer is already cache-coherent, which can be used by callers to optimize their transfers (and is true by default on x86). Old-Change-Id: I112908410bdbc8ca028d44f2f5d388c529f8057f Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169231 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> (cherry picked from commit 702dc50f1d56fe206442079fa443437f4336daed) Squashed the initial commit and a follow up fix. Change-Id: Idf7e5aa855b4f0221f82fa380a76049f273e4c88 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6633 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-08-14libpayload: Add in a missing "static".Gabe Black
The readwrite_chunk was private to the usb mass storage driver, but wasn't marked as static which was upsetting the compiler. 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> (cherry picked from commit 8140e6145b3d072b7f12a924418570022207c065) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6648 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-14libpayload: Reduce media init timeout to 5 seconds.Shawn Nematbakhsh
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. Change-Id: Icceab99fa266cdf441847627087eaa5de9b88ecc Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169209 (cherry picked from commit 9e55204e92adca0476d273565683f211d6803e7a) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6647 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-14libpayload: Increase accuracy of timeout period for media init.Shawn Nematbakhsh
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. 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> (cherry picked from commit 1d3d535db83ff478c512e37f37015b43927b3efc) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6646 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-14libpayload: usbmsc: Split transfers into 64KB chunksDuncan Laurie
Add a new function to split transfer requests into chunks of 64KB in order to be as compatible as possible with devices that choke when sent large transfer requests. Change-Id: Id11990bd149af14af5535de4af47bda21d1ab51e Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/169170 Reviewed-by: Julius Werner <jwerner@chromium.org> (cherry picked from commit 4c413b007aa23da830877127dd556c4c38b43042) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6636 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-08-12libpayload: usbhub: Don't clear PSC unless it was setJulius Werner
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. Change-Id: Idd46c2199dc6c240bd9ef068fbe70cccc88bac42 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/168098 (cherry picked from commit f7f6f008f701ab3e4a4f785032d8024d676e11cb) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6617 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-12libpayload: ehci: Set explicit terminate bits in dummy_qh next pointers.Julius Werner
The EHCI host controllers in Samsung Exynos SoC seem to be a little more picky than Intel ones. When they reach the dummy_qh in the periodic frame list, they try to access the next qTD pointer even though it's NULL, and run into a HostSystemError. This patch explicitly sets the Terminate bit on those pointers to mark them invalid. Change-Id: I50fa79bbf1c5fab306d7885c01efd66b13e279b8 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/66884 Reviewed-by: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit c575a5c958ce88732d28044352c89418bcd5ea86) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6608 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-12libpayload: Make USB transfer functions return amount of bytesJulius Werner
The USB bulk and control transfer functions in libpayload currently always return 0 for success and 1 for all errors. This is sufficient for current use cases (essentially just mass storage), but other classes (like certain Ethernet adapters) need to be able to tell if a transfer reached the intended amount of bytes, or if it fell short. This patch slightly changes that USB API to return -1 on errors, and the amount of transferred bytes on successes. All drivers in the current libpayload mainline are modified to conform to the new error detection model. Any third party users of this API will need to adapt their if (...<controller>->bulk/control(...)) checks to if (...<controller>->bulk/control(...) < 0) as well. The host controller drivers for OHCI and EHCI correctly implement the new behavior. UHCI and the XHCI stub just comply with the new API by returning 0 or -1, but do not actually count the returned bytes. Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/48308 Reviewed-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Updated the patch to support XHCI as well. Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6 (cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6390 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-11libpayload: xhci: Use Event Data TRBs for transfer event generationJulius Werner
The current XHCI code only sets IOC on the last TRB of a TD, and doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this won't generate an event at all when we have a short transfer that is not on the last TRB of a TD, resulting in event ring desync and everyone having a bad time. However, just setting ISP on other TRBs doesn't really make for a nice solution: we then need to do ugly special casing to fish out the spurious second transfer event you get for short packets, and we still need a way to figure out how many bytes were transferred. Since the Short Packet transfer event only reports untransferred bytes for the current TRB, we would have to manually walk the rest of the unprocessed TRB chain and add up the bytes. Check out U-Boot and the Linux kernel to see how complicated this looks in practice. Now what if we had a way to just tell the HC "I want an event at exactly *this* point in the TD, I want it to have the right completion code for the whole TD, and to contain the exact number of bytes written"? Enter the Event Data TRB: this little gizmo really does pretty much exactly what any sane XHCI driver would want, and I have no idea why it isn't used more often. It solves both the short packet event generation and counting the transferred bytes without requiring any special magic in software. Change-Id: Idab412d61edf30655ec69c80066bfffd80290403 Signed-off-by: Julius Werner <jwerner@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/170980 Reviewed-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> (cherry picked from commit e512c8bcaa5b8e05cae3b9d04cd4947298de999d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6516 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-10serial: Separate the serial hardware init and the serial console init.Gabe Black
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. 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> (cherry picked from commit da9ab46d974745125fe7d8b29ce43336c3586cd5) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6547 Tested-by: build bot (Jenkins)
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-10 17:09:56 +0000