| Age | Commit message (Collapse) | Author |
|---|
|
Squashed and adjusted two changes from chromium.git. Covers
CBMEM init for ROMTAGE and RAMSTAGE.
cbmem: Unify random on-CBMEM-init tasks under common CBMEM_INIT_HOOK() API
There are several use cases for performing a certain task when CBMEM is
first set up (usually to migrate some data into it that was previously
kept in BSS/SRAM/hammerspace), and unfortunately we handle each of them
differently: timestamp migration is called explicitly from
cbmem_initialize(), certain x86-chipset-specific tasks use the
CAR_MIGRATION() macro to register a hook, and the CBMEM console is
migrated through a direct call from romstage (on non-x86 and SandyBridge
boards).
This patch decouples the CAR_MIGRATION() hook mechanism from
cache-as-RAM and rechristens it to CBMEM_INIT_HOOK(), which is a clearer
description of what it really does. All of the above use cases are
ported to this new, consistent model, allowing us to have one less line
of boilerplate in non-CAR romstages.
BRANCH=None
BUG=None
TEST=Built and booted on Nyan_Blaze and Falco with and without
CONFIG_CBMEM_CONSOLE. Confirmed that 'cbmem -c' shows the full log after
boot (and the resume log after S3 resume on Falco). Compiled for Parrot,
Stout and Lumpy.
Original-Change-Id: I1681b372664f5a1f15c3733cbd32b9b11f55f8ea
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/232612
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
cbmem: Extend hooks to ramstage, fix timestamp synching
Commit 7dd5bbd71 (cbmem: Unify random on-CBMEM-init tasks under common
CBMEM_INIT_HOOK() API) inadvertently broke ramstage timestamps since
timestamp_sync() was no longer called there. Oops.
This patch fixes the issue by extending the CBMEM_INIT_HOOK() mechanism
to the cbmem_initialize() call in ramstage. The macro is split into
explicit ROMSTAGE_/RAMSTAGE_ versions to make the behavior as clear as
possible and prevent surprises (although just using a single macro and
relying on the Makefiles to link an object into all appropriate stages
would also work).
This allows us to get rid of the explicit cbmemc_reinit() in ramstage
(which I somehow accounted for in the last patch without realizing that
timestamps work exactly the same way...), and replace the older and less
flexible cbmem_arch_init() mechanism.
Also added a size assertion for the pre-RAM CBMEM console to memlayout
that could prevent a very unlikely buffer overflow I just noticed.
BRANCH=None
BUG=None
TEST=Booted on Pinky and Falco, confirmed that ramstage timestamps once
again show up. Compile-tested for Rambi and Samus.
Original-Change-Id: If907266c3f20dc3d599b5c968ea5b39fe5c00e9c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/233533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I1be89bafacfe85cba63426e2d91f5d8d4caa1800
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/7878
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
The cbmem util needs the CBMEM_IDs and the strings for
reporting and shares the cbmem.h file with coreboot. Split out
the IDs so for a simpler sharing and no worries about overlap of
standard libraries and other things in the header that coreboot
requires, but the tool does not.
Change-Id: Iba760c5f99c5e9838ba9426e284b59f02bcc507a
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10430
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Taken from CrOS, including everything up to commit da4c33913.
Adapted to upstream.
Change-Id: I095e6726a220200ba17719fc05fcdc521da484e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10432
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I78519b8f060b1ba81e8b9c7c345820180a14f2fe
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10441
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
$ make gitconfig
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
util/xcompile/xcompile: line 164: -print-librt-file-name: command not found
[..]
Change-Id: Ib477566e3841e419aa7880c912636540a0ad5432
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10464
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This removes quite a bit of boilerplate from the script, and makes
it easier to read.
Change-Id: I92348b810ff19f7d18810f842b76e0e595b3d397
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add a new option -C|--clang to buildgcc to build a clang based
toolchain as opposed to a gcc based toolchain. This toolchain
comes with the required patches needed to successfully build
coreboot, and also with clang's famous scan-build script.
Change-Id: I1aea7cd6002edc4f3bb2b46dc1f69a212ad18f77
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10415
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
- keep a list of packages to build in $PACKAGES and only download,
patch and build a package if it is in that list (instead of having
exceptions for GDB, EXPAT and PYTHON)
- unify interface for download() and unpack_and_patch()
- consolidate some randomly spread code like creating / removing
build directories and calls to searchtool()
Change-Id: I2070e3b2fbb84eb18e9220658fb2d5518b8179ee
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10434
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Resync together, backporting a fix for the initialization of
8254 and 8259, as in commit 8d9a1bd5. Also fix a typo and
reduce out useless whitespace differences.
Change-Id: I9a9b1fb9083c5417a8d061f90a89074f2a601ddf
Signed-off-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reported-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/10453
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Who knows it still?
Change-Id: If6e36569cd9a1ba3da8b3fe84264cd2a6dfd634b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10443
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Be consistent.
Change-Id: I13df06fbc86371bfcb4ddd809d07c9e7fb931018
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10381
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
The SOUTHBRIDGE_INTEL_FSP_I89XX symbols are never defined in any Kconfig
file or used anywhere in the existing coreboot tree. Removing them as
unnecessary. If the southbridge code ever gets uploaded, these can be
re-added at that point.
Change-Id: I36f9ca8e25e08ce154d10ea9d764a73095590244
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10436
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Mimic vendor BIOS in switching off the led once coreboot has booted
successfully. Currently the led behavior is inconsistent. The led turns on
during poweron and stays on forever. When entering S3 and during S3 it
blinks and turns off after wake from S3. The behavior associated with S3
is the same under vendor BIOS and under coreboot. Switching off the led
before jumping to the payload makes the led behavior consistent within
coreboot before S3 and after wake from S3 and it makes the led behavior
consistent to vendor BIOS.
Change-Id: I0dec10b842b83dfc8054cd56d2750b724c4e8576
Signed-off-by: Axel Holewa <mono-for-coreboot@donderklumpen.de>
Reviewed-on: http://review.coreboot.org/10454
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
Change the Kconfig board name symbol to uppercase to match
other symbols and to match the capitalization in the Kconfig
file where it's used in an expression.
Change-Id: I04ccb57cc15a6d7430f8d04136beb8384caa6c04
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10440
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Cleaning up unused Kconfig symbols. These symbols are not used anywhere
in the coreboot tree as far as I can tell.
Change-Id: I4d0b9512a784083dd134a8706b3bd8eca2a3a909
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10439
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
All other Kconfig locations start with tabs.
Change-Id: I0ee5f0b0b82f85c8ae58b3626f142f159554efb3
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10438
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
the moving of 'documentation' to 'Documentation/' means that the doxygen
target in the main Makefile was broken as it couldn't find the directory.
Change-Id: If6c6d34110e683f38959571a03767fb472675f40
Signed-off-by: Nicky Sielicki <nlsielicki@wisc.edu>
Reviewed-on: http://review.coreboot.org/10445
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
|
|
Fixes reproducible builds.
Change-Id: I3b0a21f93daee09605c0c2a05c1739e04f44527f
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/10447
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
generate_sata_ssdt_ports() generates ports based on sata enable map
Change-Id: Ie68e19c93f093d6c61634c4adfde484b88f28a77
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9708
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-by: Peter Stuge <peter@stuge.se>
|
|
This will be useful for adding clang support (and hopefully
makes the code a bit more readable)
Change-Id: Ie866fb2bd71e2a64f26f2755961bd126e101cbe5
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10433
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I1ba4bfa0ac36a09a82b108249158c80c50f9f5fd
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9599
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I7fca8c3fa15c1be672e50e4422d7ac8e4aaa1e36
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9598
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
`device_t device` is missing as argument. Every device_op function
should have a `device_t device` argument.
Change-Id: I3fc8e0339fa46fe92cc39f7afa896ffd38c26c8d
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: http://review.coreboot.org/9597
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This simply copies veyron_brain to veyron_mickey and makes the
minimal set of changes (s/brain/mickey) to make it compile. The
follow-up patch will take into account board differences.
BUG=none
BRANCH=none
TEST="emerge-veyron_mickey coreboot" doesn't fail
Change-Id: I7d029b36d2fb865446490b896117ade632325a52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 34f6b391290f99caf517d7e98c31c89dc57309be
Original-Change-Id: I03a2b80eb441384f363910467180479521765431
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/271360
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10408
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This simply copies veyron_brain to veyron_romy and makes the
minimal set of changes (s/brain/romy) to make it compile. The
follow-up patch will take into account board differences.
BUG=none
BRANCH=none
TEST="emerge-veyron_romy coreboot" doesn't fail
Change-Id: Ice1bc012bddd6c51b43944747e0df3ffa34207fa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ab849178b69cf2323f126e503bd61080048240a
Original-Change-Id: I0516ce94fd3c6a38170fae221a070f503ccfaf0f
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/271345
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/10407
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
|
|
This patch adds a few bit counting functions that are commonly needed
for certain register calculations. We previously had a log2()
implementation already, but it was awkwardly split between some C code
that's only available in ramstage and an optimized x86-specific
implementation in pre-RAM that prevented other archs from pulling it
into earlier stages.
Using __builtin_clz() as the baseline allows GCC to inline optimized
assembly for most archs (including CLZ on ARM/ARM64 and BSR on x86), and
to perform constant-folding if possible. What was previously named log2f
on pre-RAM x86 is now ffs, since that's the standard name for that
operation and I honestly don't have the slightest idea how it could've
ever ended up being called log2f (which in POSIX is 'binary(2) LOGarithm
with Float result, whereas the Find First Set operation has no direct
correlation to logarithms that I know of). Make ffs result 0-based
instead of the POSIX standard's 1-based since that is consistent with
clz, log2 and the former log2f, and generally closer to what you want
for most applications (a value that can directly be used as a shift to
reach the found bit). Call it __ffs() instead of ffs() to avoid problems
when importing code, since that's what Linux uses for the 0-based
operation.
CQ-DEPEND=CL:273023
BRANCH=None
BUG=None
TEST=Built on Big, Falco, Jerry, Oak and Urara. Compared old and new
log2() and __ffs() results on Falco for a bunch of test values.
Change-Id: I599209b342059e17b3130621edb6b6bbeae26876
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3701a16ae944ecff9c54fa9a50d28015690fcb2f
Original-Change-Id: I60f7cf893792508188fa04d088401a8bca4b4af6
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273008
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Every Lenovo Thinkpad includes a Trusted Platform Module, so we can enable
it for the sandy-/ivybridge platforms.
Change-Id: Icda443ba88c2a49a0033014ce7710dd607fa15dc
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: http://review.coreboot.org/10411
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I930f2beacdc95d0a7edd07db66a1c2e58bb2f3cd
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8566
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: Ice7cb89c19585cf725b6f73c33443050f8d65418
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8565
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
We can define is_sblink = (max == 0) as sblink is always the
very first chain we scan.
Change-Id: Ibd6b3ea23954ca919ae148604bca2495e9f8753b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8564
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I6041b666e6792cf97b8273ed54832d86af8ed23e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8563
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I1e935a6b848a59f7f2e58779bceea599032de9e3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8562
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I65fad1cfba95f0ee1ed3f7f7a57d874144da1e40
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8561
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
If SB_HT_CHAIN_ON_BUS0 is selected, HyperTransport chain for System Bus
is the first to scan and it will be assigned with bus number 0.
If HT_CHAIN_DISTRIBUTE is selected, each link will reserve a fixed range
of bus numbers instead of assigning consecutive numbers across all the links.
All fam10 have SB_HT_CHAIN_ON_BUS0 selected under northbridge.
Follow-up can easily drop this if we find this is dictated by architecture.
Change-Id: I8deddcb4c3fd679b6b27e2879d9dba3895c4dd6f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8366
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
When we want to scan the HT chain to southbridge first, we
relocate it as the first item of dev->link_list of node 0.
Change-Id: Ic73ba43aadb3c5e0c8d4b82ed7d41094692ea37f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8560
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Define the default value under northbridge. The list of boards this
patchset touches will change to use SB_HT_CHAIN_ON_BUS0 with
follow-up patch.
Based on code analysis, these boards already scan system bus
as the first (active) HT chain, so it is placed as bus 0
even when this option was not explicitly selected.
Change-Id: I5a00d6372cb89151940aeee517ea613398825c78
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8353
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I452a93af452073eeac4e6cb9bbc232dc59e911c1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8365
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I24ca1dce025e00064f9209affa27586292c7650e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8559
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: Ic8fbafdfadbc4ef0896d93e61c8a54ce69297e07
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8558
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I3b00e5e4e45089fbd7d0d6243d5e441bd8929c0b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8557
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Some cases of max==0xff wrapping around the 8-bit link->secondary
register remain to be solved.
Change-Id: I01e2ab6b2f23a03dbac49207ab584eccd1ca9b1f
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8364
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I6bbd1b5eaa66a640e0a2e132c8d67f38f103caf5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8352
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I297de09dcf93511acece4441593ef958a390fddb
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8362
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Change-Id: I41aeb80121f120641b65759c8502150ce89caa30
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8556
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
One PCI function may contain upto 4 links, further links must
be added to PCI function 4 on the same device.
There is no requirement that in dev->link_list the last element
would have the highest link->link_num.
Also fix off-by-one error when allocating for more links.
Change-Id: If7ebdd1ad52653d3757b5930bd0a83e2cf2fcac6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8555
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
clang requires some additional options to disable warnings which
can be handled by xcompile.
Also drop the hard coded clang compilers in Makefile
Change-Id: I0f12f755420f315127e6d9adc00b1246c6e7131b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7612
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We test for it in xcompile and add it to CFLAGS.
Change-Id: I041a881b542bc55c1725af384f038da3356e3bb1
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10426
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Instead of fetching libgcc's location and required compiler flags on every
individual build, do it once in xcompile.
Change-Id: Ie5832fcb21710c4cf381ba475589d42ce0235f96
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/10425
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
This uses the availability of CONFIG_* variables in .xcompile and tests for
compilers in xcompile so that the build system doesn't need to probe them.
Change-Id: I359ad6245d2527efa7e848a9b38f5f194744c827
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/10424
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This is in preparation of adding support for clang to xcompile.
Change-Id: I518d077f134610082b0939b1525682f2289eec34
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10423
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Kconfig already quotes the string. Double quoting actually removes the
quoting.
Change-Id: I927d90dc2ce8af4e8d2d700d2bb3e04254459e1b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10382
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
It's not used until then, but by moving it below including .config,
we can use CONFIG_* in the .xcompile file in the future.
Change-Id: I672f444dd28b5fae1fc339a1e0e78a249c9b7875
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10422
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
crossgcc builds gmp, whose build system normally optimises for the hardware
it's built on. That may give a minor performance boost but has the downside
that the compiler becomes non-portable and may break on other systems due to
illegal instructions.
Setting CFLAGS to some reasonable value prevents gmp's configure script from
choosing CPU specific -mtune flags (which may enable optimizations that only
run on CPUs with the same feature set).
Enabling "fat" builds make the build system add all optimized assembler
routines and makes the selection of the right one a runtime decision instead
of deciding at compile time.
Change-Id: I72d20627270baa082cd02ebb4c9a09cd23f30f8c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/10412
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The input/output value max is no longer used for tracking the
bus enumeration sequence, everything is handled in the context
of devicetree bus objects.
Change-Id: I545088bd8eaf205b1436d8c52d3bc7faf4cfb0f9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8541
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ifd277992a69a4182e2fac92aaf746abe4fec2a1b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8540
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: Ib33d3363c8d42fa54ac07c11a7ab2bc7ee4ae8bf
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8539
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Parameter max is the cumulative number of PCI buses scanned on the
system so far. Use the property subordinate from the parent PCI bridge
device to keep track of the first available bus number instead of
passing that on the stack.
Change-Id: I1a884c98d50fa4f1eb2752e10b778aea8a7b090a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8537
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I1766c92abe7a74326c49df74ba38930a502fcb5b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8536
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
For the PCI root node, input parameter max==0 and output value
max is not relevant for operation.
Change-Id: I23adab24aa957c4d51d703098a9a40ed660b4e6c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8855
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
The actual use of the parameter max is to keep track of PCI bus
number while recursively scanning PCI bridges or PCI-e rootports.
Neither CPU, SMBus, LPC or other static buses are involved in this
enumeration, but the way bridge operations were originally designed
forced to pass this argument thru unrelated functions.
Follow-up removes these once the function prototype gets fixed.
Change-Id: Idbc9c515a362c571a1798bb36972058b309c2774
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8535
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
Use of scan_static_bus() and tree traversals is somewhat convoluted.
Start cleaning this up by assigning each path type with separate
static scan_bus() function.
For ME, SMBus and LPC paths a bus cannot expose bridges, as those would
add to the number of encountered PCI buses.
Change-Id: I8bb11450516faad4fa33b8f69bce5b9978ec75e5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8534
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
|
|
For amdfam10, (ht_c_index > 3) never evaluates true as the code
already has a return for this case above.
Change-Id: Ie90941671e1b2b4f42e2b1b0641ca59334fcf0f1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8688
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Allows to remove parameter max from the call, it is not involved
with the unitid assignment.
Change-Id: I087622f4ff69474f0b27cfd8709106ab8ac4ca98
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8687
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Follow up for commit b890a12, some contributions brought
back a number of FSF addresses, so get rid of them again.
Change-Id: Idcd059f05523916f726b94931c2487ab028b7d72
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10409
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
|
|
1. There is a mis-understanding to calculate the value of TD Size
in Normal TRB. For MTK's xHCI controller it defines a number of
packets that remain to be transferred for a TD after processing
all Max packets in all previous TRBs, that means don't include the
current TRB's.
2. To minimize the scheduling effort for synchronous endpoints in xHC,
the MTK architecture defines some extra SW scheduling parameters for
HW. According to these parameters provided by SW, the xHC can easily
decide whether a synchronous endpoint should be scheduled in a specific
uFrame. The extra SW scheduling parameters are put into reserved DWs
in Slot and Endpoint Context. But in coreboot synchronous transfer can
be ignored, so only two fields are set to a default value 1 to support
bulk and interrupt transfers, and others are set to zero.
3. For control transfer, it is better to read back doorbell register or add
a memory barrier after ringing the doorbell to flush posted write.
Otherwise the first command will be aborted on MTK's xHCI controller.
4. Before send commands to a port, the Port Power in PORTSC register should
be set to 1 on MTK's xHCI so a hook function of enable_port in
generic_hub_ops_t struct is provided.
Change-Id: Ie8878b50c048907ebf939b3f6657535a54877fde
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 738609c11f16264c6e6429d478b2040cb391fe41
Original-Change-Id: Id9156892699e2e42a166c77fbf6690049abe953b
Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/265362
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10389
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
BRANCH=none
BUG=none
TEST=none
Change-Id: I563ef65db900d7675aeb5b9123dfb5a8980bf964
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9764115d7bcce1d6423464bd81b58211ac728409
Original-Change-Id: Ibac8d3b9e28b4a563079f288901abcfbff6913ee
Original-Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/269863
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
cbfs_get_file_content was replaced with cbfs_boot_map_with_leak but
36f8d27ea9f741e184b76b5f42d7f777f207edc0 failed to get it into account.
Change-Id: I0c7840043b2ea6abaf8e70f4bf1a63c96aedebc1
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10403
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Ieb6f70f5b2863336bd6143b2dfbb1d67c4c26109
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10323
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Makes it cleaner by putting AML into separate file rather than having
an array in C code.
Change-Id: Ia5d6b50ad9dabdb97ed05c837dc3ccc48b8f490f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10385
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This should be an internal selectable variable rather than user-visible config.
Moreover the description is misleading.
This is a typical case of an option "Should it work?" where there is only one
right answer yet we still ask it.
Change-Id: Idc0ce2e1b9f89eddd034966cc877483d994ce0eb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10378
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
RELOCATABLE_MODULES controls inclusion of rmodule support but including it
without having anything that uses it is a pure waste of space. So instead
make RELOCATABLE_MODULES be selected exactly when there is something using it.
Change-Id: I377a955f0cd95b0f811b986df287864c3dc9f89a
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10377
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
One can remove the struct buffer_area and use the region_device
embedded in the struct prog to represent the in-memory loaded
program. Do this by introducing a addrspace_32bit mem_region_device
that can have region_device operations performed on it. The
addrspace_32bit name was chosen to make it explicit that 32-bits
of address space is supported at the max.
Change-Id: Ifffa0ef301141de940e54581b5a7b6cd81311ead
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10261
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
The api to mirror_payload() was changed, but as no board
in coreboot.org selected MIRROR_PAYLOAD_TO_RAM_BEFORE_LOADING
this issue was missed. Update to using the prog functions.
Change-Id: I4037f5dc6059c0707e1bf38eb1fa3d1bbb408e2a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10260
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
This reverts commit 701211a6e57a17ea861b4ad682dca7416fc9050e.
Change-Id: Ib3e573548bff5c17ab30cfab3d833a2065d689c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10222
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
|
|
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The lack of a div_round_up() function in libpayload keeps being a
problem for payloads and has already caused us to sprinkle numerous
less-readable ALIGN_UP(n, d) / d throughout depthcharge. Let's add this
so we can avoid adding any more and then maybe cocchinelle them all over
later.
BRANCH=None
BUG=None
TEST=None
Change-Id: I241a52770a0edcf7003b48a81875b3fa0cb7ed53
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a3f9514f9cfd325cc3c4b542020574b605fac935
Original-Change-Id: Ia55bd4bc52ab8a249b4854e40727cf6917af7b30
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/273050
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10392
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The RPM initialization Acknowledge is cleared by writing 1
into bit-10 of the RPM_INT_ACK register.
The existing code got it wrong and is writing zero to that bit.
BRANCH=storm
BUG=chrome-os-partner:39231
TEST=with this patch and an RPM firmware update, an SP4 device
survived more than 1000 reboots in a row.
Change-Id: Ibba296ed0571ad9403a0c51c7f82f07f185b4e83
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 13b4a0f093ba652ad6bccdfc4b3686c0741c6fe7
Original-Change-Id: I39e6ea50e0f66b4af68bdb868dd4437c34bb4524
Original-Signed-off-by: Viswanath Kraleti <vkraleti@codeaurora.org>
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/266969
Original-Reviewed-by: Manoj Juneja <mjuneja@qti.qualcomm.com>
Reviewed-on: http://review.coreboot.org/10310
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch provides support for TPM Infineon SLB9670 by adding its
device ID to the list.
BRANCH=None
BUG=chrome-os-partner:40640
TEST=Built and test SLB9670 on SKL U Reference board Fab 2
Change-Id: I2d26fc6c7d074881f2e6189e1325808544b7d26d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3c92884be75b631c302801e162292c245ed7bf5d
Original-Change-Id: I4607fc96f70175b2461b40ba61e7a821e187de40
Original-Signed-off-by: Wenkai Du <wenkai.du@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/274053
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: http://review.coreboot.org/10387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
BRANCH=none
BUG=none
TEST=Booted on Oak and confirmed the output cacheable/non-cacheable
string is correct.
Change-Id: I062c1cc384b8cb9d07038399b1bc7ef47d992103
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 45552f95b55cd9fc81817e4ff02c78e885377065
Original-Change-Id: Ie52066dbefd2f54d0746792b89f0b57767811adb
Original-Signed-off-by: Jimmy Huang <jimmy.huang@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273994
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/10390
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
We have observed issues with enabling CONFIG_SMP and adding prints
before MMU is enabled on Tegra-based SoCs. This seems to be related
to the hardware assisted locks and the restrictions laid down by ARMv8
spec.
BUG=None
BRANCH=None
TEST=Boots to kernel prompt on smaug.
Change-Id: I29a52f5a972baf396c01faba3ae3e5ecd27563e9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f52ee4b5b2e9b7f54eee0d105cb7e17f9a7e1613
Original-Change-Id: I432895560f468903c7beef00e78b6d38275a619c
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/272449
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10311
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The current arm64 MMU interface is difficult to use in pre-RAM
environments. It is based on the memranges API which makes use of
malloc(), and early stages usually don't have a heap. It is also built
as a one-shot interface that requires all memory ranges to be laid out
beforehand, which is a problem when existing areas need to change (e.g.
after initializing DRAM).
The long-term goal of this patch is to completely switch to a
configure-as-you-go interface based on the mmu_config_range() function,
similar to what ARM32 does. As a first step this feature is added
side-by-side to the existing interface so that existing SoC
implementations continue to work and can be slowly ported over one by
one. Like the ARM32 version it does not garbage collect page tables that
become unused, so repeated mapping at different granularities will
exhaust the available table space (this is presumed to be a reasonable
limitation for a firmware environment and keeps the code much simpler).
Also do some cleanup, align comments between coreboot and libpayload for
easier diffing, and change all error cases to assert()s. Right now the
code just propagates error codes up the stack until it eventually
reaches a function that doesn't check them anymore. MMU configuration
errors (essentially just misaligned requests and running out of table
space) should always be compile-time programming errors, so failing hard
and fast seems like the best way to deal with them.
BRANCH=None
BUG=None
TEST=Compile-tested rush_ryu. Booted on Oak and hacked MMU init to use
mmu_config_range() insted of memranges. Confirmed that CRCs over all page
tables before and after the change are equal.
Change-Id: I93585b44a277c1d96d31ee9c3dd2522b5e10085b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f10fcba107aba1f3ea239471cb5a4f9239809539
Original-Change-Id: I6a2a11e3b94e6ae9e1553871f0cccd3b556b3e65
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/271991
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10304
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Change-Id: I99717072679a51deecd6934ce7fb4aeb45135cd6
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: http://review.coreboot.org/10386
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
|
|
With addition of bl31 and trusty, we need to increase the number of
parsed fw components in vboot to 6.
CQ-DEPEND=CL:273866
BUG=chrome-os-partner:40713
BRANCH=None
TEST=Compiles successfully and vboot finds trusty and bl31.
Change-Id: I3597e98370bbaef4d2e563c868eed59b2e18adca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ff87fdbc7779e6ee410905d1618281411b38a93
Original-Change-Id: Ia403f895b50cc5349bb700d01f62e13c679f68f4
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273865
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
They're not referenced in the code anywhere.
Change-Id: I4805e11523ca7d3cffb484c719f479b7a6ba3e15
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10384
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I79fd4d17b534274b1e84bc97ca5a2a6ee55e3114
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10383
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Change-Id: I3b5fe953fa0e00fb827b66963d69f32d63a07b16
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10369
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Previously I tried to see if Linux think that port 0x60 is in use by keyboard.
Unfortunately it always thinks that it is. Instead just base off real input
busses used.
Change-Id: I4bb744938f623d29f38396165a1694fee78c3d32
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10376
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: I26c78d05524e5affcd44b528895d1e19905e924b
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10375
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
It was reversed between Lenovo and non-Lenovo cases.
Change-Id: I52c3b928abda2851e97ec0b40b7da5c5191217f5
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10374
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: Icfa3874b8e3accb3aa3db44d0baa6b7b5a683b41
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10373
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Apple is named Apple Inc in DMI but is "apple" in coreboot naming.
For other vendors we should follow similar pattern.
Change-Id: I7975b19faaf942c5bd44a704bcee994815499ceb
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10372
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: Ibd5c8a1364ab183f72e12cc9b450a36200fe3fde
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10371
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
This allow an easy creation of standalone "autoport pack".
Change-Id: Ibe9e38aa3b4bbd7260104e1c2a11630790ff4d2f
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10370
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Change-Id: I089ec3d68e734820d13bb68a7122dfdb89c3f6a3
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10368
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
|
|
Only define the ASSERT macro when it is not already defined. This
change allows the UEFI/FSP definitions to be included with most other
coreboot includes.
BRANCH=none
BUG=None
TEST=Build and run on sklrvp
Change-Id: Iccfeb83eb1e52623ae0a0fe2a96b587ce61f82d7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch provides support for TPM Infineon TT1.2
devices by enumerating the TT1.2 ID in the Infineon
device list.
BRANCH=None
BUG=None
TEST=Built for sklrvp and tested on RVP3.
Change-Id: I9daecc09311477fd9947e829d80abc040b2c9e3d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3ff86f96cb3e2f203dbc86e7004f1a037b98b90a
Original-Change-Id: I8b59eba348fc44632e22600646eb0b10eb2f4901
Original-Signed-off-by: Subrata <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/271256
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Reviewed-on: http://review.coreboot.org/10302
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
Current TPM driver does not support multiple devices for
a given vendor. As the device object never takes the 2nd
ID in the list. This patch fixes the same.
BRANCH=None
BUG=None
TEST=Built for sklrvp and tested on RVP3.
Change-Id: I82c3267c6c74b22650fc53dc6abdc2eb3daa138e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ff42613f11b4f1a79e907601f1ecb7b83a3aeaab
Original-Change-Id: Ieb44735c37208bfe90a8e22e0348dd41c8c642d2
Original-Signed-off-by: Subrata <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/271727
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Tested-by: Naveenkrishna Ch <naveenkrishna.ch@intel.com>
Original-Commit-Queue: Pravin K Angolkar <pravin.k.angolkar@intel.com>
Original-Tested-by: Pravin K Angolkar <pravin.k.angolkar@intel.com>
Reviewed-on: http://review.coreboot.org/10303
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
|
|
Change-Id: I106779571df5168ec358ad1cc4dc4195639a7a7d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/10359
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
