Build with bfd and gold linker, but use bfd linker per default
and make sure that lto is enabled in both binutils and gcc
Change-Id: I0584396b4580674cfdca24fbed0d8eeb1ee38806
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10496
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
Instead of building IASL and GDB implicitly when building
GCC, this patch changes buildgcc to let you explicitly specify
what you want to build.
This will prevent IASL from building over and over again, when
all you need is GDB.
The new command line option is -P | --package <package> where
package is one of the following: GCC, GDB, CLANG, IASL
If no package is specified, buildgcc will default to GCC.
Change-Id: I8836bed16fc2bc39e0951199143581cc6d71cb4d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10492
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
The type1 family setting from chromium was mis-merged into the
type2 function. Move it to the correct type1 function.
Bad commit: 51bdc47816
Change-Id: I72e6ef80bbf185a39fcf169c8247dc16462e6bc3
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10498
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
IASL was broken when compiling without GCC.
Change-Id: Ib859ce41c1dda10181781c025fc378504f5ebb91
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10495
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
GDB stopped building ever since we updated from version 7.6
but nobody noticed ;)
Update from 7.9 to 7.9.1 and bring the required patches forward.
Change-Id: I2f357525a46d5540e9f57b80d830943bbd5dfcaf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10494
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <edward.ocallaghan@koparo.com>
This groups all tasks happening in the main program,
orders them according to their dependencies and adds
comments on the various tasks.
Change-Id: Ib62bd213977cbc3307ef62e9a7e64515563968c1
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10490
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
- don't capture build_$package in a subshell by piping it
- move HOSTCFLAGS to build_GMP
- only create a build directory if a build happens
- automatically collect packages to build
Change-Id: Ic5a9f3f222faecd3381b413e5f25dff87262a855
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10475
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Tested-by: build bot (Jenkins)
The type of a resource is really an enumeration but our implementation
is as a bitmask. Compare all relevant bits and remove the shadowed
declarations of IORESOURCE bits.
Change-Id: I7f605d72ea702eb4fa6019ca1297f98d240c4f1a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8891
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
No board in the tree selects this and it looks like the implementation
was done at chipset level while it should be part of PCI subsystem.
When enabled, at least AMD K8 and f14, f15tn and f16kb fail build test.
Feature of placing prefetchable PCI memory above 4GB may not work if
there is any 32-bit only prefetchable PCI BARs in the system.
Change-Id: I40ded2c7d6d05f461423721aa5d78a78f9f9ce1e
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8705
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
On modern mainboards with multiple PCI-e devices and a single
graphics card the default MMIO hole size of 512M is inadequate,
leading to resource-hungry PCI-e devices (such as an external
graphics card) being assigned invalid MMIO ranges. This, in
turn, causes the entire PCI subsystem to become unavailable,
leading to a failure to boot.
TEST: Booted KGPE-D16 with NVIDIA 7300LE and verified proper
operation of PCI/PCI-e devices, including text mode VGA operation
via the add-on card and its VGA option ROM.
Change-Id: I8d25f4b19f2d0860644ab1ee002c15041437121f
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/10428
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add a savedefconfig target and the help for it to the kconfig
makefile.
The main advantage I found for using defconfigs instead of the full
.config is that they require less maintenence, so long as reasonable
default values are set when adding new config options. When the
defconfig is expanded, it will use default values for all options not
saved in the defconfig. This cuts the size of a saved config from
500ish lines to roughly 20 lines.
savedefconfig was added to the linux kernel in commit id
7cf3d73b4360e91b14326632ab1aeda4cb26308d
Change-Id: I45f3dc87b773fb6e9ee53e32fdcafff1f53074d2
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10462
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Bring gdb in sync with all other build targets.
Change-Id: I9c478947a00f044edf910a91d876bbf486a791cf
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10488
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Otherwise one could end up with what they think is a coreboot toolchain
but in fact it'd be missing some patches.
Change-Id: Ic451f7061b822d0f4b64acc9976ba81fd544e85b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10487
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
gcc and binutils fixed their upstream tar balls, and running
autoconf created more problems than it solved
Change-Id: I0003dd597f521701405ff35923214435136b262d
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10486
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Change-Id: I29fe23e377045f08b8212742d84c2ee2b4a61b15
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10485
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Change-Id: I7a095470d408d013a4a915e010c59ea99ca1f1c8
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10484
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
For console drivers which use udelay() we can deadlock
in the printk path on the spinlock. The reason is that
on the first call to udelay() from within a console driver
it will go back down the printk() path deadlocking oneself.
Just remove the printk() as it was asymmetric on romstage
vs ramstage.
Change-Id: I30fe7d6e5b4684f17d4f353c0816b64f9242de0a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10483
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This change is necessary to support future additions to romstage.
Change-Id: Ibb69994847945c7adbafbf2bc677b33821df8146
Signed-off-by: Ionela Voinescu <ionela.voinescu@imgtec.com>
Reviewed-on: http://review.coreboot.org/10457
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of having the chipset code make the approrpiate
calls at the appropriate places use the cbmem init hooks
to take the appropriate action. That way no chipset code
needs to be changed in order to support the external
stage cache.
Change-Id: If74e6155ae86646bde02b2e1b550ade92b8ba9bb
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
It can be helpful to certain users of the cbmem init hooks
to know if recovery was done or not. Therefore, add this
as a parameter to the hooks.
Change-Id: I049fc191059cfdb8095986d3dc4eee9e25cf5452
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10480
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to accomodate objects not directly linked into ramstage
anymore those files need to be added to the image when UPDATE_IMAGE
is selected. Otherwise many required pieces are missing from booting
correctly.
Change-Id: Ic0b24387d24d0af3b75f5fd6fa1795fd381c4d58
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10410
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
CPU-side logic is unchanged for this range of CPUs as long as all of them
use TSEG (or ASEG, just needs to be consistent). So uplift 206ax code while
extracting southbridge and APIC code into separate functions.
Change-Id: Ib365681d1da8115922c557fddcc59afc156826da
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10465
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
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>
Stefan Reinauer