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>
$ 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>
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>
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>
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>
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>
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>
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>
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>
Kyösti Mälkki