This patch adds the ability to attach a GDB host through the UART to a
running payload. Libpayload implements a small stub that can parse and
respond to the GDB remote protocol and provide the required primitives
(reading/writing registers/memory, etc.) to allow GDB to control
execution.
The goal of this implementation is to be as small and uninvasive as
possible. It implements only the minimum amount of primitives required,
and relies on GDB's impressive workaround capabilities (such as
emulating breakpoints by temporarily replacing instructions) for the
more complicated features. This way, a relatively tiny amount of code on
the firmware side opens a vast range of capabilities to the user, not
just in debugging but also in remote-controlling the firmware to change
its behavior (e.g. through GDBs ability to modify variables and call
functions).
By default, a system with the REMOTEGDB Kconfig will only trap into GDB
when executing halt() (including the calls from die_if(), assert(), and
exception handlers). In addition, payloads can manually call gdb_enter()
if desired. It will print a final "Ready for GDB connection." on the
serial, detach the normal serial output driver and wait for the commands
that GDB starts sending on attach.
Based on original implementation by Gabe Black <gabeblack@chromium.org>.
BUG=chrome-os-partner:18390
TEST=Boot a GDB enabled image in recovery mode (or get it to hit a
halt()), close your terminal, execute '<toolchain>-gdb --symbols
/build/<board>/firmware/depthcharge_gdb/depthcharge.elf --directory
~/trunk/src/third_party/coreboot/payloads/libpayload --directory
~/trunk/src/platform/depthcharge --directory
~/trunk/src/platform/vboot_reference --ex "target remote
<cpu_uart_pty>"' and behold the magic.
(You can also SIGSTOP your terminal's parent shell and the terminal
itself, and SIGCONT them in reverse order after GDB exits. More
convenient wrapper tools to do all this automatically coming soon.)
Original-Change-Id: Ib440d1804126cdfdac4a8801f5015b4487e25269
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202563
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 9c4a642c7be2faf122fef39bdfaddd64aec68b77)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9238b4eb19d3ab2c98e4e1c5946cd7d252ca3c3b
Reviewed-on: http://review.coreboot.org/8119
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There have been leaks of GPL code into libpayload for a while now, for
new features or improvements that require third party code with no
adequate alternative among BSD-licensed software. It seems silly and
counter-productive to keep holding back features and performance
improvements from libpayload for a use-case (proprietary payloads) that
doesn't even seem to be implemented anywhere to date. Open-source
payloads should not need to suffer to appease commercial ones.
Instead, this patch introduces a new Kconfig option to explicitly allow
inclusion of GPL code. It will use Kconfig dependencies and/or Makefile
rules to ensure that no GPL code can end up in the final payload if that
option is unset, allowing proprietary payloads to keep working with the
existing BSD-licensed feature set. New features and patches (that are
sufficiently separate and self-contained to allow guarding through this
config option) can choose whether to import GPL code, and need to depend
on this option if they do.
Also clean up all (known) existing uses of GPL code to depend on the new
option, add some recent third-party imports to the LICENSES file, and
relicense the selfboot.c files to BSD with permission of the author.
BUG=chrome-os-partner:24957
TEST=Compiled Falco and Nyan_Big both with and without the new option,
disassembled output binaries to ensure that memcpy() looks as expected.
Original-Change-Id: I6e3a75b1a8e46291c75a876844c7a01f7d3f2a0e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203513
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit d8e5a9fdf583b5ac861f34baea6a16c4d8536512)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I446fef028264c793b946dd9f765e446bf708b4db
Reviewed-on: http://review.coreboot.org/8118
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This patch makes some slight changes to the exception hook interface.
The old code provides a different handler hook for every exception
type... however, in practice all those hook functions often need to look
very similar, so this creates more boilerplate than it removes. The new
interface just allows for a single hook with the exception type passed
as an argument, and the consumer can signal whether the exception was
handled through the return value. (Right now this still only supports
one consumer, but it could easily be extended to walk through a list of
hooks if the need arises.)
Also move the excepton state from an argument to a global. This avoids a
lot of boilerplate since some consumers need to change the state from
many places, so they would have to pass the same pointer around many
times. It also removes the false suggestion that the exception state was
not global and you could have multiple copies of it (which the exception
core doesn't support for any architecture).
On the ARM side, the exception state is separated from the exception
stack for easier access. (This requires some assembly changes, and I
threw in a few comments and corrected the immediate sigils from '$' to
the official '#' while I'm there.) Since the exception state is now both
stored and loaded through an indirection pointer, this allows for some
very limited reentrance (you could point it to a different struct while
handling an exception, and while you still won't be able to return to
the outer-level exception from there, you could at least swap out the
pointer and return back to System Mode in one go).
BUG=chrome-os-partner:18390
TEST=Made sure normal exceptions still get dumped correctly on both
archs.
Original-Change-Id: I5d9a934fab7c14ccb2c9d7ee4b3465c825521fa2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202562
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 97542110f0b385b9b8d89675866e65db8ca32aeb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
*** Squashed to prevent build failures. ***
libpayload: align arm64 with new exception handling model
The exception handling was previously updated, however the
arm64 changes raced with hat one. Make the arm64 align with
the new model. Without these changes compilation will fail.
BUG=None
BRANCH=None
TEST=Can build libpayload for rush.
Original-Change-Id: I320b39a57b985d1f87446ea7757955664f8dba8f
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/204402
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 0080df41b311ef20f9214b386fa4e38ee54aa1a1)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9a0bb3848cf5286f9f4bb08172a9f4a15278348e
Reviewed-on: http://review.coreboot.org/8117
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds a console_kill_output_driver() function, which can
remove a previously registered output driver. This is mostly useful when
you overlay some output channel over another, such as when the GDB stub
takes direct control of the UART (and thus has to get rid of the
existing serial output driver).
BUG=chrome-os-partner:18390
TEST=None
Original-Change-Id: I6fce95c22fd15cd321ca6b2d6fbc4e3902b1eac3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202561
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 87680a246429d24e99b7b477b743c357f73b752c)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I50001cee4582c962ceedc215d59238867a6ae95a
Reviewed-on: http://review.coreboot.org/8116
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a UART driver for the ipq8064 controller. It still does not
quite work in the receive direction - the receive FIFO returns read
data in 32 bit chunks, which means that 4 keys need to be pressed
before a character pops out of the driver (and it reports it as a
single character).
This issue is being addressed separately, the driver is being checked
in to facilitate concurrent development.
BUG=chrome-os-partner:27784, chrome-os-partner:29313
TEST=with deptcharge modifications in place, the AP148 board comes up
to the depthcharge prompt:
Starting depthcharge on storm...
Original-Change-Id: Ief2cfcca73494be5c4147881144470078adcefb8
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202045
Original-Reviewed-by: Deepa Dinamani <deepad@codeaurora.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 4499318fb9a4e663c504d7c41380ccf2aa89da29)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3e07d7568c20c0e570222971ff219de3a6d9b7cc
Reviewed-on: http://review.coreboot.org/8061
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some drivers being ported to depthcharge use io bit manipulation
macros. The libpayload include file seems the most appropriate place
to keep these macros in. There is no common io.h file across
architectures, the x86 version could be added later if required.
BUG=chrome-os-partner:27784
TEST=observed ipq806x SPI driver deptcharge port (WIP) compile properly.
Original-Change-Id: I33f3be072faefce293c871f7e3bc3b2e6bc38ffe
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/202559
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
(cherry picked from commit ad18a605b4d0ec3251c1614e7358b42aa6b5c45a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8656e12af20ce4cf11d771942e8fe7d4eb2a560d
Reviewed-on: http://review.coreboot.org/8062
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds some assembly code to clear .bss segment. It might have been
already cleared by the loader, but it is not guaranteed. This also
helps when the program is loaded by the debugger.
BUG=none
TEST=observed that .bss is now initialized when the program is
restarted. Verified correct boundaries of the segment.
Original-Change-Id: I0aed0070da53881e4cf8c27049459040c006e765
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/201784
Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Original-Reviewed-by: Trevor Bourget <tbourget@codeaurora.org>
(cherry picked from commit c89ecee5ddfc33a438d4d1926d3756a48f3c2576)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ic0c33d2a8ad22cd23b3ccb73c603cb14ae2aab29
Reviewed-on: http://review.coreboot.org/8060
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Libpayload libc requires timer clock frequency to be at least 1MHz.
Ipq8064 code presently provides a single option of 32kHz. Pretend to
be running at 1 MHz without additional accuracy.
This is a hack which will be reverted as soon as the SOC is configured
to supply a faster running clock.
BUG=chrome-os-partner:27784, chrome-os-partner:28880
TEST=with other changes depthcharge boots to the CLI console
Original-Change-Id: I80ec6652bc5693a549668cd6e824e9cf5c26b182
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/201342
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 466a59967b13986099106f8b44924648c1e6e6cd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I113689191db70710e7a45ccd02d672f482343e35
Reviewed-on: http://review.coreboot.org/8004
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The earlier compilation warning fix (chromium 7e4aa17) incorrectly
assumed that selfboot() is a function defined in the cbfs driver.
This is a commonly available function, it should not come from cbfs.h.
BUG=none
TEST=the following build command succeeds:
rambi storm nyan_big
Original-Change-Id: I3ef49d849168ad9dc24589cbd9ce7382052345bd
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/201386
(cherry picked from commit d5090e8410530f41b9fd33e2caa1d8aa25438105)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I8404fb52112b391982f954a6d06fe4b451dfcb8a
Reviewed-on: http://review.coreboot.org/8003
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This is still using the 32kHz timer coreboot uses. A finer granularity
timer implementation for 806x is in the works.
BUG=chrome-os-partner:27784,chrome-os-partner:28880
TEST=none yet.
Original-Change-Id: Iae206749000d45040090df48199c8d86d76bbae5
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198021
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 8f49f752ab8f84b7c5dc189238732360e8d2aae2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia150c974e5b66939de0b007cf7c1308c187f3289
Reviewed-on: http://review.coreboot.org/8002
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With commands typically shorter than the buffer they're
copied to, copy cmdlen bytes, cut off by the buffer limit.
Change-Id: Ia9d2663bd145eff4538084ac1ef8850cfbcea924
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Found-by: Coverity Scan
Reviewed-on: http://review.coreboot.org/7977
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
ARM processors save the PC value in the Link Register when they handle
and exception, but they store it with an added offset (depending on the
exception type). In order to make crashes easier to read and correctly
support more complicated handlers in libpayload, this patch adjusts the
saved PC value on exception entry to correct for that offset.
(Note: The value that we now store is what ARM calls the "preferred
return address". For most exceptions this is the faulting instruction,
but for software interrupts (SWI) it is the instruction after that. This
is the way most programs like GDB expect the stored PC address to work,
so let's leave it at that.)
Numbers taken from the Architecture Reference Manual at the end of
section B1.8.3.
BRANCH=none
BUG=chrome-os-partner:18390
TEST=Provoked a data abort and an undefined instruction in both coreboot
and depthcharge, confirmed that the PC address was spot on.
Original-Change-Id: Ia958a7edfcd4aa5e04c20148140a6148586935ba
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199844
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 4a914d36bb181d090f75b1414158846d40dc9bac)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib63ca973d5f037a879b4d4d258a4983160b67dd6
Reviewed-on: http://review.coreboot.org/7992
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Make sure the build breaks in case of warnings.
BUG=none
TEST= All builds succeed with the restored patch and fail when a
compilation warning is thrown.
Original-Change-Id: I9bdcd8938f59913e4ba86df5e4921b3f821ef920
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200110
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 16dde875950d6806cc770cdbee4d3ff456ed6f02)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I86988f8d3f1acaa6ceeabdcbfa3cede1e67c28fe
Reviewed-on: http://review.coreboot.org/7911
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Fix pointer related casts since this can create a problem for 64-bit systems.
BUG=None
BRANCH=None
TEST=Compiled successfully for link, nyan using emerge-* libpayload
Original-Change-Id: I4cbd2d9f1efaaac87c3eba69204337fd6893ed66
Original-Reviewed-on: https://chromium-review.googlesource.com/199564
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 914b118a64b0691aeca463dff24252db9c24109e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I11f070ed5d3eddd8b9be30c428cb24c8439e617b
Reviewed-on: http://review.coreboot.org/7905
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
xHCI Spec says TD Size (5 bits) field shall be forced to 31,
if the number of packets to be scheduled is greater than 31.
BUG=chrome-os-partner:27837
BRANCH=rambi,nyan
TEST=Manual: Ensure recovery boot with USB 2.0 media on Squawks
works fine without any babble errors.
Original-Change-Id: Iff14000e2a0ca1b28c49d0da921dbb2a350a1bbd
Original-Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com>
Original-Originally-Reviewed-on: https://chromium-review.googlesource.com/202297
Original-Reviewed-on: https://chromium-review.googlesource.com/202330
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Commit-Queue: Julius Werner <jwerner@chromium.org>
Tested-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ae58b99370df3a86bf15d84b97db858a968b1dbd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9668b947f676c109fad9297e5efde91bf7f796fd
Reviewed-on: http://review.coreboot.org/7913
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When emerging libpayload a warning is generated about selfboot() being
defined without a prior prototype.
Add cbfs.h when CBFS use if compiled fixes the warning.
BUG=none
TEST=build rambi storm nyan_big
verify that there is no compilation warnings thrown any more
Original-Change-Id: Ic9cb5571f708bb006a0d477e451fd1f3b3eb833f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200099
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 7e4aa17936b70dd08f58b3a55c6db55ea03709d7)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie3baaaca82fb6ec432860c638acb2a3ef9451469
Reviewed-on: http://review.coreboot.org/7909
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
The calling convention of payload entry function is different by architecture.
For example, X86 takes no arguments and ARM needs first param to be a
cb_header_ptr*.
To help payloads load and execute other payloads easily and correctly, we should
provide the selfboot() function in libpayload, using same prototype as defined
in coreboot environment.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Original-Change-Id: I8f1cb2c0df788794b2f6f7f5500a3910328a4f84
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199503
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1e916cf021ce68886eb9668982c392eadedc7b7e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I7279ef27f49ef581d25a455dd8f1f2f7f1ba58cb
Reviewed-on: http://review.coreboot.org/7907
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The -z "${V}" sure must have meant to be -n "${V}", but come to think
of it, this check is not necessary, as the following check will
succeed if and only if V is set to 1.
BUG=none
TEST=verified that adding V=1 to the environment causes the lpgcc
debug statements to show up in the output.
Original-Change-Id: I1eb43ef49aeb4f16aef4fbee3a1037e853f9b40f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/200501
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Marc Jones <marc.jones@se-eng.com>
(cherry picked from commit 7d69a292b1dc90e68e539e329f019098f8af5007)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I63785fd9fc88b95d50ecced1f4f74a76ca68089c
Reviewed-on: http://review.coreboot.org/7912
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
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)
The keyboard.c uses IO cycles to access the legacy PC keyboard device.
ARM can't do IO cycles, so remove the option for ARM configs.
Change-Id: Ifc6c2368563f27867f4babad5afdde0e78f4cf78
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7922
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There were a few build warnings in the USB driver to clean
up before -Werror may be enabled.
Change-Id: I220cfcf0ee926912a184a91d3ced3ba61259130e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7921
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The video console runs a video_console_fixup_cursor() function after
every printed character to make sure the cursor is still in the output
window and avoid overflows. For some crazy reason, this function does
not run when cursor_enabled is false... however, that variable is only
about cursor *visibility*, and it's imperative that we still do proper
bounds checking for our output even if the cursor itself doesn't get
displayed (otherwise we can end up overwriting malloc cookies that cause
a panic on the next free() and other fun things like that).
In fact, there seems to be no reason at all to even keep track of the
cursor visibility state in the generic video console framework (the
specific backends already do it, too), so let's remove that code
entirely. Also set the default cursor visibilty in the corebootfb
backend to 0 since that's consistent with what the other backends do.
BUG=None
TEST=Turn on video console on Big, generate enough output to make it
scroll, make sure it does not crash.
Original-Change-Id: I1201a5bccb4711b6ecfc4cf47a8ace16331501b4
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196323
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 1f880bca06ed0a3f2c75abab399d32a2e51ed10e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6c67a9efb00d96fcd67f7bc1ab55a23e78fc479e
Reviewed-on: http://review.coreboot.org/7908
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Some EABI conformant toolchains like GCC need additional functions like raise.
To prevent payloads adding arch-specific implementations everywhere, we should
provide the default version in libpayload.
BUG=none
TEST=emerge-nyan libpayload # pass
BRANCH=none
Original-Change-Id: Id1e3c29590aa5881aefd944a7551949ce9a47b8f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/199686
(cherry picked from commit 395810c4b744dbb720050f79a2c1a30e81464554)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2e1d8c8cb519f8e788c22d081132d23b49b8f822
Reviewed-on: http://review.coreboot.org/7906
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
I always thought the support for multiple logical SCSI units in the USB
mass storage class was a dead feature. Turns out that it's actually used
by SD card readers that provide multiple slots (e.g. one regular sized
and one micro-SD). Implementing perfect support for that would require a
major redesign of the whole MSC stack, since the one device -> one disk
assumption is deeply embedded in our data structures.
Instead, this patch implements a poor man's LUN support that will just
cycle through all available LUNs (in multiple calls to usb_msc_poll())
until it finds a connected device. This should be reasonable enough to
allow these card readers to be usable while only requiring superficial
changes.
Also removes the unused 'protocol' attribute of usb_msc_inst_t.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=Alternatively plug an SD or micro-SD card (or both) into my card
reader, confirm that one of them is correctly detected at all times.
Original-Change-Id: I3df4ca88afe2dcf7928b823aa2a73c2b0f599cf2
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198101
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 960534a20e4334772c29355bb0d310b3f41b31ee)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I39909fc96e32c9a5d76651d91c2b5c16c89ace9e
Reviewed-on: http://review.coreboot.org/7904
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
So I was debugging this faulty USB SD card reader that would just fail
it's REQUEST SENSE response for some reason (sending the CSW immediately
without the data), cursing those damn device vendors for building
non-compliant crap like I always do... when I noticed that we do not
actually set the Allocation Length field in our REQUEST SENSE command
block at all! We set a length in the CBW, but the SCSI command still has
its own length field and the SCSI spec specifically says that the device
has to return the exact amount of bytes listed there (even if it's 0). I
don't know what's more suprising: that we had such a blatant bug in this
stack for so long, or that this card reader is really the first device
to actually be spec compliant in that regard.
This patch fixes the bug and changes the command block structures to be
a little easier to read (why that field was called 'lun' before is
beyond me... LUN is a transport level thing and should never appear in
the command block at all, for any command). It also fixes a memcpy() in
wrap_cbw() to avoid a read buffer overflow that might expose stack frame
data to the device.
BRANCH=rambi?,nyan
BUG=chrome-os-partner:28437
TEST=The card reader works now (for it's first LUN at least).
Original-Change-Id: I86fdcae2ea4d2e2939e3676d31d8b6a4e797873b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/198100
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 88943d9715994a14c50e74170f2453cceca0983b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I3097c223248c07c866a33d4ab8f3db1a7082a815
Reviewed-on: http://review.coreboot.org/7903
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
We recently changed the USB stack to detach devices aggressively that we
don't intend to use. This alone is not really a problem, but it
exarcerbates the fact that our device detachment itself is not very
good. We destroy any local info about the device, but we don't properly
disable the offending port. The device keeps thinking that it's active,
and if we later try to reuse that device address for another device
things become confused.
The real fix would be to properly disable all ports that we don't intend
to use. Unfortunately, this isn't really possible in our current
device/hub polymorphism structure, and I don't want to hack a new
disable_port() callback into usbdev_t that really doesn't belong there.
We will only be able to fix this cleanly after we ported all root hubs
to the generic_hub interface.
Until then, an easy workaround is to just avoid reusing addresses as
long as possible. This is firmware, so the chance that we'll ever run
through 127 devices is really small in practice. Even if we ever fix the
underlying issue, it's probably a smart precaution to keep.
BRANCH=nyan,rambi
BUG=chrome-os-partner:28328
TEST=Boot from a hub that has an "unknown" device in an earlier port
than the stick you want to boot from, make sure you can still boot.
Original-Change-Id: I9b522dd8cbcd441e8c3b8781fcecd2effa0f23ee
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197420
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 28b48aa69b55a983226edf2ea616f33cd4b959e2)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Id4c5c92e75d6b5a7e8f0ee3e396c69c4efd13176
Reviewed-on: http://review.coreboot.org/7881
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The console output driver framework in libpayload is currently built on
the putchar primitive, meaning that every driver's function gets called
one character at a time. This becomes an issue when we add drivers that
could output multiple characters at a time, but have a high constant
overhead per invocation (such as the planned GDB stub, which needs to
wrap a special frame around output strings and wait for an
acknowledgement from the server).
This patch adds a new 'write' function pointer to the
console_output_driver structure as an alternative to 'putchar'. Output
drivers need to provide at least one of the two ('write' is preferred if
available). The CBMEM console driver is ported as a proof of concept
(since it's our most performace-critical driver and should in theory
benefit the most from less function pointer invocations, although it's
probably still negligible compared to the big sprawling mess that is
printf()).
Even with this fix, the problem remains that printf() was written with
the putchar primitive in mind. Even though normal text already contains
an optimization to allow multiple characters at a time, almost all
formatting directives cause their output (including things like
padding whitespace) to be putchar()ed one character at a time.
Therefore, this patch reworks parts of the output code (especially
number printing) to all but remove that inefficiency (directives still
invoke an extra write() call, but at least not one per character). Since
I'm touching printf() core code anyway, I also tried to salvage what I
could from that weird, broken "return negative on error" code path (not
that any of our current output drivers can trigger it anyway).
A final consequence of this patch is that the responsibility to prepend
line feeds with carriage returns is moved into the output driver
implementations. Doing this only makes sense for drivers with explicit
cursor position control (i.e. serial or video), and things like the
CBMEM console that appears like a normal file to the system really have
no business containing carriage returns (we don't want people to
accidentally associate us with Windows, now, do we?).
BUG=chrome-os-partner:18390
TEST=Made sure video and CBMEM console still look good, tried printf()
with as many weird edge-case strings as I could find and compared serial
output as well as sprintf() return value.
Original-Change-Id: Ie05ae489332a0103461620f5348774b6d4afd91a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/196384
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit ab1ef0c07736fe1aa3e0baaf02d258731e6856c0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I78f5aedf6d0c3665924995cdab691ee0162de404
Reviewed-on: http://review.coreboot.org/7880
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
`*memory` is not changed in `hexdump()` and just read so make it
`const`.
Change-Id: I9504d25ab5c785f05c39c9a4f48c21f68659a829
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/5403
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
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>
Turns out that when you clear 28 bits starting with bit 3, you leave bit
31 standing. Ooops...
This shouldn't really matter since that bit is reserved/SBZ in CLIDR
anyway, but it's still nice to fix it. This whole thing should really be
an AND for clarity anyway in my opinion.
Bug found in upstream NetBSD (who would've thought...).
BUG=None
TEST=Still boots.
Change-Id: Ic826e82d58fd1ce984971afea3dfa9296f746d9f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193300
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d270c0ec18b74b272451c456cbf07e99d95896cb)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7745
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
TEST=Booted nyan in normal and recovery mode. Created a map, filled it with some
chars, then verified they can be read from the pointer returned.
BUG=chrome-os-partner:25587
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Id1f1be4f6d2d5734d87bf3452d4806d0fe3fda88
Original-Reviewed-on: https://chromium-review.googlesource.com/188894
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 7fda3885f51c8d383585a80e99ab3df9c789d872)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6255d11396c87f40b0ae12ceab0fd152f2478529
Reviewed-on: http://review.coreboot.org/7658
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use the SPSR to extract and inject CPSR values when an exception happens and
pass that information to exception hooks.
The register structure GDB expects when using its remote protocol has a spot
for the CPSR.
BUG=None
TEST=Built and booted on link, nyan.
BRANCH=None
Original-Change-Id: Id950fb09d72fb0f81e4eef2489c0849ce5dd8aca
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/180253
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8e7014f24a580f84c91fa7b0369dfa922918adcc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I49357fb6a65edeff7a9a48d54254308a6b0efdb7
Reviewed-on: http://review.coreboot.org/7657
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To support a GDB stub, it will be necessary to trap various exceptions which
will be used to implement breakpoints, single stepping, etc.
BUG=None
TEST=Built and booted on Link with hooks installed and saw that they
triggered when exceptions occurred. Built and booted on nyan.
BRANCH=None
Original-Change-Id: Iab659365864a3055159a50b8f6e5c44290d3ba2b
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/179602
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8db0897b1ddad600e247cb4df147c757a8187626)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5e7f724b99988cd259909dd3bd01166fa52317ec
Reviewed-on: http://review.coreboot.org/7656
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
To find the coreboot tables, the payload has historically searched for their
signature in a predefined region of memory. This is a little clumsy on x86,
but it works because you can assume certain regions are RAM. Also, there are
areas which are set aside for the firmware by convention. On x86 there's a
forwarding entry which goes in one of those fairly small conventional areas
and which points to the CBMEM area at the end of memory.
On ARM there aren't areas like that, so we've left out the forwarding entry and
gone directly to CBMEM. RAM may not start at the beginning of the address space
or go to its end, and that means there isn't really anywhere fixed you can put
the coreboot tables. That's meant that libpayload has to be configured on a
per board basis to know where to look for CBMEM.
Now that we have boards that don't have fixed amounts of memory, the location
of the end of RAM isn't fixed even on a per board level which means even that
workaround will no longer cut it.
This change makes coreboot pass the location of the coreboot tables to
libpayload using r0, the first argument register. That means we'll be able to
find them no matter where CBMEM is, and we can get rid of the per board search
ranges.
We can extend this mechanism to x86 as well, but there may be more
complications and it's less necessary there. It would be a good thing to do
eventually though.
BUG=None
TEST=Built and booted on nyan. Changed the size of memory and saw that the
payload could still find the coreboot tables where before it couldn't. Built
for pit, snow, and big.
BRANCH=None
Original-Change-Id: I7218afd999da1662b0db8172fd8125670ceac471
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/185572
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit ca88f39c21158b59abe3001f986207a292359cf5)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Iab14e9502b6ce7a55f0a72e190fa582f89f11a1e
Reviewed-on: http://review.coreboot.org/7655
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch changes the ENTRY() macro in asm.h to create a new section
for every assembler function, thus providing dcache_clean/invalidate_all
and friends with the same --gc-sections goodness that our C functions
have. This requires a few minor changes of moving around data (to make
sure it ends up in the right section) and changing some libgcc functions
(which apparently need to have two names?), but nothing serious.
(You may note that some of our assembly functions have data, sometimes
even writable, within the same .text section. This has been this way
before and I'm not looking to change it for now, although it's not
totally clean. Since we don't enforce read-only sections through paging,
it doesn't really hurt.)
BUG=None
TEST=Nyan and Snow still boot. Confirm dcache_invalidate_all is not
output into any binary anymore since no one actually uses it.
Original-Change-Id: I247b29d6173ba516c8dff59126c93b66f7dc4b8d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/183891
(cherry picked from commit 4a3f2e45e06cc8592d56c3577f41ff879f10e9cc)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ieaa4f2ea9d81c5b9e2b36a772ff9610bdf6446f9
Reviewed-on: http://review.coreboot.org/7451
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@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
Original-Change-Id: I9feda35a50a3488fc504d1561444161e0889deda
Original-Signed-off-by: Marcelo Povoa <marcelogp@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/187020
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 85779a34a161c324cc8af995ada4393137275f20)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Conflicts:
payloads/libpayload/Config.in
payloads/libpayload/drivers/serial.c
Change-Id: I23c8b3728cd7d2d7692b3e86a679e061e88f7bb5
Reviewed-on: http://review.coreboot.org/7422
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These drivers are needed right away and never really fit into depthcharge's
driver model anyway.
CQ-DEPEND=CL:194064
BUG=None
TEST=Built and booted nyan, link, and peach_pit and verified that timer values
in cbmem were reasonable. Built for nyan_big, nyan_blaze and daisy.
BRANCH=None
Original-Change-Id: Ia7953cfece57524262a6c7d6537082af7a00f4d6
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/194058
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit f30a410f0a248c93bc34f5868af1596bf8ce3cdd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I782d20f3cd63210a87c712643c7a53753f5ef301
Reviewed-on: http://review.coreboot.org/7225
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We've recently fixed a problem where an external hard drive would choke
due to one too many CLEAR_FEATURE(HALT) commands in the XHCI stack with
"libpayload: usb: xhci: Fix STALL endpoint handling". Clearing stall
conditions from within the transfer function is wrong in general... this
is really something that is host controller agnostic and should be left
to the higher-level driver to decide. The mass storage driver (the only
one that should really encounter stalls right now) already contains the
proper amount of clear_stall() calls... any more than that is redundant
and as we found out potentially dangerous.
This patch removes automatic clear stalls from UHCI and OHCI drivers as
well to make things consistent between host controllers.
BUG=chromium:192866
TEST=None. I could borrow the original hard drive from Shawn and compile
a Snow to only use the OHCI driver to reproduce/verify this, but alas, I
am lazy (and it's really not that important).
Original-Change-Id: Ie1e4d4d2d70fa4abf8b4dabd33b10d6d4012048a
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193732
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit d46e183f3e7e0b0130becdefa6fd3ef8097df54b)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ie8f4ab3db8ec0d9a2d1e91c62967833e59c46700
Reviewed-on: http://review.coreboot.org/7223
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch combines a few minor fixes and refactoring to the various
host controller and root hub drivers to ensure they all do the right
thing on a call to usb_exit(). It puts a usb_detach_device(0) call
into detach_controller() so that the HCD doesn't need to remember to
tear down the root hub itself, and makes sure all root hubs properly
detach the subtree of devices connected to their ports first (as
generic_hub and by extension XHCI had already been doing).
It also fixes up some missing free() calls and replaces most 'ptr =
malloc(); if (!ptr) fatal()' idioms with the new x(z)alloc().
BUG=chromium:343415
TEST=Tested EHCI on Big and OHCI, EHCI, and XHCI on Snow. Could not test
UHCI (unless anyone volunteers to port coreboot to a ZGB? ;) ), but the
changes are really tame.
Original-Change-Id: I6eca51ff2685d0946fe4267ad7d3ec48ad7fc510
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/193731
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 5791b546e5a21a360d0c65888a5b92d5f48f8178)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I00138f0aeceb12ed721f7368c7788c9b6bee227d
Reviewed-on: http://review.coreboot.org/7222
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Furquan Shaikh