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>
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>
Move SeaBIOS' build directory out of build/
This allows the user to delete build/ in the top dir
and keep the built binary in payloads/external/SeaBIOS/seabios/out/
Change-Id: Ia7d515cd7e349beebcd9b62c9d956137acb73c82
Signed-off-by: Idwer Vollering <vidwer@gmail.com>
Reviewed-on: http://review.coreboot.org/6460
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.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>
timer initialization is the first thing happening in
the Exynos CPU's bootblock code. Hence we don't need
to keep track of it in several places, and we don't
need to do it over and over again (e.g. in each stage)
Change-Id: I7bd9a0b7930fc9c37faabd62e3eecc3e5614a879
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168994
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Commit-Queue: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit 5a95bc2bcab5a92c5e6c144005861bf731f59de3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6638
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
A recent change to support early firmware selection on ARM broke snow and was
incompletely implemented on pit. This change fixes snow by applying
the remaining part of the change that had been applied to pit,
and also hooks up real values in the get_write_protect_state function.
Change-Id: Ifef7ad1bf399f79353daec3dd46973f2b2022e37
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/169120
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 841773e048cd9cfbb64782059c24e29c467f17c8)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6635
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
When passing '-ffreestanding' the 'main' romstage.c may no longer
necessarily be considered the entry point.
From the C specification in 5.1.2.1 Freestanding environment;
"In a freestanding environment (in which C program execution may take
place without any benefit of an operating system), the name and type of
the function called at program startup are implementation-defined."
Clang complains about these being missing as Clang is somewhat more
strict about the spec than GNU/GCC is. An advantage here is that a
different entry-point type-signature shall now be warned about at
compile time.
Change-Id: I467001adabd47958c30c9a15e3248e42ed1151f3
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/5872
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Otherwise without USB when coreboot boots too quickly
EC is confused and thinks that LID is closed and so
powers off the backlight until user flaps the lid.
Change-Id: I14dfaa62582de83fd4c9f9518e9436b3a3035366
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6651
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Otherwise we get a warning on normal boot.
Change-Id: Ida1e1d23e258438251d4ec2417f93ad14c3b9f7d
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6652
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Tested-by: build bot (Jenkins)
It doesn't harm to set several times but it pollutes the log.
Change-Id: I7aad7f0229a7d9d071ba844a1cfa123dffc4cacf
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6653
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
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 cleans out a lot of unused variables in the
ARM Kconfig files and introduces CONFIG_RAMSTAGE_BASE
which is similar to CONFIG_RAMBASE on x86.
This gets rid of the hard coded assumption that on ARM
coreboot is always executed at the lowest DRAM address.
But in fact, this might not be true because we might want
coreboot to live at the end of RAM, or in SRAM
Change-Id: I03e992645f9eb730e39a521aa21f702959311f74
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168645
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit 15b87892eb2d5e27759c49dc6c8c7e626f651d77)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6634
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
All this samsung_get_base_address_of_device_with_a_really_long_name()
boilerplate makes my eyes bleed... I think there are so much cleaner
ways to do this. Unfortunately changing this ends up touching nearly
every Exynos5 file, but I hope you agree that it's worth it (and the
sooner we get it over with, the better... I can't bring myself to make
another device fit into that ugly scheme).
This also removes the redundant EXYNOS5 base address definitions from
the 5420 directory when there are EXYNOS5420 ones, to avoid complete
confusion. The new scheme tries to use EXYNOS5 for base addresses and
exynos5 for types that are common between the two processors, and
EXYNOS5420/exynos5420 for things that have changes (although I probably
didn't catch all differences).
Change-Id: I87e58434490ed55a9bbe743af1f9bf2520dec13f
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/167579
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: ron minnich <rminnich@chromium.org>
(cherry picked from commit 66c87693352c248eec029c1ce83fb295059e6b5b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6632
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Since we're now supporting ARMv7 relocations, we can enable
rmodule support on Exynos 5420. This does not automatically
enable relocatable ramstage.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ic3af1eabb3b816944587a46409224f778d941b8a
Reviewed-on: https://chromium-review.googlesource.com/167403
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 7b5afef4ee87fc3245ec887dfda873c529d8d04d)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6629
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
This change shows the source structure for nvidia Tegra and Tegra124
SOC. The problem we are trying to solve is that there is a large
amount of common code in the form of .c and .h files across many
different Tegra SOCs. The solution is to provide common code in a
single directory, but not to compile in the common code directory;
rather, we compile in a directory for a given SOC. Different SOCs
will sometimes need different bits of code from the common directory.
Tegra common code lives in tegra/, but there is no makefile there: if
a Tegra common file is needed in a SOC, it is referenced via a
Makefile in a specific Tegra SOC.
Another issue is includes. Include files in the common directory might be
accessed by a piece of code in an SOC directory. More problematically,
code in the common directory might require a file in an SOC directory.
We don't want to put the SOC name in an #include path, e.g.
in a C file in tegra/ is very undesirable, since we might be compiling
for a tegra114.
On some systems this is solved by a pre-pass which creates a set of
symbolic links; on others with nested #ifdef in the common code
which include different .h files depending on CPP variables.
In previous years, both LinuxBIOS and coreboot have tried these
solutions and found them inconvenient and error-prone.
We choose to solve it by requiring explicit naming of part of the path
of files that are in the common directory. This requirement, coupled
with two -I directives in the Makefile.inc, allows common and SOC
C code to incorporate both common and SOC .h files.
.c and .h files -- SOC or common -- name include
files in the common directory with the prefix tegra/, e.g.
SOC files will be included from the SOC directory if they have no prefix:
The full patch of clock.h will depend on what SOC is being compiled, which
is desirable.
In this way, a common file can pick up a specific SOC file without
creating symlinks or other such tricky magic.
We show this usage with one file, soc/nvidia/tega124/clock.c. This compiles.
The last question is where to put the prototype for the function
defined in this file -- soc.h?
Change-Id: Iecb635cec70f24a5b3e18caeda09d04a00d29409
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/171569
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 53e3bed868953f3da588ec90661d316a6482e27e)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6621
Tested-by: build bot (Jenkins)
For now using the same gma.c and i915io.c files as for slippy
Change-Id: Ieb09d0152d525aa090eeb86ebfa253d450d22820
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64373
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 3e119c7e22cb82677754413e56a125f4a372ad54)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6603
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
A large portion of documented registers have been initialized using macros. Only a few
undocumented registers are left out. i915io.c looks lot more cleaner by removing redundant
calls. However, some more work is required to correctly identify which calls are not required.
All the io_writes are replaced by gtt_writes.
Change-Id: I077a235652c7d5eb90346cd6e15cc48b5161e969
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66204
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit 39f3289f68b527575b0a120960ff67f78415815e)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6600
Tested-by: build bot (Jenkins)
It's the third minipcie slot in x200.
Change-Id: Ibfa8d787698cd23b4abcffe5cff2d62039cf0f86
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/6641
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This commented out code is a left over from x86.
Change-Id: Ice806000c73d5a068962914d067d4de7b3d75f45
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/168961
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: David Hendrix <dhendrix@chromium.org>
(cherry picked from commit 9d700cf35d2283a088e704c0ebd34e6f58f54993)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6639
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The GPIO offset of '0x44 - GP_IO_SEL3' as specified in the pch.h header
is incorrectly reported as 'GPIO_SEL3'.
Change-Id: I56dcdda109d5f57ed45938d60b995807bdfb46b1
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6459
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Both 'SbSpiSpeedSupport' and 'UsbRxMode' are uninitiated upon return from
a 'sb800_cimx_config()' call.
Change-Id: I32237ff97fafc3e69627d427e54268dcb039e12c
Found-by: Coverity Scan
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/6474
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch renames the x86 way of doing things to
explicitly mention CMOS (which is not available on
our ARM platforms) and adds an implementation to
get VBNV through the Chrome EC. We might want to
refine this further in the future to allow VBNV
in the EC even on x86 platforms. Will be fixed when
that appears. Also, not all ARM platforms running
ChromeOS might use the Google EC in the future, in
which case this code will need additional work.
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901
Reviewed-on: https://chromium-review.googlesource.com/167540
Reviewed-by: David Hendrix <dhendrix@chromium.org>
Tested-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
(cherry picked from commit 8df6cdbcacb082af88c069ef8b542b44ff21d97a)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6616
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Vladimir Serbinenko