Since commit 17fec8a0 [1]
drm/i915: Use Graphics Base of Stolen Memory on all gen3+
present in the Linux kernel since version 3.12, 3D does not work
anymore [2].
Comparing the graphics registers, in this case that means output of
`intel_reg_dumper`, the vendor Video BIOS is setting the register
PGTBL_CTL/PGETBL_CTL, only documented in the i965 datasheet [3], to
`0x3ffc0001` on a system with 1 GB of RAM, while native graphics init
sets it to `0x3f800001`.
Currently native graphis init sets the GTT right above the base
address of stolen memory. The Video BIOS sets it below the top of
memory. The Linux Intel driver expects it to be below top of memory, so
do it this way, by setting the address to TOM minus the size of the GTT,
which is hardcoded to 256 KiB.
As `PGETBL_CTL` is zero by default, reading its value in the beginning
is not necessary and is only confusing. Make it clear that the code
calculates the value.
There is still a PTE error reported during boot, but 3D works
with Linux 3.12+ and no user visible problems are shown.
[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=17fec8a08698bcab98788e1e89f5b8e7502ababd
[2] https://bugs.freedesktop.org/show_bug.cgi?id=79038
[3] https://01.org/linuxgraphics/sites/default/files/documentation/965_g35_vol_1_graphics_core_0.pdf
Intel ® 965 Express Chipset Family and
Intel ® G35 Express Chipset Graphics Controller
Programmer’s Reference Manual
Volume 1: Graphics Core
Revision 1.0a
Change-Id: I0a5b04c2c5300f5056cb48075aa5804984bc9948
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-on: http://review.coreboot.org/5927
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
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>
This uses the packet mode of the controller since that allows transfering more
data at a time.
Change-Id: I8329e5f915123cb55464fc28f7df9f9037b0446d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172402
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 4444cd626a55c8c2486cda6ac9cfece4e53dd0d3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6703
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The pins on tegra are controlled by three different units, the pinmux, the
pin group controls, and the GPIO banks. Each of these units controls some
aspect of the pins, and they layer together and interact in interesting ways.
By default, the GPIOs are configured to pass through the special purpose IO
that the pinmux is configured to and so can be ignored unless a GPIO is needed.
The pinmux controls which special purpose signal passes through, along with
pull ups, downs, and whether the output is tristated. The pingroup controls
change the parameters of a group of pins which all have to do with a related
function unit.
The enum which holds constants related to the pinmux is relatively involved
and may not be entirely complete or correct due to slightly inconsistent,
incomplete, or missing documentation related to the pinmux. Considerable
effort has been made to make it as accurate as possible. It includes a
constant which is the index into the pinmux control registers for that pin,
what each of the functions supported by that pin are, and which GPIO it
corresponds to. The GPIO constant is named after the GPIO and is the pinmux
register index for the pin for that GPIO. That way, when you need to turn on
a GPIO, you can use that constant along with the pinmux manipulating functions
to enable its tristate and pull up/down mode in addition to setting up the
GPIO controls.
Also, while in general I prefer not to use macros or the preprocessor when
writing C code, in this case the set of constants in the enums was too large
and cumbersome to manage without them. Since they're being used to construct
a table in a straightforward way, hopefully their negative aspects will be
minimized.
In addition to the low level functions in each driver, the GPIO code also
includes some high level functions to set up input or output GPIOs since that
will probably be a very common thing to want to do.
Old-Change-Id: I48efa58d1b5520c0367043cef76b6d3a7a18530d
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171806
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 5cd9f17fe0196d13c1e10b8cde0f2d3989b5ae1a)
tegra124: Add base address for the pinmux and pingroup registers.
There weren't any constants for the pinmux or pingroup registers in the
address map header.
Old-Change-Id: I52b9042c7506cab0bedd7a734f346cc9fe4ac3fe
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172081
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 79b61016bfd702b0ea5221658305d8bd359f4f62)
Squashed two related commits.
Change-Id: Ifeb6085128bd53f0ef5f82c930eda66a2b59499b
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6702
Tested-by: build bot (Jenkins)
If these aren't set, the rom and ram stages will attempt to load at address
zero which doesn't work.
Change-Id: I0b9b37d6363e6b208248d8a1af6ebee4db602486
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/173540
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 6ac5cea39d423bfcf5bbd53c2cc6228ab89f08b2)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6704
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Trustzone needs to be initialized/disabled both on boot and on wake, so it
needs to be done before ramstage which doesn't run on wake. cpu.c isn't
compiled into romstage and fixing that causes other problems, so the trustzone
functions were split out.
Change-Id: I8fc630237ebec1f02a91600f8baf3d4e9ea66d0e
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169817
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 055ed0e28476123b0bd666109af90baf40aadcee)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6666
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A problem with including the tegra124 directory directly in the include path
is that it makes all headers in that directory first level headers available
everywhere including places that have nothing to do with the SOC, even headers
which were only intended for local use by tegra124 code. This change modifies
things a bit to be more like the way the arch headers are chosen. In the
tegra124 directory, there's an include directory which has an soc subdirectory
in it. That include directory is added to the include path, making it possible
to have headers private to the tegra124. When files specific to whatever tegra
is being built for are needed, you can include <soc/foo.h> and get the version
specific to that particular soc.
Also, the soc.h header file was overhauled to use enums instead of defines, to
consistently name things as far as their prefix (the less cryptic TEGRA instead
of NV_PA) and suffixes like "BASE", and to get rid of values which were
specific to U-Boot which we don't need. Since the only thing in the file were
address constants, I also renamed the file addressmap.h. It would be included
as:
<soc/addressmap.h>
which I think is easy to remember, does what you'd think it does from the
name, and won't conflict with other header files just minding their own
business in some other directory.
Change-Id: I6a1be1ba28417b7103ad8584e6ec5024a7ff4e55
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/172080
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 2c554f58f9ee18e151e824f01c03eb3f0e907858)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6659
Tested-by: build bot (Jenkins)
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)
I just spent half a day (including the time to implement a stack dumper)
to figure out that I am reading from a NULL pointer. A problem this
simple should be more easy to catch. Let's mark the address range below
SRAM as uncached so that the MMU can yell at you right away for being
the bad programmer you are when you access a NULL pointer.
Change-Id: I4a3a13f75bf21b25732be2ecb69d47503eff1b53
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/170112
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
(cherry picked from commit 7316732ea0ccdc0d607bde81dbb38ca9abd29fa9)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6650
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The UART / serial console is put in retention state by kernel during suspend /
resume path, which caused Coreboot not able to print any messages during resume.
Sending values to the padret_uart_opt inside PMU may release UART, but that may
also cause unexpected output when kernel is back. However, it's still very
helpful when we are debugging suspend/resume inside Coreboot.
To get UART message on resume, call wakeup_enable_uart() in boot block or
romstage (before console_init).
Change-Id: Ib5759cb402c6e018d9dba14fad8b61f6a1b1a265
Reviewed-on: https://chromium-review.googlesource.com/170440
Tested-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Commit-Queue: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 547fbbfe2eeb6da4e161f36be2caf8099f9eac9b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6649
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This patch adds support for the DesignWare3 USB 3.0 DRD controller and
PHY to the Exynos5250 and Exynos5420 CPUs. It also adds code to the
Google Snow and Pit boards to turn these controllers on where
applicable.
Change-Id: Idcca627363a69f1d65402e1acb9a62b439f077ff
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/169452
Reviewed-by: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit e9809ae12ef8b8bd6cd61d3f604cb9e4718cf7eb)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6642
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Right now some console specific objects are included
in the bootblock even if CONFIG_BOOTBLOCK_CONSOLE is
disabled while others are not. Make all of them conditional
and also fix a preprocessor misuse in bootblock_simple.c
and a stray (useless) die() in the Exynos wakeup code that
made inclusion of those files necessary.
Change-Id: Ia7f9d17654466f199b0e13afbdc9e14c9706530f
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168772
Reviewed-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit 855da1f07b52898c7edcaffe5baabe9d485bbd83)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6637
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Code cleanup requested in commit 90957f88 -
"mainboard/intel: Add Mohon Peak CRB for Intel's atom c2000"
- Change com2 to COM2 in Kconfig text
- clean up includes of headers
- fix whitespace
Change-Id: I828bc4781ee7de95be5546206c5d6033b75293d9
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6607
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
This matches what was done on baytrail in commit bfca984b -
soc/intel/fsp_baytrail: set up for including irqroute.h twice
irq_helper.h intentionally gets included into irqroute.asl twice - once
for pic mode and once for apic mode. Since people are used to seeing
guard statements on the .h files, add the guards to irqroute.h and add
a comment to irq_helper.h explaining why they aren't there.
Change-Id: I709f9370ce7db1b3ffac2297aeaba5cc670ec20c
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6606
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Use tab between "COREBOOT", and comment.
This fix was requested in 90957f88 -
"mainboard/intel: Add Mohon Peak CRB for Intel's atom c2000"
Change-Id: If9fb6158cca95341ab57db1125e85648b616b72c
Signed-off-by: Martin Roth <martin.roth@se-eng.com>
Reviewed-on: http://review.coreboot.org/6601
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Some of C-states still cause hang. Revert C-states patch.
This reverts commit fe661612d8.
Change-Id: I7534dac5d27b853d7b93947c38bf3742797fdcc2
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6694
Tested-by: build bot (Jenkins)
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
So it's in line with other boards and those addresses are cached for faster
access.
Change-Id: I7794d75ef1e3ceea6b2a4acba01e4af5d1f005f5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6689
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Now battery indicator and lid work.
Change-Id: I2f747a408e331a245d91dd5f9c7ead0729f02a67
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5323
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Current problems:
- Complete lack of EC support (no battery indicator, no temperature, ...)
- No audio support
Change-Id: I25d09629dd82e01fadca2b6c25f72aaf08eafae1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Signed-off-by: Axel Holewa <mono@posteo.de>
Reviewed-on: http://review.coreboot.org/5321
Tested-by: build bot (Jenkins)
Old init was a replay not even meant to have been committed.
This one really computes values and does its job. Tested on
Macbook2,1 (1280x800) and X60 (1024x768).
Change-Id: I61b6946c095fe06e20ae9a0db54696d0568225dd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5320
Reviewed-by: Francis Rowe <info@gluglug.org.uk>
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
fam14_callouts.h should not have the execute bit set.
Change-Id: Iab44d04f2c9669e28d2d5028b0a11e565cc7bb07
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Reviewed-on: http://review.coreboot.org/6675
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested on lenovo X200 in both text and gfx mode.
Change-Id: I273971d0f34ca3529959d4228e9516775459b806
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6682
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Change-Id: I0c2943bb0889552dc384d8efb5226cd6982a4d81
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6663
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
This header has nothing to do with cache-as-ram. Therefore, 'car'
is the wrong term to use. It is about providing a prototype for
*romstage*.
Change-Id: Ibc5bc6f3c38e74d6337c12f246846853ceae4743
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/6661
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The initial commit for tegra124 (396b072) was not updated for the new ARCH settings.
Change-Id: I147bdf289e91031bd0c0a61e6da43e9c1a438f84
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6658
Tested-by: build bot (Jenkins)
Stop polluting first screen of all boards.
Change-Id: I1ab88075722f7f0d63550010e7c645281603c9c3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6548
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
These symbols are not used anywhere in our C code, so
when using GCC's link time optimization feature they
will be dropped even though they're needed by libgcc.
Hence we need to mark them as used so GCC does not stumble
and fall over its own guts.
Change-Id: Ib2e9ea2610b57ab8244d5b699dd56025a4f08a01
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168773
(cherry picked from commit 416ffc880bcf4122b5430fbd9d9547c83886af2f)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6640
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
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>
Paul Menzel