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>
config.panther was added in a chromium upstream patch. We don't
want mainboard specific configs in libpayload, so remove it.
Change-Id: Ibfb894a0262911c13e88bc161749b78e2b5c5185
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7450
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Update x86 and ARM defconfig. Adds default N to specific timer
and serial drivers.
Change-Id: Ida6b953565dc6053729c2a72c6342d86596c599b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7449
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This patch changes several cache-related pieces to be cleaner, faster or
more correct. The largest point is removing the old
arm_invalidate_caches() function and surrounding bootblock code to
initialize SCTLR and replace it with an all-assembly function that takes
care of cache and SCTLR initialization to bring the system to a known
state. It runs without stack and before coreboot makes any write
accesses to be as compatible as possible with whatever state the system
was left in by preceeding code. This also finally fixes the dreaded
icache bug that wasted hundreds of milliseconds during boot.
Old-Change-Id: I7bb4995af8184f6383f8e3b1b870b0662bde8bd4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183890
(cherry picked from commit 07a35925dc957919bf88dfc90515971a36e81b97)
nyan_big: apply cache-related changes from nyan
This applies the same changes from 07a3592 that were applied to nyan.
Old-Change-Id: Idcbe85436d7a2f65fcd751954012eb5f4bec0b6c
Reviewed-on: https://chromium-review.googlesource.com/184551
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 4af27f02614da41c611aee2c6d175b1b948428ea)
Squashed the followup patch for nyan_big into the original patch.
Change-Id: Id14aef7846355ea2da496e55da227b635aca409e
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
(cherry picked from commit 4cbf25f8eca3a12bbfec5b015953c0fc2b69c877)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6993
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These drivers need to be ready right away and never really fit into the
depthcharge driver model anyway.
CQ-DEPEND=CL:194063
BUG=None
TEST=Built and booted on nyan and peach_pit. Built for nyan_big, nyan_blaze,
and daisy.
BRANCH=None
Original-Change-Id: I9570dee53c57d42ef4cd956f66a878ce39a2dc20
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/194057
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 26e18f680c93fc990a3d1057c164f19859634a9f)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ia2233e2bd821d8de8d2d57a9423aeb74be7efd93
Reviewed-on: http://review.coreboot.org/7224
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch switches every last part of Coreboot on ARM over to Thumb
mode: libpayload, the internal libgcc, and assorted assembly files. In
combination with the respective depthcharge patch, this will switch to
Thumb mode right after the entry point of the bootblock and not switch
back to ARM until the final assembly stub that jumps to the kernel.
The required changes to make this work include some new headers and
Makefile flags to handle assembly files (using the unified syntax and
the same helper macros as Linux), modifying our custom-written libgcc
code for 64-bit division to support Thumb (removing some stale old files
that were never really used for clarity), and flipping the general
CFLAGS to Thumb (some more cleanup there as well while I'm at it).
BUG=None
TEST=Snow and Nyan still boot.
Original-Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/182212
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5f65c17cbfae165a95354146ae79e06c512c2c5a)
Conflicts:
payloads/libpayload/include/arm/arch/asm.h
src/arch/arm/Makefile.inc
src/arch/arm/armv7/Makefile.inc
*** There is an issue with what to do with ramstage-S-ccopts, and
*** will need to be covered in additional ARM cleanup patches.
Change-Id: I80c04281e3adbf74f9f477486a96b9fafeb455b3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/6930
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch adds the 10ms TRSTRCY delay between a reset and the following
Set Address command that is required by the USB 2.0 specification to the
EHCI root hub driver. The generic_hub driver that's used for XHCI and
external hubs already included this delay. This is such a glaring
violation of the spec that I'm really amazed how many USB 2.0 devices
we tested before seemed perfectly fine with responding to a Set Address
within 2 microframes of the reset...
It also increases the port reset hold delay by one millisecond to avoid
an ugly race condition on Tegra SoCs: they decided to time the 50ms
themselves instead of relying on the CPU to do it (fair enough), and to
automatically transition Port Reset to 0 and Port Enable to 1 after that
(bad idea). If the CPU's read-modify-write to clear Port Reset races
exactly with the host controller setting Port Enable, we may end up
clearing the bit again and going into the companion controller handoff
path later on. The added millisecond shouldn't cause any problems for
other host controllers and is not a big deal compared to other delays in
this code path.
BUG=chrome-os-partner:26749
TEST=Run several dozen reboot loops with The USB Stick of Death (TM) (a
blue Patriot XT 13fe:5200 with bcdDevice = 1.00), make sure it always
gets detected correctly.
Original-Change-Id: Idd3329ae6d7e5e1c07a84a5475549b3459836b31
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/189872
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
Original-Reviewed-by: Jim Lin <jilin@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 4deca38e9d79f6373f4418fcaf51a6945232c8b8)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I68a29bfd2e0f30409fbfc330b2575f0f9f61a79d
Reviewed-on: http://review.coreboot.org/7221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch enables the OHCI driver to use DMA memory, which is necessary
for ARM systems where DMA devices are not cache coherent. I really only
need this to test some later OHCI changes, but it was easy enough...
copied almost verbatim from ehci.c.
Change-Id: Ia717eef28340bd6182a6782e83bfdd0693cf0db1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193730
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit e46b6ebc439e86a00e13bf656d60cf6c186a3777)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7010
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Remove the call to clear_stall in xhci_reset_endpoint because we will
call clear_stall from the mass-storage driver.
- Remove the xhci_reset_endpoint call from xhci_bulk on STALL since we
will reset on the next transfer anyway.
- Remove the clear_halt parameter from xhci_bulk since it's now unused.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I852b87621861109e596ec24b78a8f036d796ff14
Reviewed-on: https://chromium-review.googlesource.com/192866
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit e67e4f0545cbdc074328c83c7edccf9e712cd7be)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7011
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
libpayload's kconfig is totally incompatible with other kconfig versions,
today. Using other versions just doesn't work any more, so don't use the
overridable $(obj)/util/kconfig path. Choose a path that reflects the
incompatibility: $(obj)/util/lp_kconfig, instead.
This whole every-(sub)project-has-it's-own-patched-kconfig-version makes
me really, really sad :'-(
Change-Id: I964772f3323dc20aa7c1cc26a384a2fbca1dbb5e
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: http://review.coreboot.org/7061
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: I9b80b72de96fb28489dcc8547b8f748ea4fcc355
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7074
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: Patrick Georgi <pgeorgi@google.com>
If a port is connected before and after an xhci controller reset, the
PORTSC CSC bit may not be asserted. Add an additional check in
xhci_rh_port_status_changed for the PRC bit so we can correctly handle
ports in such a state.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I2d623aae647ab13711badd7211ab467afdc69548
Reviewed-on: https://chromium-review.googlesource.com/189394
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit ee7c3ea182b35bb6ce3c62f301c4515714f6e654)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7002
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The generic roothub reset port function is overly broad and does some
things which may be undesirable, such as issuing multiple resets to a
port if the reset is deemed to have finished too quickly. Remove the
generic function and replace it with a controller-specific function,
currently only implemented for xhci.
Change-Id: Id46f73ea3341d4d01d2b517c6bf687402022d272
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189495
Reviewed-by: Julius Werner <jwerner@chromium.org>
(cherry picked from commit 54e1da075b0106b0a1f736641fa52c39401d349d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7001
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Pass -ggdb3 to the compiler when building libpayload, -ggdb so that it uses
"the most expressive format available", and 3 so that the debugging level is
set to 3, the highest value currently supported. The debugging information can
be stripped by the payload consuming the library, and will definitely be
stripped by cbfstool when installing that payload into an image.
Change-Id: Ifd6c4a928fbb0b9fa9b3b2e0ea298abff31baf3b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/180252
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit dc04daaf099c53c57508b66e08f40945345a56ca)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6980
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch fixes the remaining few bugs in our shiny new cache iteration
by set/way/level algorithm to actually make it work: It makes it start
from cache level 0 (previously it would always start at LoC and be
"done" instantly), fixes up the two shifts that isolate the set bits at
the end (which didn't seem to account for the fact that the first shift
affects the second), and throws an S bit on that last shift so that it
actually affects the conditionals after it.
In addition, also moves the next_level block to the top so that we can
share (and thus eliminate) some code at initialization, and turns the
whole thing into a thrice-instantiated macro to create functions that
fit our existing interface.
Change-Id: I1338a589cbb37d74ea6e7a3d4f67ff827e24edbe
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183879
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 6d94f8330191c316fe093ddb5288329453da8a4b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6932
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch adds another cache invalidation stub to the x86 arch to
make it usable in common code. This whole stuff should probably be
redesigned anyway but I just want to get it working and unblock my CL
for now... more cleanups coming later.
Change-Id: I2e8bdd8aa0e6723209384c24042f053f2e993fe6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182534
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit cafce5182a7a2a9ce17ad40d9d893a40ebd5aafd)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6919
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The memcpy/memset/memmove assembly implementations have been taken from
U-Boot, which originally got them from Linux. I turns out that they are
actually not that bad, but they could use an update. This patch pulls in
the current Linux upstream versions of those files, removing some old
U-Boot cruft such as checking whether the two pointers in a memcpy() are
equal (really now?) or side-stepping the R8 register because it was used
for special purposes. It also returns to the good old Linux
ENTRY/ENDPROC macros since we have them now anyway, and straightens out
the W() macro in preparation for unified thumb support.
Change-Id: I138af269b423bef0a237759ac29f1ee58ca206a0
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182179
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 777127997bde5785b21d422d0b6eb04c4328b478)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6918
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
libgcc/macros.h contains some useful assembly macros that are common in
Linux kernel code and facilitate things such as unified ARM/THUMB
assembly. This patch moves it to a more general place where it can be
used by other code as well.
Change-Id: If68e8930aaafa706c54cf9a156fac826b31bb193
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/182178
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit a780670def94a969829811fa8cf257f12b88f085)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6917
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This is needed by depthcharge on ARM if coreboot is loading its
ramstage from the RW section of the ROM.
Change-Id: I96c6c04a0cee39854b45f2eda169e93461da0694
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/176757
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit cf26be4cb527b0fc4212d401a8c77ceb1c7992d0)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6906
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This functionality is already available for ARM, so lets add it to x86 as
well. We'll want to be able to hook exceptions when running as a remote GDB
target.
Change-Id: I42f640b08eb9eb86a1bcab3c327f7780191a2eb5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179601
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5b8cf0c9f70a7e14766a2b095e6739a8d6321a34)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6898
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This function returns the number of microseconds scaled from the number of raw
timer ticks. It accepts a base parameter which is subtracted from the current
time, which makes it easy to keep track of relative times.
Change-Id: I55f2f9e90c0e12cda430bbe88b044f12b0b563c8
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/179600
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4dd549e18d170dbf918c5b4b11bbe1f4e99b6695)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6897
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The xmalloc wrapper checks whether the malloc succeeded, and if not stops
execution and prints a message. xmalloc always returns a valid pointer. The
xzalloc wrapper does the same thing, but also zeroes the memory before
returning it.
Old-Change-Id: I00e7de04a5c368ab3603530b98bd3e3596e10632
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178001
Reviewed-by: Julius Werner <jwerner@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 4029796d4f66601e33ae3038dbfc3299f56baf89)
libpayload: malloc: Fix xmalloc() for zero byte allocations
The C standard considers it legal to return a NULL pointer for zero
length memory allocations, and our malloc implementation does in fact
make use of that. xmalloc() and xzmalloc() should therefore not consider
this case a failure.
Also fixed a minor formatting issue.
Old-Change-Id: Ib9b75df9458ce2ba75fd0bc0af9814a3323298eb
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178725
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 3033437e9d89c6072464860ea50ea27dcb76fe54)
Squashed 2 libpayload malloc related commits.
Change-Id: I682ef5f4aad58c93ae2be40e2edc1fd29e5d0438
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6890
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
If a programming error is detected, die can be used to print a message and
stop execution similar to failing an assert. There's also a "die_if" function
which is conditional.
die functions, like asserts, should be used to trap programming errors and not
when the hardware does something wrong. If all code was written perfectly, no
die function would ever be called. In other words, it would be appropriate to
use die if a function was called with a value that was out of bounds or if
malloc failed. It wouldn't be appropriate if an external device doesn't
respond.
In the future, the die family of functions might print a stack trace or show
other debugging info.
Old-Change-Id: I653fc8cb0b4e459522f1b86f7fac280836d57916
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/178000
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 59df109d56a0f5346562de9b3124666a4443adf0)
libpayload: Fix the license in some files which were accidentally made GPL.
Some files were accidentally made GPL when they were added to libpayload. This
change changes them over to a BSD license to be in line with the intended
license of libpayload.
Old-Change-Id: Ia95ac4951b173dcb93cb489705680e7313df3c92
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/182202
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 5f47600e50e82de226f2fa6ea81d4a3d1c56277b)
Squashed the initial patch for "die" functions and a later update to
the license header.
Change-Id: I3a62cd820e676f4458e61808733d81edd3d76e87
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6889
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
"Hey guys, I have this awesome idea! How about we put a huge array
filled with 0xa5 into the data segment of our uncompressed romstage
for no particular reason? Give our SPI driver something to do so it
doesn't get too bored, you know?"
Guess it pays off to just hexdump our image and sanity-check it top to
bottom every once in a while...
Also reduces the size because 8K is crazy just to print a bunch of
registers (256 bytes ought to be enough for anybody).
Old-Change-Id: Icec0a711a1b5140d2ebcd98338ec638a4b6262fa
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/176762
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 61c360a1c3f445535c9ff383a389e643cfe4527c)
arm: Remove exception_test()
The exception_test() mechanism might have been useful when exceptions
were first implemented, but now that they are pretty stable it's really
not necessary anymore (especially not on every single boot in production
Chromebooks). It forces a simple unaligned access, and as we start
having exceptions in stages that might not have paging turned on yet,
it's better to remove that completely.
Also removed the duplicated implementations of SCTLR-stuff and switched
to the existing ones in cache.h.
Old-Change-Id: I85e66269f5e2f2dfd3e8aaaa18441493514b62f8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177101
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit d0706b848572fbea26e0e432ec5827503b9603c9)
Squashed 2 exception related commits.
Change-Id: Id2c115ee39a0732c375472afc0194436e2f5e069
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes the -ffixed-r8 CFLAG from the coreboot and libpayload
Makefiles. This seems to be a relic from U-Boot, which uses that
register to keep it's global data structure pointer. There's no reason
for us to throw away a perfectly fine register on this already pretty
constrained architecture.
Also removed a config.h inclusion from the Makefile because that should
really be done inside the C files.
Change-Id: Ia176c0f323c1be07cddf88fa5488788786a27cdf
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177110
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 2a81112abde284ba09020db6afa363169911a7f6)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6880
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Forgot an asterisk and everything goes to hell. Sorry about that.
Change-Id: I6b2503ca3ea0f80d4e4e5d8b8c0e986fec5db2c9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173587
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: David James <davidjames@chromium.org>
(cherry picked from commit 2a357560a697b56cc6022a4dd3dda47b33568d83)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6854
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The dump_td() debug function in the EHCI stack incorrectly masks the
amount of transferred bytes on output... the actual field is 15 bits
wide (30:16). Let's just use the mask constant we already have for all
the other code.
Change-Id: I28c6f0ec75cc613e38d53b670645d19bf9ffe1b9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/174986
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 570077da7f16bbe2204b4a80790e4bd8fe1a2bd7)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6853
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are ARM systems which are essentially heterogeneous multicores where
some cores implement a different ARM architecture version than other cores. A
specific example is the tegra124 which boots on an ARMv4 coprocessor while
most code, including most of the firmware, runs on the main ARMv7 core. To
support SOCs like this, the plan is to generalize the ARM architecture so that
all versions are available, and an SOC/CPU can then select what architecture
variant should be used for each component of the firmware; bootblock,
romstage, and ramstage.
Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171338
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
ARM: Split out ARMv7 code and make it possible to have other arch versions.
We don't always want to use ARMv7 code when building for ARM, so we should
separate out the ARMv7 code so it can be excluded, and also make it possible
to include code for some other version of the architecture instead, all per
build component for cases where we need more than one architecture version
at a time.
The tegra124 bootblock will ultimately need to be ARMv4, but until we have
some ARMv4 code to switch over to we can leave it set to ARMv7.
Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7
Reviewed-on: https://chromium-review.googlesource.com/171400
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483)
Squashed two related patches for splitting ARM support into general
ARM support and ARMv7 specific pieces.
Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6782
Tested-by: build bot (Jenkins)
This target does (pretty much) exactly the same what jenkins
is doing on our build nodes:
- complete abuild run of our tree with a given payload
- building all libpayload configs we ship
- building the cbmem utility
In fact at some point we could tell jenkins to just run this command.
For debugging, pass along V and Q variables so inner make processes
are slightly more noisy on demand.
Change-Id: Ib515170603a151cc3c3b10c743f1468a9875dbdc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6797
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This patch represents a major overhaul of the USB enumeration code in
order to make it cleaner and much more robust to weird or malicious
devices. The main improvement is that it correctly parses the USB
descriptors even if there are unknown descriptors interspersed within,
which is perfectly legal and in particular present on all SuperSpeed
devices (due to the SuperSpeed Endpoint Companion Descriptor).
In addition, it gets rid of the really whacky and special cased
get_descriptor() function, which would read every descriptor twice
whether it made sense or not. The new code makes the callers allocate
descriptor memory and only read stuff twice when it's really necessary
(i.e. the device and configuration descriptors).
Finally, it also moves some more responsibilities into the
controller-specific set_address() function in order to make sure things
are initialized at the same stage for all controllers. In the new model
it initializes the device entry (which zeroes the endpoint array), sets
up endpoint 0 (including MPS), sets the device address and finally
returns the whole usbdev_t structure with that address correctly set.
Note that this should make SuperSpeed devices work, but SuperSpeed hubs
are a wholly different story and would require a custom hub driver
(since the hub descriptor and port status formats are different for USB
3.0 ports, and the whole issue about the same hub showing up as two
different devices on two different ports might present additional
challenges). The stack currently just issues a warning and refuses to
initialize this part of the hub, which means that 3.0 devices connected
through a 3.0 hub may not work correctly.
Change-Id: Ie0b82dca23b7a750658ccc1a85f9daae5fbc20e1
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170666
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit ecec80e062f7efe32a9a17479dcf8cb678a4a98b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6780
Tested-by: build bot (Jenkins)
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>
This patch fixes a bug in the XHCI stack that occurs when a multi-TRB TD
times out before the last TRB is processed. The driver will correctly
issue a Stop Endpoint command in that case, but the xHC will still
preserve the transfer state and just pick up right after that on the
next doorbell ring. It will then process the leftover TRBs from the old
TD the next time a transfer is issued. (cf. XHCI 4.6.9)
We fix this by changing the existing xhci_reset_endpoint() calls in
transfer functions to not only trigger on Halted (2) and Error (4), but
also on Stopped (3). That function will not actually issue a Reset
Endpoint command in this case, but it will nuke the whole transfer ring
and issue a Set TR Dequeue Pointer command, which is sufficient (though
slightly overkill) to solve our problem.
Change-Id: I3abbe30ff9d4911a8af1f792324e018d427019e8
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170833
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit f12424af0e29ac12963e8e5a7970fadcc0bb6cee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6787
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This minor refactoring patch changes the signature of all limited cache
invalidation functions in coreboot and libpayload from unsigned long to
void * for the address argument, since that's really what you have in
95% of the cases and I think it's ugly to have casting boilerplate all
over the place.
Change-Id: Ic9d3b2ea70b6aa8aea6647adae43ee2183b4e065
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167338
(cherry picked from commit d550bec944736dfa29fcf109e30f17a94af03576)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6623
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
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>
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>
make junit.xml tries to build it, but fails
(ARM port doesn't seem to be ready?)
Useful test case to demonstrate a failing
libpayload build.
Change-Id: Iba4fe551b48f631e6a3bd90eb07930fc70761332
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4552
Tested-by: build bot (Jenkins)
Reviewed-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch fixes the following minor bugs in the USB stack:
1. Ensure that all dynamically allocated device structures are cleaned
on detachment, and that the device address is correctly released again.
2. Make sure MSC and HID drivers notice missing endpoints and actually
detach the device in that case (to prevent it from being used).
3. Make sure XHCI-specific set_address() cleans up all data structures
on failure.
4. Fix broken Slot ID range check that prevented XHCI devices from being
correctly cleaned up.
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>
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)
The cache functions for armv7 require 'march=armv7-a' to use
the 'isb' and 'dsb' instructions.
Change-Id: I3b7ad8fc7da8c3167b38fd1a325090fe49e4ca42
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6668
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Patch 'coreboot_tables: reduce redundant data structures' (1f5487a)
added a new lb_range structure to coreboot and libpayload but the
original chromium patch added cb_range to libpayload instead. A followup
patch 'arm: libpayload: Add cache coherent DMA memory definition
and management' (b8fad3d) used the incorrect cb_range structure but
this wasn't caught since the current verification build doesn't
build libpayload for arm.
Change-Id: I7cedc66a4794bf4daa214f54be6e917f96418ff6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6665
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Since the DMA memory is allocated by Coreboot (outside of the payload's
linker script), it won't get zeroed upon loading like the heap.
Therefore, a warm reboot that doesn't reset memory may leave stale
malloc cookies lying around and misinterpret them as memory that is
still in use on the next boot. After several boots this may fill up the
whole DMA memory and lead to OOM conditions.
Therefore, this patch explicitly wipes the first cookie in
init_dma_memory() to prevent that from happening. It also expands the
existing memory allocator debugging code to cover the DMA parts, which
was very helpful in identifying this particular problem.
Change-Id: I6e2083c286ff8ec865b22dd922c39c456944b451
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169455
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8e5e1784638563b865553125cd5dab1d36a5d2cb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6645
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
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>
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>
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>
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>
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>
This patch adds a mechanism to set aside a region of cache-coherent
(i.e. usually uncached) virtual memory, which can be used to communicate
with DMA devices without automatic cache snooping (common on ARM)
without the need of explicit flush/invalidation instructions in the
driver code.
This works by setting aside said region in the (board-specific) page
table setup, as exemplary done in this patch for the Snow and Pit
boards. It uses a new mechanism for adding board-specific Coreboot table
entries to describe this region in an entry with the LB_DMA tag.
Libpayload's memory allocator is enhanced to be able to operate on
distinct types/regions of memory. It provides dma_malloc() and
dma_memalign() functions for use in drivers, which by default just
operate on the same heap as their traditional counterparts. However, if
the Coreboot table parsing code finds a CB_DMA section, further requests
through the dma_xxx() functions will return memory from the region
described therein instead.
Change-Id: Ia9c249249e936bbc3eb76e7b4822af2230ffb186
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167155
(cherry picked from commit d142ccdcd902a9d6ab4d495fbe6cbe85c61a5f01)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6622
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
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>
The USB bulk and control transfer functions in libpayload currently
always return 0 for success and 1 for all errors. This is sufficient for
current use cases (essentially just mass storage), but other classes
(like certain Ethernet adapters) need to be able to tell if a transfer
reached the intended amount of bytes, or if it fell short.
This patch slightly changes that USB API to return -1 on errors, and the
amount of transferred bytes on successes. All drivers in the current
libpayload mainline are modified to conform to the new error detection
model. Any third party users of this API will need to adapt their
if (...<controller>->bulk/control(...)) checks to
if (...<controller>->bulk/control(...) < 0) as well.
The host controller drivers for OHCI and EHCI correctly implement the
new behavior. UHCI and the XHCI stub just comply with the new API by
returning 0 or -1, but do not actually count the returned bytes.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/48308
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Updated the patch to support XHCI as well.
Change-Id: Ic2ea2810c5edb992cbe185bc9711d2f8f557cae6
(cherry picked from commit e39e2d84762a3804653d950a228ed2269c651458)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6390
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The current XHCI code only sets IOC on the last TRB of a TD, and
doesn't set ISP anywhere. On my Synopsys DesignWare3 controller, this
won't generate an event at all when we have a short transfer that is not
on the last TRB of a TD, resulting in event ring desync and everyone
having a bad time. However, just setting ISP on other TRBs doesn't
really make for a nice solution: we then need to do ugly special casing
to fish out the spurious second transfer event you get for short
packets, and we still need a way to figure out how many bytes were
transferred. Since the Short Packet transfer event only reports
untransferred bytes for the current TRB, we would have to manually walk
the rest of the unprocessed TRB chain and add up the bytes. Check out
U-Boot and the Linux kernel to see how complicated this looks in
practice.
Now what if we had a way to just tell the HC "I want an event at exactly
*this* point in the TD, I want it to have the right completion code for
the whole TD, and to contain the exact number of bytes written"? Enter
the Event Data TRB: this little gizmo really does pretty much exactly
what any sane XHCI driver would want, and I have no idea why it isn't
used more often. It solves both the short packet event generation and
counting the transferred bytes without requiring any special magic in
software.
Change-Id: Idab412d61edf30655ec69c80066bfffd80290403
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170980
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
(cherry picked from commit e512c8bcaa5b8e05cae3b9d04cd4947298de999d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6516
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This new version is used to implement the version which doesn't take the
input and output buffer sizes.
Old-Change-Id: I8935024aca0849bc939263d7fc3036c586e63c68
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65510
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 465d167ad2f6a67d0b2c91fb6c68c8f9a09dd395)
libpayload: Make lzma truncation non-fatal.
If the size the lzma header claims it needs is bigger than the space we have,
print a message and continue rather than erroring out. Apparently the encoder
is lazy sometimes and just puts a large value there regardless of what the
actual size is.
This was the original intention for this code, but an outdated version of the
patch ended up being submitted.
Old-Change-Id: Ibcf7ac0fd4b65ce85377421a4ee67b82d92d29d3
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66235
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 30c628eeada274fc8b94f8f69f9df4f33cbfc773)
Squashed two related commits and updated the commit message to be
more clear.
Change-Id: I484b5c1e3809781033d146609a35a9e5e666c8ed
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6408
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
A bootblock overwalk was occuring when deriving the actual
length, the bootblock size was not taken into account and bootblock
size was not aligned.
Resolved merge conflict.
Change-Id: I7eb42f8deaaf223dcf07b37bb7dde4643acd508f
Signed-off-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65989
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Steve Sherk <ssherk70@gmail.com>
Tested-by: Steve Sherk <ssherk70@gmail.com>
(cherry picked from commit 20b0ba479b01755fbdc7f3dd9214e8af923402ba)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6539
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
There are three coreboot table tags that all define some kind of memory
region, and each has their own homologous struct. I'm about to add a
fourth so I'll just clean this up and turn it into a generic struct
lb_range instead.
Change-Id: Id148b2737d442e0636d2c05e74efa1fdf844a0d3
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167154
(cherry picked from commit 22d82ffa3f5500fbc1b785e343add25e61f4f194)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6456
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
This patch enhances the armv7 exception handlers in Coreboot and
libpayload to show the correct SP and LR registers from the aborted
context, and also dump a part of the current stack. Since we cannot
access the banked registers of SVC mode from a different exception mode,
it changes Coreboot (and its payloads) to run in System mode instead. As
both modes can execute all privileged instructions, this should not have
any noticeable effect on firmware operation (please correct me if I'm
wrong!).
Change-Id: I0e04f47619e55308f7da4a3a99c9cae6ae35cc30
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170045
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit d0db2f5e938200e3f5899c5e1f1606ab2dd5b334)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6538
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Representing a (non-negative) length with a signed integer is not
optimal, so change its type to `size_t`.
Change-Id: Ic0c2b7e081ba32d917409568ee53007d9ab7f8f3
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/4768
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
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)
This script is used by 'make menuconfig', but being non executable it
fails to run, causing the make invocation failure.
Setting 'x' mode bits fixes the problem.
Change-Id: I925ca4ee056937b6c38ad34f5520fd621f9d9eb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/173564
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 3ddb9d221ecc3df968853d765b566cf0648a7525)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6540
Tested-by: build bot (Jenkins)
When libpayload header files are included in the payload itself, it's possible
that the payloads config settings will conflict with the ones in libpayload.
It's also possible for the libpayload config settings to conflict with the
payloads. To avoid that, the libpayload config settings have _LP_ (for
libpayload) added to them. The symbols themselves as defined in the Config.in files
are still the same, but the prefix added to them is now CONFIG_LP_ instead of just
CONFIG_.
Change-Id: Ib8a46d202e7880afdeac7924d69a949bfbcc5f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/65303
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 23e866da20862cace0ed2a67d6fb74056bc9ea9a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6427
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
This adds a wrapper for data cache clean (without invalidate)
by set/way.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I09ee1563890350a6c1d04f1b96ac5d0c042e2af2
Reviewed-on: https://gerrit.chromium.org/gerrit/66118
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 05bc4f8564c547eacb9cc840a03b916b3c1c6001)
armv7: clean but do not invalidate caches between stages
This cleans the caches without invalidating them between stages. The
dcache content should still be valid when the next stage begins, so
we should see a small performance gain.
(thanks to gabeblack for pointing this out)
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: Ie18d163f3a78e2786e9fbc7479c8bd896b8ac3aa
Reviewed-on: https://gerrit.chromium.org/gerrit/66119
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 619bfe4cf9b93847e38d03d7076beb78fbfa1d1d)
armv7: Make coreboot and libpayload cache files the same
This merges the difference between the ARM version of cache.c and
cache.h for libpayload and coreboot.
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Old-Change-Id: I246d2ec98385100304266f4bb15337a8fcf8df93
Reviewed-on: https://gerrit.chromium.org/gerrit/66120
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
(cherry picked from commit 0c92f694034f1e94a8aa7811251738c9dc3db2c6)
ARM: Fix cache cleaning operation.
There was no behavior defined for OP_DCCSW in dcache_op_set_way, so it
silently did nothing. Since we started using that to clean the cache between
stages and I have a change that enables caches earlier on, this was preventing
booting on pit.
Old-Change-Id: I3615b6569bf8de195d19d26b62f02932322b7601
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66234
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 99241468cb9dcc86fcca9266ffe72baa88a1f79f)
libpayload: Fix data cache cleaning on ARM.
A similar fix was made to coreboot where OP_DCCSW was silently not doing
anything in dcache_op_set_way.
Old-Change-Id: Ia0798aef0cd02da7d1a14b7affa05038a002ab3b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66236
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 6f6596a182a6780a2e997ac320733722697990c5)
Squashed five related commits.
Change-Id: I763d42bd5dd9f58734e1e21eb7c8ce3ce2ea56ee
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6418
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
The generic cbfs code relies on the libpayload_init_default_cbfs_media
symbol. However, none was provided for ARM. Provide an empty
implementation that returns an error as there is no generic way
to locate the default cbfs media.
Old-Change-Id: Ie0d06fbe6fc790c9d92434cd2d60922908acdc69
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56805
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
(cherry picked from commit d3410c28ef9f37b832e2fa2d18351dda332bc9f7)
libpayload: place dummy_media.c in correct object list
The commit introducing dummy_media.c was placed in the
libc object list. This wasn't correct. It should be in the
libcbfs object list as well as guarded by CONFIG_CBFS.
Old-Change-Id: Iace43fff8f85f60ecac5e6eb8350cd1f3ee9d35e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56925
(cherry picked from commit 7937c7c5e95a934593bc0cedd5f4496b4770c303)
Squashed two related commits.
Change-Id: I84cd132b44cc2ea5b29acf109a3562baaeede9c6
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6411
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This change makes it possible for vboot to avoid an
exploit that could cause involuntary switch to dev mode.
It gives depthcharge/vboot some information on the
type of input device that generated a key.
BUG=chrome-os-partner:21729
TEST=manually tested for panther
BRANCH=none
CQ-DEPEND=CL:182420,CL:182241,CL:182946
Change-Id: I87bdac34bfc50f3adb0b35a2c57a8f95f4fbc35b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/182357
Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
Tested-by: Luigi Semenzato <semenzato@chromium.org>
Commit-Queue: Luigi Semenzato <semenzato@chromium.org>
Reviewed-on: http://review.coreboot.org/6003
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
(Panther clone of Ia41af8425ab6c24746253abd025acd3365dd5a18 by reinauer)
BUG=chrome-os-partner:23563
TEST=emerge-panther chromeos-coreboot-panther
[pg: Drop configs/, which is chromeos stuff, adapted
libpayload's config.panther to work with upstream]
[pm: Add HAVE_IFD_BIN and HAVE_ME_BIN Kconfig options]
[pm: rebase to master branch of coreboot upstream]
[md: don't use FMAP to get MAC address if CONFIG_CHROMEOS not set]
Change-Id: I50fd5c02da154e424dfefbe2020f4ce7ef9a4f8f
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://chromium-review.googlesource.com/174555
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Mohammed Habibulla <moch@chromium.org>
Tested-by: Mohammed Habibulla <moch@chromium.org>
Reviewed-on: http://review.coreboot.org/5990
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Setting of `controller->reg_base` is of no use here, as it is never read
(in another function) later. Looks like this pattern originated from uhci.c
where it makes sense.
By removing the indirection through `reg_base` we also fix a possible
truncation to u32.
Change-Id: I5c99c5bf1f5b1d6c04bd84d87fd3e275fd7d0411
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6251
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Fix a possible null-pointer dereference (hopefully) before anyone runs
into this. Also don't switch ports to xHCI if initialization failed.
Change-Id: I5dbaeb435a98ead0b50d27fde13c9f1433ea3e81
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6245
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
As the controller structure is never fully cleared, this one wasn't
initialized for non-pci controllers (but checked for non-null later).
Change-Id: I852671c5f55650bdb6cd97f4ec74b1f95ee894c7
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6246
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Using void* for physical addresses leads to much casting and confuses
developers when to convert from physical to virtual addresses or
the other way around. When using plain integers for physical addresses
and pointers for virtual addresses things become much cleaner and we
won't ever end up dereferencing a physical address.
Change-Id: I24cd53b81c7863b6d14f0cbb4ce8937728b37c1c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6244
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Like done in FILO, libpayload's console drivers might be initialized
before a relocation. So keep physical pointers in there which won't
break on relocation.
Change-Id: I52e5d9d26801a53fd6a5f3c7ee03f61d6941d736
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6247
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Remove a redundant phys_to_virt() that sneaked in the initialization of
PCI xHCI controllers. The use of casts from void* to u32 (and vice versa)
prompts for things going wrong here. That will be addressed in a later
commit.
Change-Id: Ibc71ed6ee7016529c0e3a51559aaec07aaaba315
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/6243
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
With coreboot builds with serial console disabled, there is no
CB_TAG_SERIAL entry in coreboot tables. We ended up with
lib_sysinfo.serial == NULL and serial_hardware_is_present == 1.
Change-Id: I9a2fc0b55bf77769f2f2bfbb2b5476bee8083f7d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/5723
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Alignment-agnostic encode/decode bytestream to/from little/big endian.
The le16enc(), le16dec(), le32enc(), le32dec() functions encode and
decode integers to/from byte strings on any alignment in big/little
endian format. See BYTEORDER(9).
Change-Id: I73a174b9c02c467bc60590c5cd894dac58b8683a
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5198
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Decompartmentalise AHCI driver into two parts, ATA and ATAPI. Add a few
superficial comments while here. This also fixes a compiler warning.
Change-Id: Ia1fd545b39868a81cbc311f6ffc786f9f1f61415
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/4783
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Pull the ACPI GNVS pointer from CBMEM and expose it in
the sysinfo structure for use by payloads.
BUG=chrome-os-partner:24380
BRANCH=none
TEST=build and boot rambi with emmc in ACPI mode
Change-Id: I47c358f33c464a4a01080268fb553705218c940c
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/179900
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/5016
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Rambi currently has more than 16 memory ranges. Because of
this libpayload is silently dropping them and the full amount
of memory is not being properly wiped. Correct this by bumping
the number of ranges to 32.
BUG=None
BRANCH=None
TEST=Built and booted rambi. Noted that the full amount of memory
was being properly wiped.
Change-Id: Ida456decf2498cb1547c0ceef23df446a975606b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/175792
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4942
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
This reverts commit 1287d1cc80.
This commit has the side-effect of making abuild fail, and as such is
reverted until a safe solution can be found.
Change-Id: Ib8cb78468c2922322b490e0b52c0bd24f3de7ef9
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/3269
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
If xcompile can't find out suitable GCC compiler for i386/armv7, it
will not set $CC_i386/$CC_armv7 variable. Makefile sets $CC variable
from xcompile, and will print strange error messages when executing
$CC program if $CC is empty.
Add checking to avoid this problem. If $CC is empty, also delete
invalid .xcompile file, so Make can recreate this file next time.
Change-Id: Ia8d481d76ca52f3351cb99f05779d06947161c5d
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3905
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Without it payloads that need curses fail to build.
Change-Id: I4533238b547e4c2d9e0778fb7d314db35a9559df
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4689
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
It resulted in garbage in upper bytes of numeric options.
Change-Id: I5e5d8b770ed93c7e8a1756a5ce32444b6a045bac
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/4691
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Code is using it...
Change-Id: I6894b45cbbf70c8e7ce37ce18d93cadf0ea9fbfc
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4649
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
It builds all defconfigs/* and logs the results
in junit.xml, suitable for consumption by jenkins
Change-Id: I86c4022851b47820c95359b2ea9b735a77b1bc2c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4551
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Just clean out stuff we don't even have anymore
Change-Id: I2b4128c6496b4400d52d87680bedc3cece3d444c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4550
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
being a good citizen on the box, libpayload tries to return to EHCI
mode on shutdown, so a non-XHCI capable USB driver after it (eg. in
the OS) finds something to work with.
Change-Id: Id227d646e08a258b841c644263112f0815dd486c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4547
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds inline wrappers to read the L2 cache auxiliary control
register (L2ACTLR).
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: Iec603d7c738426232f7ce3a4a474d01c85fa3f2f
Reviewed-on: https://gerrit.chromium.org/gerrit/64861
Commit-Queue: David Hendricks <dhendrix@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/4437
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The cache.h header uses standard int types but doesn't include stdint.h itself.
Change-Id: If470978164b0cd1f05c27c2c8eda365133cc47ff
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63190
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4387
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Add a function to disable and clear the keyboard controller.
Verified Code flow in normal boot/S3 resume with print statements.
Verified Keyboard was correctly disabled and flushed by booting
to recovery mode screen while pressing keys on the integrated
keyboard.
Change-Id: I3e1f011c3436fee5ce10993c6c26a3c8597c6fca
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63627
Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Shawn Nematbakhsh <shawnn@chromium.org>
Commit-Queue: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/4395
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The hexdump function was added to libpayload recently, but its source file was
never added to the Makefile so it wasn't compiled or linked in.
Change-Id: Ic3c12a5b8a6ea631b83c10a6e4210544ff00b5bf
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64878
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4439
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The EHCI driver defines a maximum transfer timeout of two seconds. The
comments state that during tests the maximum amount of required transfer
time was for the SCSI TEST_UNIT_READY command on certain devices. We
have now observed a USB device (Patriot Memory 13fe:3100) that can NAK
this command for slightly more than two seconds. It will also completely
fail if the timeout hits, since it gets confused by the subsequent CSW
retry/recovery mechanism and starts producing babble errors. This patch
increases the timeout to three seconds to circumvent this problem.
To test, boot a Falco from a red-black RageXT USB stick.
Change-Id: I3c4fef468fb16eacc5a487d76d025a78fb450e27
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/63095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
Reviewed-on: http://review.coreboot.org/4379
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
- prints hex and ascii
- detects duplicate all zero lines
Change-Id: I084b3072bc05725b23c5c3ca0dbf1533f164a08c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/63660
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Author: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/4393
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The ram_media.c file is being compiled, however the
global functions were not exposed through a header.
Change-Id: I4588fbe320c29051566cef277bf4d20a83abf853
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/56642
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4194
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I7252925ef5c4efb69cad6b6fa179031162cf8e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/61058
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4346
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When dealing with DMA, we need a function to invalidate cache without corrupting
contents on main memory (clean).
Change-Id: I28e632ae57a7b7ed1accee74e76045b92f92a699
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61078
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4345
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The OP assigned by dcache_clean_by_mva must be handled in
dcache_op_mva.
Change-Id: Ib32262f0419453b2690d7c1a1c6602380b46a37f
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/61077
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4344
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
So far this is used by the USB driver, and instead of
having ifdefs all throughout that code, implement the same
API on x86 and ARM.
Change-Id: I8093ad818ad2e38a0901787aa8674faf591d580c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56105
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4320
Tested-by: build bot (Jenkins)
- Add -ffreestanding and -fomit-frame-pointer for all
platforms.
- Add ARMv7 specific flags to the armv7 Makefile
Change-Id: I71ab1b096e505940cc20c266bccd43917bcfad3a
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56104
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4317
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
On ARMv7 we need to carefully add memory barriers to
all memory read and write operations. This change
brings libpayload in sync with what coreboot is doing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ie9c30b0f0d30531c5f9d99c2729246a86b8cec26
Reviewed-on: https://gerrit.chromium.org/gerrit/59294
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4316
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This was used by Ron 13ys ago and was never used again
ever since.
Change-Id: I8ae8a570d67fa0b34b17c9e3709845687f73c724
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59320
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4256
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Currently, the exception handling code on ARM in libpayload turns on alignment
checks as an easy way to generate an exception for testing purposes. It was
leaving it on which disabled unaligned accesses for other, unlreated code
running later. This change adjusts the code so the original value of the
alignment bit is restored after the test exception.
Built and booted into depthcharge on pit with an unaligned accesses added
after the call to exception_init in the depthcharge's main. Before this
change, the access caused an exception. After this change, the access
completed successfully.
Change-Id: If92cab3cc8eabca7c5b0560ce88a8796a27fe3b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59372
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4255
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
The address range to scan for the coreboot tables varies from machine to
machine based on the range memory occupies on the SOC being booted and on the
amount of memory installed on the machine. To make libpayload work on
different ARM systems with different needs, this change makes the region to
scan configurable. In the future, we might want to come up with a more
automatic mechanism like on x86, although there's less consistency on ARM as
far as what ranges are even memory in the first place.
Change-Id: Ib50efe25a6152171b0fbd0e324dbc5e89c527d6e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/59242
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4254
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
Otherwise the code would try to parse GPIOs when encountering
a mainboard entry in the coreboot table. This never caused any
problems because the mainboard entry is parsed before the GPIO
entry.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1443bda8585a990a39115743d48304ec4b54bccb
Reviewed-on: https://gerrit.chromium.org/gerrit/59292
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4252
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
This was never completed / working and we have the working
ARMv7 port for an architecture template, so get rid of this
dead code.
Change-Id: Ic2c1267ee5546dd6e1b63220c263b2fa86c8ae33
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56065
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4235
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Mass storage devices such as card readers show up as
as USB devices. However the media not be inserted. In those
situations the previous code would just fake a disk and
call usbcreate_disk. This is inappropriate because it forms
a 1:1 mapping of USB device to disk leading to the inability
to remove the disk and/or handle "hot plug" card insertion
and removals.
To alleviate this issue introduce the notion of ready to the
usbmsc structure. It tracks detached, not ready, and ready
states. The polling routine is then used to track not ready
to ready transitions thereby creating and removing disks
appropriately. This handles the case of inserting and removing
a card that shows up as a new disk.
Booted recovery mode. Able to observe inerstion and removal
of sdcard. Also able to insert valid USB flash drive to boot
as well.
Change-Id: I3eefbe537ec1b9c975744b8984b06c17ae236f40
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57948
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4226
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There is currently a hard-coded 30 sec delay in the mass storage
driver while waiting for each device to become ready. However, mass
storage card readers that are empty return an error code on the
TEST UNIT READY command. A REQUEST SENSE command then needs to be
issued and interrogate the data to determine if no media is present.
If no media determination is found to be true the USB device is no
longer considered a candidate to be a disk.
This code does lead to the fact that the media card reader needs to be
populated at enumeration time. I suspect this is not an issue as it
appears the storage stack in libpayload can't handle removable media
coming online later.
Booted recovery and dev modes. Noted that removable mass storage
devices with no media were ignored without any boot delay.
Change-Id: Ida7a45614d97c6e6fbfc9bb099765aad4df550fd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/57828
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/4225
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The architecture name for our ARM port is armv7, not arm.
Hence, none of those flags were ever actually used.
Fix the architecture name and remove the flags, they should
not be set in xcompile, but in the Makefile, like in coreboot.
Change-Id: Id9c5db7ebceafddb58a1ce1988417f09c074ba6c
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56084
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/4179
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Restructure USB stack to not depend on PCI, and
make PCI stub available on x86, but provide fixed
BARs for ARM (Exynos 5)
Change-Id: Iee7c8b134c22b661a9a515e24943470c9dbadd1f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/49970
Reviewed-on: http://review.coreboot.org/4175
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Two structures in the USB EHCI stack were pointing
to hardware but not marked attribute((packed)) hence
leaving it to GCC to correctly align the data structures.
Next, the number of reserved bytes in hc_op_t was wrong
(but implicitly aligned to the correct values on x86)
It seems this worked fine on x86, but on ARM it was doing
the wrong thing.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I94bed4850ded7d3f7bbc7ff3079c103c6054c22d
Reviewed-on: https://gerrit.chromium.org/gerrit/55555
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4174
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In the process of getting rid of compiler includes during in coreboot
and libpayload, we defined size_t and ssize_t ourselves, using a GCC
macro for size_t: __SIZE_TYPE__. Unfortunately, there is no
__SSIZE_TYPE__, so we temporarily redefine unsigned to signed to make
__SIZE_TYPE__ __SSIZE_TYPE__.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I4cf4eb0fdaa4db64277c2585fe2c1bdc0acdf02b
Reviewed-on: https://gerrit.chromium.org/gerrit/49947
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4156
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I3235f42c7faaf28a63455162ea55dc1a6bebd1f5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-by: Hung-Te Lin <hungte@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48290
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4128
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This imports the cache/MMU code from coreboot as of 1877cee.
Change-Id: I97ec8b9640921a94a4b27d89e4ae6185e9f96f18
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/48288
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/4134
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Not all platforms !x86 are big endian, hence actually look
at the CONFIG_LITTLE_ENDIAN flag instead of CONFIG_ARCH_X86.
Change-Id: Ibbd8f48b377a1121dd1e045834a94a2d67eda2ab
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/56066
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/4236
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It is for crossgcc.
Change-Id: Ia1d676adfea340b6b80858215459491c9338d614
Signed-off-by: Andrew Wu <arw@dmp.com.tw>
Reviewed-on: http://review.coreboot.org/3955
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
On Intel's Panther Point the xHCI ports are shared with an EHCI
controller. Our xHCI driver switches them to xHCI, naturally. But
we forgot to switch them back on shutdown, which left them
unusable by a non-xHCI aware operating system.
Change-Id: I70ef08655a603b42ee939935d50cf77ea97878a3
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3791
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
keyboard_init attempts to read the existing mode register, set the
'XLATE' bit, and write it back. The implementation is buggy because the
keyboard may be active at the time we read the mode, and we can
misinterpret scancode data as the reply to our command. It leads to
problems where the KB gets disabled in firmware.
In fact, setting the 'XLATE' bit is completely unnecessary, even if we
desire QEMU keyboard support. We already set this bit when we initialize
the keyboard in pc_keyboard_init. Basically, this code does nothing
(or worse), so just remove it.
Change-Id: Iab23f03fa8bced74842c33a7d263de5f449bb983
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: http://review.coreboot.org/3883
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For libpayload clients with larger memory needs (eg. FILO with integrated
flashrom) the current configuration isn't enough.
Change-Id: Ic82d6477c53da62a1325400f2e596d7d557d5d1e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3889
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Change-Id: Ie69ceb343494b7dd309847b7d606cb47925f68b6
Reviewed-on: http://review.coreboot.org/3888
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Prettier in real-world payloads (ie. FILO)
Change-Id: I9ed968fe527c5d46090e707e2d89b7406a43662e
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3887
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
flashrom has started to use revision IDs to distinguish AMD chipsets
and fails (even more) to build with libpayload since then because
PCI_REVISION_ID is undefined in libpayload's pci header.
Change-Id: If7440a48c1005a4ba4fc09303f47cdfa9f408ad1
Signed-off-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-on: http://review.coreboot.org/3884
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
For reasons explained in a previous CL, it might be necessary to "load" a file
from CBFS in place. The loading code in CBFS was, however, zeroing the area of
memory the stage was about to be loaded into. When the CBFS data is located
elsewhere this works fine, but when it isn't you end up clobbering the data
you're trying to load. Also, there's no reason to zero memory we're about to
load something into or have just loaded something into. This change makes it
so that we only zero out the portion of the memory between what was
loaded/decompressed and the final size of the stage in memory.
Change-Id: If34df16bd74b2969583e11ef6a26eb4065842f57
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3579
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Instead of returning 0 on success and -1 on error, return the decompressed
size of the data on success and 0 on error. The decompressed size is useful
information to have that was being thrown away in that function.
Change-Id: If787201aa61456b1e47feaf3a0071c753fa299a3
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3578
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The memset and memcpy functions are assembled as ARM code, likely because
that's the default of the assembler. Without special annotation, the assembler
and linker don't know that those symbols are functions which need special
handling so that ARM/thumb issues are handled properly. This change adds that
annotation which gets those functions working in Coreboot which is compiled as
thumb. Libpayload and depthcharge are compiled as ARM so they don't *need* the
annotation since it just works out in ARM mode, but it's the safe thing to do
in case we change that in the future.
We should explicitly select ARM vs. thumb when assembling assembly files to be
consistent across builds and toolchains.
Change-Id: I814b137064cf46ae9e2744ff6c223b695dc1ef01
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3672
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The counted delay of 1ms was shorter than the time usb_poll() took
(~30ms observed). So with a given timeout of 100ms it actually took 3s.
We can lower the problem if we delay 10ms per loop iteration.
Change-Id: I6e084bdd05332111cc8adcd13493a5dfb4bc8b28
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3533
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Teach lpgcc to look in the in-coreboot tree directory structure, too.
Change-Id: I3809456d072ce2f91542b0edb3fd39f536298cc2
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3530
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
We can't read the drives signature before it's ready, i.e. spun up.
So set the timeout to the standard 30s. Also put a notice on the
console, so the user knows why the signature reading failed.
Change-Id: I2148258f9b0eb950b71544dafd95776ae70afac8
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3493
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A timeout while waiting for a device' signature has shown that our
error path wasn't correct. The shutdown of the ports command engine
always timed out. Fix that by waiting for FR (FIS Receive Running)
to be cleared independently from CR (Command List Running) and after
clearing FRE (FIS Receive Enable).
Change-Id: I50edf426ef0241424456f1489a7fc86a2cfc5753
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3494
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Well, it turned out to be more as some gaps ;)
but we finally have xHCI running. It's well tested against a QM77 Ivy
Bridge board.
We have no SuperSpeed support (yet). On Ivy Bridge, SuperSpeed is not
advertised and USB 3 devices will just work at HighSpeed.
There are still some bit fields in xhci_private.h, so this might need
little more work to run on ARM.
Change-Id: I7a2cb3f226d24573659142565db38b13acdc218c
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3452
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is mostly a rewrite, don't even try to read a diff.
Tested with an internal rate matching hub on a QM77 board and three hubs
integrated into DELL monitors.
Change-Id: Ib12fa2aa90af4e0f37143d2ed92c4a1705b6d774
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3451
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The current drivers for external usb hubs and root hubs all follow
the same pattern. Before adding another one with 90% of the same code,
extract the common parts and rewrite them with a simple interface.
This also adds debouncing of new attachments. Current drivers just
waited 100ms before they reset the device. However, we should check
if the device becomes disconnected and reconnected during this period.
Porting of the current hub drivers will take place in separate
commits (when I have time to test the older HCIs).
Change-Id: I0c0ce0ac1b1cc51fb4cd009b3f9fcd1b9d2ba8fe
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3450
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Read bInterval from endpoint descriptors and store it in our endpoint_t
struct. The interval is encoded dependently on the device' speed and the
endpoint's type. Therefore, it will be normalized to the binary logarithm
of the number of microframes, i.e.
t = 125us * 2^interval
The interval attribute will be used in the xHCI driver.
Change-Id: I65a8eda6145faf34666800789f0292e640a8141b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3449
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
xHCI requires special treatment of set_address since it determines
the device number itself (instead of the driver, as with the other
controllers). The controller also wants to validate a chosen device
configuration and we need to setup additional structures for the
device and the endpoints.
Therefore, we add three functions to the hci_t structure, namely:
set_address()
finish_device_config()
destroy_device()
Current implementation for the Set Address request moved into
generic_set_address() which is set_address() for the UHCI, OCHI and
EHCI drivers. The latter two are only provided as hooks for the xHCI
driver.
The Set Configuration request is moved after endpoint enumeration.
For all other controller drivers nothing changes, as there is no other
device communication between the lines where the set_configuration()
call moved.
Change-Id: I6127627b9367ef573aa1a1525782bc1304ea350d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Signed-off-by: Patrick Georgi <patrick.georgi@secunet.com>
Reviewed-on: http://review.coreboot.org/3447
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
These values are already used in this usb stack.
Change-Id: If96f1dc2b67fbc13dfc4ae2d84e8f9945aa03163
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3448
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
During device initialization, skip any non-endpoint descriptor before
reading the endpoint descriptors. By now, only HID descriptors were
skipped.
Change-Id: I190f3ae44b864aa71d5f32c3738097cf8f33a61b
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Add the Mobile Panther Point (PPT) AHCI controller (DEVID 0x1e03) to
the list of tested controllers. Also comment the only other listed
controller (Mobile ICH9).
The PPT AHCI controller was tested with a QM77 chipset on a Kontron
KTQM77 board.
Change-Id: Ia396761411f4f9289af11ec8e1b144512b2fc126
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/3361
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes the configuration where serial console output is
being sent to non-existant hardware to be captured with I/O
trapping. In this configuration where there isn't serial
hardware present we still want to init the consoles. We just
never want to read non-existant hardware.
Change-Id: Ic51dc574b9c0df3f6ed071086b0fb2119afedc44
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3249
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The cbfs core code would print out the name of the file it is
searching for and when it is found would print out the name
again. This contributes to a lot of unnecessary messages in a
functioning payload’s output. Change this message to a DEBUG one
so that it will only be printed when CONFIG_DEBUG_CBFS is enabled.
Change-Id: Ib238ff174bedba8eaaad8d1d452721fcac339b1a
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/3208
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The cbfs core code would print out all unmatched file
names when searching for a file. This contributes to a lot
of unnecessary messages in the boot log. Change this
message to a DEBUG one so that it will only be printed when
CONFIG_DEBUG_CBFS is enabled.
Change-Id: I34c747e0d3406351318abf70994dbc0bb3fa6c01
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/3164
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Because pointers can be 32bit or 64bit big,
using them in the coreboot table requires the
OS and the firmware to operate in the same mode
which is not always the case. Hence, use 64bit
for all pointers stored in the coreboot table.
Guess we'll have to fix this up once we port to
the first 128bit machines.
Change-Id: I46fc1dad530e5230986f7aa5740595428ede4f93
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3115
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
The way we got to include the compiler includes was kind of whacky.
Instead of mixing in potentially problematic headers, make libpayload
self-contained by adding some missing header files. Also clean up
conflicting definitions of size_t throughout the tree.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I0ad1194de1a00b7133c5477c00eb167d63a2ee85
Reviewed-on: https://gerrit.chromium.org/gerrit/47608
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/3058
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reading commit »libpayload: New AHCI, ATA and ATAPI drivers«
(1f6bd94f) [1], the spelling error was found and is now fixed.
[1] http://review.coreboot.org/1622
Change-Id: Id418bcb99c1a9a400a49fc04078e465bd0908074
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3071
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This change modifies the code in libpayload that scans the PCI hierarchy for
USB controllers. Previously, if a devices primary function (function 0) was a
bridge, then none of the other functions, if any, would be looked at. If one
of the other functions was a bridge, that wouldn't be handled either. The new
version looks at each function that's present no matter what, and if it
discovers that it's a bridge it scans the other side.
Change-Id: I37f269a4fe505fd32d9594e2daf17ddd78609c15
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2517
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Nico Huber spotted [1], that commit (4d6ab4e2) [1] updating
superiotools’s `README` with the Git command line
superiotool: Update README with Git repository URL and directory location
missed, that after `git clone` one sitll has to change into
the cloned directory.
So prepend the path with `coreboot/` to fix that. The same error
happened in the commit (e1ea5151) for libpayload [2]
libpayload: Update README with Git repository URL and directory location
and is fixed in this patch too.
[1] http://review.coreboot.org/#/c/3019/
[2] http://review.coreboot.org/2228
Change-Id: Ib6e8b678af6276556a40ccfd52ae35ca7e674455
Reported-by: Nico Huber <nico.h@gmx.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/3021
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Building libpayload with the PDCurses backend the following warning
is shown.
/src/coreboot/payloads/libpayload(master) $ make clean
/src/coreboot/payloads/libpayload(master) $ make
[…]
CC curses/pdcurses-backend/pdcscrn.libcurses.o
curses/pdcurses-backend/pdcscrn.c: In function 'PDC_scr_open':
curses/pdcurses-backend/pdcscrn.c:75:5: warning: "CONFIG_SPEAKER" is not defined [-Wundef]
[…]
The GCC documentation states [1]
In some contexts this shortcut is undesirable. The -Wundef option
causes GCC to warn whenever it encounters an identifier which is
not a macro in an ‘#if’.
and therefore use `#ifdef` [2] to silence this warning. No functional
change is done, as `CONFIG_SPEAKER` is assigned the value `Y` when
defined.
There was some discussion going on the list [3], but my points in there
turned out to be incorrect.
[1] http://gcc.gnu.org/onlinedocs/cpp/If.html
[2] http://gcc.gnu.org/onlinedocs/cpp/Ifdef.html
[3] http://www.coreboot.org/pipermail/coreboot/2013-March/075561.html
Change-Id: I8e9c9b5d01985b21ad05018986d614cf9bf2b439
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2934
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
This imports the newest cache and MMU code from coreboot. This
time it's so new that it hasn't even been checked in to coreboot.
However, this version at least allows DMA to work properly for the
MSHC driver. So even if we rebase a few more times, this version is
at least a step in the right direction.
Note: This omits the stuff that sets up dcache policy since
libpayload should not need to worry about that and it depends
on cbmem stuff.
Change-Id: Idd42b083e8019634aaaa44d5bf5b51db6c3912f5
Signed-off-by: David Hendricks <dhendrix@google.com>
Reviewed-on: http://review.coreboot.org/2975
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
This imports the new cache maintenance API from coreboot at
commit bba8090. This is a BSD-licensed implementation which
exposes cache maintenance opertaions necessary for payloads
for things such as DMA transfers.
Change-Id: I554676db89517bebc6edae4f7ab7e5882e6f986d
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/2974
Tested-by: build bot (Jenkins)
On x86, coreboot may allocate a variable range MTRR for enabling caching
of the system ROM. Add the ability to parse this structure and add the
result to the sysinfo structure.
An example usage implementation would be to obtain the variable MTRR
index that covers the ROM from the sysinfo structure. Then one would
disable caching and change the MTRR type from uncacheable to
write-protect and enable caching. The opposite sequence is required
to tearn down the caching.
Change-Id: I3bfe2028d8574d3adb1d85292abf8f1372cf97fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2920
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes the following PDCurses warnings:
CC curses/pdcurses-backend/pdcsetsc.libcurses.o
curses/pdcurses-backend/pdcsetsc.c: In function 'PDC_curs_set':
curses/pdcurses-backend/pdcsetsc.c:17:9: warning: implicit declaration of function 'serial_cursor_enable' [-Wimplicit-function-declaration]
curses/pdcurses-backend/pdcsetsc.c:22:9: warning: implicit declaration of function 'video_console_cursor_enable' [-Wimplicit-function-declaration]
CC curses/pdcurses-backend/pdcutil.libcurses.o
curses/pdcurses-backend/pdcutil.c:30:6: warning: no previous prototype for 'curses_enable_serial' [-Wmissing-prototypes]
curses/pdcurses-backend/pdcutil.c:35:6: warning: no previous prototype for 'curses_enable_vga' [-Wmissing-prototypes]
curses/pdcurses-backend/pdcutil.c:40:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
curses/pdcurses-backend/pdcutil.c:45:5: warning: function declaration isn't a prototype [-Wstrict-prototypes]
Change-Id: If0d4d475d3006f1a77f67ec46c6bdf4ee2906981
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2908
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There were a number of type issues in libpayload that sneaked in
with 903f8e0.
- size_t and ssize_t were conflicting with gcc builtins
- some stdint types were used in libpayload but not defined
in our stdint.h
With this patch it's possible to compile libpayload with the
reference toolchain again.
Change-Id: Idd5ccfdd9f3536b36bceca2d101e7405883b10bc
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2903
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
libcbfs was using printf for size_t typed variables. However, printf
did not support printing those. This patch fixes the issue, removing
the warning when compiling ram_media.c
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 2 has type 'long unsigned int' [-Wformat]
libcbfs/ram_media.c:52:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat]
Change-Id: Iaf6e723f9a5b0a61a39d3125036fee9853e37ba8
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2904
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The keyname() and termname() functions were creating a whole lot of warnings of
the style
curses/PDCurses-3.4/pdcurses/keyname.c:41:9: warning: initialization discards 'const' qualifier from pointer target type [enabled by default]
This patch fixes them.
Change-Id: Iae3c4e5201b48c2d2033cac48577e0462a34f309
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2905
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
PDCurses has a function called overlay() and also uses
overlay as a variable name in some functions.
This patch fixes the ambiguity that caused warnings like
curses/PDCurses-3.4/pdcurses/overlay.c: In function '_copy_win':
curses/PDCurses-3.4/pdcurses/overlay.c:51:39: warning: declaration of 'overlay' shadows a global declaration [-Wshadow]
In file included from curses/PDCurses-3.4/curspriv.h:16:0,
from curses/PDCurses-3.4/pdcurses/overlay.c:3:
curses/PDCurses-3.4/curses.h:1014:9: warning: shadowed declaration is here [-Wshadow]
Change-Id: I907653df0c8bb32c98bdcbc6476e94d2da6e0e90
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2906
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Xinitscr is only used internally in PDCurses, unless XCURSES
is defined. This patch fixes a warning that is produced because
of that.
Change-Id: I211f75717276cf028e0b435f328d1687d3536eb7
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2907
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The function dump_qh() was added a while back but never used.
Hide it behind USB_DEBUG so it doesn't cause warnings when not
debugging the USB stack.
Change-Id: Idb3c7bb214895ef82676d181836a578bf161e8e0
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2909
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martin.roth@se-eng.com>
PDcurses is already default. Hence drop the additional attempt
that is not supported by Kconfig.
Config.in:123:warning: defaults for choice values not supported
Change-Id: I12cb5ea0bef2f146cf237c7a3cc9293a600d736b
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2902
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The controller's shutdown function free()s the controller structure so
we shouldn't access it any more after calling shutdown.
As all controllers detach themself, i.e. unchain themself from usb_hcs,
just keep iterating over usb_hcs until it's NULL.
Change-Id: Ie85caba0f685494c3fe04c550a5a14bc4158a94e
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/2900
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
It shouldn't be used any more as we're about to free() the memory behind
the controller -- therefore detach it.
Change-Id: I875322a9940570c51d412a7f3bfb6af4ea3b3764
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Reviewed-on: http://review.coreboot.org/2899
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After another incident related to virtual pointers in lib_sysinfo (and
resulting confusion), I decided to put some comments on the matter into
the code.
Remember, we decided to always use virtual pointers in lib_sysinfo, but
it's not always obvious from the code, that they are.
See also:
425973c libpayload: Always use virtual pointers in struct sysinfo_t
593f577 libpayload: Fix use of virtual pointers in sysinfo
Change-Id: I886c3b1d182cba07f1aab1667e702e2868ad4b68
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: http://review.coreboot.org/2878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a test case for using CBFS images that reside in RAM
and a Makefile to run it (and maybe other tests in the future).
The test concerns an issue in libcbfs when using x86 style CBFS
images in non-canonical locations (eg. when loading CBFS images
for processing).
Use with "make run" inside the tests directory.
Change-Id: I1af3792a1451728ff9594ba7f0410027cdecb59d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2623
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change "ERROR" to "WARNING" -- not finding the indicated file is usually
not a fatal error.
Change-Id: I0600964360ee27484c393125823e833f29aaa7e7
Signed-off-by: Shawn Nematbakhsh <shawnn@google.com>
Reviewed-on: http://review.coreboot.org/2833
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The template had a dependency on config.h which was correct for coreboot,
where this build system originally came from, but not for libpayload which
uses the differently named libpayload-config.h, presumably to avoid colliding
with a config.h used by the actual payload. Because libpayload-config.h is now
effectively a dependency of everything, it doesn't have to be added piecemeal
in Makefile.inc.
Change-Id: I01f20d363cb1393fa1cdcf0dc916670db90294e9
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2763
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
And include the new, split out version in drivers/keyboard.c and
drivers/usb/usbhid.c. Those files were including curses.h just for those
definitions, but the include path was only fixed up to to point to the
libpayload versions of those files if one of the variants of curses was
compiled in. If neither was, gcc would fall back to the system version of that
header which is wrong.
Change-Id: I8c2ee0baf5f0702bd8c713c8dd4613a4bb269ce5
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2762
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The vboot_handoff structure needs to be parsed from the coreboot tables.
Add a placeholder in sysinfo as well as the ability to parse the
coreboot table entry concering the vboot_handoff structure.
Built with unified boot loader and ebuild changes. Can find and use
the VbInitParams for doing kernel selection.
Change-Id: If40a863b4a445fa5f7814325add03355fd0ac647
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/2720
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In their current macro form, any arguments that are expressions will be
evaluated multiple times. That can cause problems if they have side effects,
and might not even compile if the overall expression is ambiguous, for
instance if you pass in foo++.
Built with code that previously wouldn't compile because the macros
expanded to ambiguous expressions.
Change-Id: I378c04d7aff5b4ad40581930ce90e49ba7df1d3e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2719
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The timekeeping code in libpayload was dependent on rdtsc, and when it was
split up by arch, that code was duplicated even though it was mostly the same.
This change factors out actually reading the count from the timer and the
speed of the timer and puts the definitions of ndelay, udelay, mdelay and
delay into generic code. Then, in x86, the timer_hz and timer_get_raw_value
functions which used to be in depthcharge were moved over to libpayload's
arch/x86/timer.c. In ARM where there isn't a single, canonical timer, those
functions are omitted with the intention that they'll be implemented by a
specific timer driver chosen elsewhere.
Change-Id: I9c919bed712ace941f417c1d58679d667b2d8269
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2717
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This function is static and not used in that file. To avoid the compiler
complaining about that fact, put the two functions and the call to dump_ed
(currently #if 0) behind #ifdef USB_DEBUG
Change-Id: Ic373313b5fff81f09800f286b32238350ab699c6
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2716
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
'for' loop initial declarations are only allowed in C99 mode
I didn't realize we don't enable 14 year old features when building
libpayload, and I must have accidentally not rebuilt everything when making my
final tweaks to my earlier change.
Change-Id: I6caeeffad177b6d61fa30175f767e85084c061f4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2718
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Use memcpy to access a uint32_t that's inherently unaligned due to the layout
of the LZMA header format.
Built and booted on Daisy and saw a data abort go away. Built and booted
into developer mode on Link and verified that bitmaps were
decompressed/displayed correctly.
Change-Id: Id3ae746c04d23bcb0345cb71797bfa219479cc8f
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2670
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Some new TPM drivers in depthcharge require that type. I added it to
arch/types.h which seemed appropriate, but I'm not sure that's exactly the
right header to use, or in other words if you'd get that type from libpayload
the same way you'd get it if you were building a standard Linux program.
Also, I attempted to determine what underlying types gcc would use, and while
I think I picked the right ones I'm not 100% certain of that either.
Change-Id: Ic5c0b4173c8565ede3bfce8870976d596d69e51d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2669
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Don't keep using the coreboot stack on ARMv7.
Change-Id: I734c5d77f8584e30ee0c720d41e21e3040f56db4
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2668
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: Ia85a7cd6a0b85119cce6b2f9c42a7fc31ffd9f97
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2654
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
It might be useful to provide a USB driver in the payload itself instead of in
libpayload. For example there are multiple payloads being built and linked
against the same libpayload, and they might not need or even want to have the
same set of drivers installed.
This change adds two new functions, usb_generic_create and usb_generic_remove,
which behave like the usbdisk_create and usbdisk_remove functions which are
defined for USB mass storage devices. If a USB device isn't recognized and
claimed by one of the built in USB class drivers (currently hub, hid, and msc)
and the create function is defined, then it will be called to give the payload
a chance to use the device. Once it's removed, if usb_generic_remove is
defined it will be called, effectively giving the payload notice.
Built and booted depthcharge on Link. Built depthcharge for Daisy. Built
a netbooting payload, called usb_poll() with those functions implemented, and
verified that they were called and that the devices they were told about were
reasonable and the same as what was reported by lsusb in the booted system.
Change-Id: Ief7c0a513b60849fbf2986ef4ae5c9e7825fef16
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2666
Tested-by: build bot (Jenkins)
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
EHCI controllers see transfers as a queue of transfer descriptors
(qTDs), each of which can represent an aligned area of up to 20KB. Each
qTD is processed separately, which means that a single USB packet cannot
span multiple qTDs.
While this should not be a problem according to the specification, some
USB storage devices seem to get confused when a packet in the middle of
a transfer is smaller than the maximum packet size (512 bytes) due to
falling on a qTD boundary. This patch aligns the total transfer length
per qTD to 512 bytes to avoid that problem (any excess bytes will simply
roll over to the next qTD).
Change-Id: I0b5db07507699a3861b30c1a5ee774c45dda7fdd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/2651
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Initialize the high part of the address
and use 64-bit compatible descriptors.
(waste a few bytes on 32-bit but should be harmless)
Read USB stick on a SandyBridge system which has 64-bit EHCI.
Change-Id: I59cc842459acecdde8f8bdd4795ebfeccb842c8f
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2650
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Kimarie Hoot <kimarie.hoot@se-eng.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
These were currently stubbed out for PowerPC but not for ARM.
Change-Id: I08f45174877bf5751d972078b8c53d82898b7f2b
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2655
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I56f810dfa6654ac1e9d1696ad15e7f1b8bfe59bd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2652
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I01b1fa42139af925716cd5d57f96dc24da6df5a7
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2660
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Change-Id: I36c750d520ff034c9ca9b9af46bd99bd49af7355
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2659
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This way we won't have two copies of the hardware init function, and three
copies of the putchar, havechar, and getchar functions.
Change-Id: Ifda7fec5d582244b0e163ee93ffeedeb28ce48da
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2657
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Default it to no to be consistent with the other architecture wide options
(endianness), and turn it on explicitly for x86 and PowerPC.
Change-Id: Idda26d580156bbbf08ea11b28abe75cfa6b594b2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2658
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When building other payloads with lpgcc the -nostdinc flag was injected into
CFLAGS, but when building libpayload itself some headers were being used from
the host system. This change puts -nostdinc into the Makefile and xcompile
script, fixes up one include path in include/inttypes.h, adds the compiler
provided include directory to the include search path, and deletes the two now
redundant stdint.h files.
BUG=None
TEST=With this and other changes, built libpayload and depthcharge for Daisy,
Link, and Fox.
BRANCH=None
Change-Id: Ia7817fceab5297cd82ccc0d392330de0df61980e
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2710
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There weren't enough parenthesis in the macros so operations might only apply
to the last part of an expression passed in as an argument.
Change-Id: I5afb406f9409986e45bbbc598bcbd0dd8507ed35
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2665
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I9a16331dedc97f17af94bf2cf535a9c93d1729a0
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2667
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The functions in endian.h (betoh{l,w,ll} and others) were named differently from
the well-known BSD/glibc style endian functions (ex, betoh{16,32,64}). We should
provide the BSD/glibc style functions to prevent confusion.
Change-Id: Ia3bee481ba7989ac25b79ddb89bc6819d52fd8c3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2705
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The functions defined in that header aren't used anywhere in the actual code,
and that include breaks things on ARM.
Built for ARM with COREBOOT_VIDEO_CONSOLE turned on and saw compiler
errors go away.
Change-Id: I56d6fe5e00c8fccda6e31ef8752326bd36398e74
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2656
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
That way when it's treated as a u32 when its value is extracted for numblocks
and blocksize below, it doesn't make the compiler unhappy, and it ensures that
the buffer will be properly aligned on architectures where that sort of thing
matters.
Built and saw warnings about type punning go away.
Change-Id: I254e0b5e70847112d660675b7df0ac9cb52e4051
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2653
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Three issues:
1. the hardcoded dereferenced pointer at 0xfffffffc
2. "RAM media" has no idea about ROM relative addresses
3. off-by-one in RAM media: it's legal to request 4 bytes from 0xfffffffc
Change-Id: I671ac12d412c71dc8e8e6114f2ea13f58dd99c1d
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2624
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Things work better with it turned on, and the overhead should be negligable.
Built and booted into depthcharge on Snow. Verified that calling between
various bits of thumb and ARM code worked correctly.
Change-Id: I08d1006e113d2cca08634bf19240aca138a449d9
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2567
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Give some indication what happened instead of just crashing.
As part of setup, cause an exception and make sure that we get
the right one, and that we recover correctly. Hence we have
some assurance that if they really happen we can handle them.
Built and booted into test payload on Snow. Saw the built in test function
worked correctly. Artificially added code which got an exception and saw that
the error information prints correctly.
Change-Id: I2e0d022f090ee422fb988074fbb197afa2485caa
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2569
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The linker uses that info so interworking can work correctly.
Built and booted into depthcharge on Snow and saw interworking start to
work correctly.
Change-Id: I0ac54f1c424ec70f8244edf6541a10b089ce47b4
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2568
Tested-by: build bot (Jenkins)
In the file `COPYING` in the coreboot repository and upstream [1]
just one space is used.
The following command was used to convert all files.
$ git grep -l 'MA 02' | xargs sed -i 's/MA 02/MA 02/'
[1] http://www.gnu.org/licenses/gpl-2.0.txt
Change-Id: Ic956dab2820a9e2ccb7841cab66966ba168f305f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/2490
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This function was using mdelay in a loop to check for the completion of an USB
controller operation. Since we're busy waiting anyway, we might as well wait
only 1 us before checking again and potentially seeing the completion 999 us
earlier than we would otherwise.
Change-Id: I177b303c5503a0078c608d5f945c395691d4bd8a
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2522
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
This is so the user of libpayload can attach data to the device which it can
retrieve when the device is referred to later, for instance in usbdisk_remove.
Otherwise, there's no direct connection from the usbdev_t structure to any
bookkeeping in the host firmware.
Change-Id: I36fe693b0dcd2098e359c26744e376e73bd3a723
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2513
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When checking to see if a PCI device exists at a particular bus/dev/func,
libpayload was checking the vendor and device id fields together against a 16
bit 0xffff. The two fields together are 32 bits, however, so the check was
never true, and all dev/func combinations on a particular bus would be
checked. That was slightly wasteful, but had relatively small impact.
Change-Id: Iad537295c33083243940b18e7a99af92857e1ef2
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2521
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The interval used to be about 55 ms which is excessively long. Coreboot only
waits for 2 ms and gets a reasonable answer. That should be good enough for us
as well.
Change-Id: I4d4e8b25b6ba540c9e9839ed0bbaa1f04f67cce1
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: http://review.coreboot.org/2520
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Cherry-picking CBFS fix from http://review.coreboot.org/#/c/2292/
For x86, the old CBFS search behavior was to bypass bootblock and we should keep
that. This will speed up searching if a file does not exist in CBFS.
For arm, the size in header is correct now so we can remove the hack by
CONFIG_ROM_SIZE.
Change-Id: I286ecda73bd781550e03b0b817ed3fb567d6b8d7
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2458
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Not only were these files checked in with the Chromium OS Authors
copyright, but in addition they were wrongly licensed as GPL.
Switch to 3-clause BSD (and, since we're changing it, fix copyright,
too)
Change-Id: I3656c1f4304d53e343d89bb7c909fd4b929249f4
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2456
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
get_cbfs_header expects CBFS_HEADER_INVALID_ADDRESS (0xffffffff)
instead of NULL when something is wrong.
Also, fix typo.
Change-Id: Ibe56c9eab3b9fdfc6d0b14bc848ca75f3a4fc2f1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2455
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
Create a new serial console variable, X86_SERIAL_CONSOLE
which is only enabled when SERIAL_CONSOLE and ARCH_X86 are defined.
Builds for x86 and ARM.
Change-Id: I607253c418de015975a839e3c33577842885ec0c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2412
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The compiler gets mad when the types are equivalent size but not necessarily
interchangeable because of strict aliasing checks. Since uint32_t is likely to
be used when trying to read 32 bit data, it makes sense for them to be the
compatible.
Signed-off-by: Gabe Black <gabeblack@google.com>
Change-Id: If73d794866055dc026fc06d6268e692adac0f835
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2411
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
lpgcc was unconditionally setting -m32.
Most of the flags it sets in the common case are right, however: no need
to duplicate them everywhere, and we only want to change the common ones
in one place, so it would be a shame to duplicate _CFLAGS all over the place.
So add another variable, _ARCHEXTRA, which can be used to add
special flags to _CFLAGS. We onlu use it at present for the x86; this may
change.
This allows us to get through compiling on arm and x86.
Change-Id: I12f1620982c4ee10f76b3953e4225f13db31531e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2399
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Get rid of the nest of includes, and make separate sections
for each architecture. Also gets rid of the "there's X86 and there's
everything else" structure of this file.
Change-Id: I4232f50f048fa05e911e5de3aa9ec1530931b461
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2397
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
The default_ functions in memory.c are only used to initialize a weak
variable. They should not be used outside memory.c. Make them
invisible.
Remove the declaration from libpayload.h. For real this time.
Change-Id: Id54c1fd172c78748f01a958ce4065dd0eb53bbc3
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2394
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
These live at the bottom of memory on x86, but that's IO mapped on the exynos.
The particular range used will likely need to be configurable, but this will
make it work in one more case than it used to.
Change-Id: I4d4963b9732cf538d00f8effb4398f30cbbde6aa
Signed-off-by: Gabe Black <gabeblack@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2410
Tested-by: build bot (Jenkins)
Reviewed-by: Gabe Black <gabeblack@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
I think this needs to be its own ldscript. I'm pretty sure this one
is going to need some work however. Is libpayload PIC? That would be
best if so.
Change-Id: I44578d70dfa72de527af8901a86583c2a60130ec
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2398
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: build bot (Jenkins)
Since it's utterly architecture-dependent, put it in arch/x86.
Avoid the temptation to make yet another directory with just one
file in it. Fix the makefile to pick up the proper arch-dependent script.
Change-Id: I21ea02551a97bdcbc38419714f3b38cf8335c178
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2389
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Upgrade CBFS in libpayload to use new media-based implementation from coreboot
( http://review.coreboot.org/#/c/2182/ ).
Old CBFS functions (cbfs_find, cbfs_find_file, get_cbfs_header) are still
supported, although the recommended way is to use new CBFS API.
To migrate your existing x86 payload source:
- Change cbfs_find to cbfs_get_file
- Change cbfs_find_file to cbfs_get_file_content
- Prefix every CBFS call with a CBFS_DEFAULT_MEDIA argument.
Ex, char *jpeg_data = cbfs_find_file("splash.jpg", CBFS_TYPE_BOOTSPLASH);
=> char *jpeg_data = cbfs_get_file_content(
CBFS_DEFAULT_MEDIA, "splash.jpg", CBFS_TYPE_BOOTSPLASH);
The legacy setup_cbfs_from_{ram,flash} is also supported, although the better
equivalent is to make a new media instance:
struct cbfs_media ram_media;
init_cbfs_ram_media(&ram_media, start, size);
char *data = cbfs_get_file_content(&ram_media, "myfile", my_type);
Verified by being successfully linked with filo.
Change-Id: If797bc7e3ba975d7e3be905c59424f7a93b8ce11
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2191
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
The libpaylaod xcompile script path to xgcc should look
for coreboot/util, not libpayload/util.
Change-Id: I565801549cdcdfcf55ecef1b543a982f969f435b
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/2261
Tested-by: build bot (Jenkins)
Reviewed-by: Steven Sherk <steven.sherk@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Improve USB debugging for EHCI by adding dump_qh
and enhacing dump_td to dump all queue chain and information.
Change-Id: Ia8ecf19c6dac085cf9558bdf659a5e74ce332714
Signed-off-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-on: http://review.coreboot.org/2053
Tested-by: build bot (Jenkins)
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.huber@secunet.com>
When overriding the DOTCONFIG variable, make install
will fail in libpayload.
Change-Id: I332be3a4ca2620a32a6f5fbe683e6c71f0d6a9e9
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/2178
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
The 'VERSION' in CBFS header file is confusing and may conflict when being used
in libpayload.
Change-Id: I24cce0cd73540e38d96f222df0a65414b16f6260
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/2098
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
A "far" modifier sneaked into the USB driver, but gcc
doesn't understand it.
Change-Id: I5c67bd55eabce467e1aa107c95c1db2518af7b0e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/2059
Tested-by: build bot (Jenkins)
Reviewed-by: Anton Kochkov <anton.kochkov@gmail.com>
Improved USB debugging for EHCI by enhacing dump_td
to dump all chain information
Change-Id: I8c667b43e09c39ff12aafbd779474efd652bd80f
Signed-off-by: Anton Kochkov <anton.kochkov@gmail.com>
Reviewed-on: http://review.coreboot.org/2054
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.huber@secunet.com>
Patrick Georgi