Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
All systems are building with IASL warnings as errors enabled.
Remove the option to disable it.
Remove the notification at the end of the build.
Change-Id: I5c6218c182fdf173b4026fd010d939a5fa36040e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16606
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Place config DEVICETREE after the sourced mainboard Kconfig. This
gives the mainboard the opportunity to set a unique default value.
Change-Id: Id877e1e8f555334a99b6c0ee1782d06a4a2b7a04
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/16493
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
A new Kconfig option, DEBUG_PRINT_PAGE_TABLES, is added to control this
behaviour. It is currently only available on RISC-V, but other
architectures can use it, too, should the need arise.
Change-Id: I52a863d8bc814ab3ed3a1f141d0a77edc6e4044d
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/16015
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Indicate to the build system that a platform provides support
for a writable boot device. The following will provide the
necessary support:
COMMON_CBFS_SPI_WRAPPER users
soc/intel/apollolake
soc/intel/baytrail
soc/intel/braswell
soc/intel/broadwell
soc/intel/skylake
The SPI_FLASH option is auto-selected if the platform provides
write supoprt for the boot device and SPI flash is the boot
device.
Other platforms may provide similar support, but they do that
in a device specific manner such as selecting SPI_FLASH
explicitly. This provides clearance against build failures
where chipsets don't provide SPI API implementations even
though the platform may use a SPI flash to boot.
BUG=chrome-os-partner:56151
Change-Id: If78160f231c8312a313f9b9753607d044345d274
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16211
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
The common boot device spi implementation is very much
specific to SPI flash. As such it should be moved into
that subdirectory. It's still a high-level option but
it correctly depends on BOOT_DEVICE_SPI_FLASH. Additionally
that allows the auto-selection of SPI_FLASH by a platform
selecting COMMON_CBFS_SPI_WRAPPER which allows for culling
of SPI_FLASH selections everywhere.
BUG=chrome-os-partner:56151
Change-Id: Ia2ccfdc9e1a4348cd91b381f9712d8853b7d2a79
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16212
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: I06f138078c47a1e4b4b3edbdbf662f171e11c9d4
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16228
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Almost all boards and chipsets within the codebase assume or
use SPI flash as the boot device. Therefore, provide an option
for the boards/chipsets which don't currently support SPI flash
as the boot device. The default is to assume SPI flash is the
boot device unless otherwise instructed. This falls in line
with the current assumptions, but it also allows one to
differentiate a platform desiring SPI flash support while it not
being the actual boot device.
One thing to note is that while google/daisy does boot with SPI
flash part no SPI API interfaces were ever implemented. Therefore,
mark that board as not having a SPI boot device.
BUG=chrome-os-partner:56151
Change-Id: Id4e0b4ec5e440e41421fbb6d0ca2be4185b62a6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16191
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
This reverts commit a83bbf5854.
This was submitted out of order.
Change-Id: Ic5a28faf94c1f1901a72e46343722eb4224c5086
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16226
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This option is no longer used in the code base. Remove it.
BUG=chrome-os-partner:56151
Change-Id: Ia73cce7546c9839518c9e931b03c50856abc2018
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16186
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Make the indication of the boot device being memory mapped
separate from SPI. However, retain the same defaults that
previously existed.
BUG=chrome-os-partner:56151
Change-Id: Ibdd7c8754f9bf560a878136b1f55238e2c2549d3
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16193
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This moves the Kconfig from the Super I/O manufacturer folder
to the chip folder instead.
This makes new chip commits self-contained unit as
edits to the central Kconfig file are no longer required.
Change-Id: I7aee07919f2ae9204850c669e0ed3cb17d4de8cd
Signed-off-by: Omar Pakker <omarpakker+coreboot@gmail.com>
Reviewed-on: https://review.coreboot.org/15973
Tested-by: build bot (Jenkins)
Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Instead of forcing the hardcoded 'devicetree.cb' filename under the
mainboard directory, this allows mainboards to select a filename for
the devicetree file.
This allows mainboard variants that need to use different devicetree
files to live under the same directory.
Change-Id: I761e676ba5d5f70d1fb86656b528f63db169fcef
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12529
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With VBOOT_VERIFY_FIRMWARE separated from CHROMEOS, move recovery and
developer mode check functions to vboot. Thus, get rid of the
BOOTMODE_STRAPS option which controlled these functions under src/lib.
BUG=chrome-os-partner:55639
Change-Id: Ia2571026ce8976856add01095cc6be415d2be22e
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15868
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
VBOOT_VERIFY_FIRMWARE should be independent of CHROMEOS. This allows use
of verified boot library without having to stick to CHROMEOS.
BUG=chrome-os-partner:55639
Change-Id: Ia2c328712caedd230ab295b8a613e3c1ed1532d9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15867
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enable the display of cbmem during romstage and postcar. Add a Kconfig
value to prevent coreboot images from increasing in size when this
feature is not in use.
TEST=Build and run on Galileo Gen2
Change-Id: Ib70ad517ebf7d37a7f46ba503b4432c7c04d7ded
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15842
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The lock stores need to migrate from CAR to CBMEM.
Change-Id: I3cffd14bdfc57d5588d0f24afe00e0f9891bfe5a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15588
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1
Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349850
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15294
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This Kconfig is deprecated, new platforms need to locate
ramstage stack in CBMEM instead.
Change-Id: I20ece297302321337cc2ce17fdef0c55242a4fc3
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15189
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Build the <board>_checklist.html file which contains a checklist table
for each stage of coreboot. This processing builds a set of implemented
(done) routines which are marked green in the table. The remaining
required routines (work-to-do) are marked red in the table and the
optional routines are marked yellow in the table. The table heading
for each stage contains a completion percentage in terms of count of
routines (done .vs. required).
Add some Kconfig values:
* CREATE_BOARD_CHECKLIST - When selected creates the checklist file
* MAKE_CHECKLIST_PUBLIC - Copies the checklist file into the
Documenation directory
* CHECKLIST_DATA_FILE_LOCATION - Location of the checklist data files:
* <stage>_complete.dat - Lists all of the weak routines
* <stage>_optional.dat - Lists weak routines which may be optionally
implemented
TEST=Build with Galileo Gen2.
Change-Id: Ie056f8bb6d45ff7f3bc6390b5630b5063f54c527
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15011
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Modern platforms like Apollolake do not use XIP for early stages. In
such cases, cbfs_prog_stage_load should check for NO_XIP_EARLY_STAGES
instead of relying on ARCH_X86 to decide if a stage is XIP.
Change-Id: I1729ce82b5f678ce8c37256090fcf353cc22b1ec
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15045
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The src/acpi/Kconfig was being sourced close to the top of the Kconfig
tree, which doesn't allow it to be overridden by mainboards or chipsets.
Moving it lower in the tree allows for the defaults to be overridden.
Change-Id: I0b100f5535c5f383e8c6db74d0024c5ff2e8c08d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14878
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The FLASHMAP_OFFSET config variable is used in lib/fmap.c, however
the fmdtool creates a fmap_config.h with a FMAP_OFFSET #define.
Those 2 values are not consistent. Therefore, remove the Kconfig
variable and defer to the #define generated by fmdtool.
Change-Id: Ib4ecbc429e142b3e250106eea59fea1caa222917
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14765
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Before multi-CBFS support was added, x86 platforms cached their
ramstage in TSEG so that it could be re-used on the resume
path. However, more resources/assets are being put in cbfs that are
utilized during ramstage. Just caching ramstage does not mean that
correct cbfs region is used for all the data. Thus, provide an option
to allow platforms to skip caching any component for resume.
Change-Id: I0e957a6b859cc7d700aaff67209a17c6558be5de
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14636
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of hard coding a #define in each architecture's
tables.c for the coreboot table size in cbmem use a Kconfig
varible. This aids in aligning on a common write_tables()
implementation instead of duplicating the code for each
architecture.
Change-Id: I09c0f56133606ea62e9a9c4c6b9828bc24dcc668
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14429
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make
them pluggable.
Also, fix up the following driver subdirectories by switching
to the src/drivers/[X]/[Y]/ scheme as these are hard requirements
for the main change:
* drivers/intel
* drivers/pc80
* drivers/dec
Change-Id: I455d3089a317181d5b99bf658df759ec728a5f6b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14047
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Instead of just defaulting to disabled, remove the option for
x86 since it doesn't work there.
Change-Id: I2b84b9f866f9231943e573b873c970f420c7c9a5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14017
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add the DEBUG_BOOT_STATE Kconfig value to enable boot state debugging.
Update include/bootstate.h and lib/hardwaremain.c to honor this value.
Add a dashed line which displays between the states.
Testing on Galileo:
* select DEBUG_BOOT_STATE in mainboard/intel/galileo/Kconfig
* Build and run on Galileo
Change-Id: I6e8a0085aa33c8a1394f31c030e67ab3d5bf7299
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch generalizes the approach previously used for ARM32
TTB_SUBTABLES to "auto-detect" whether a certain region was defined in
memlayout.ld. This allows us to get rid of the explicit Kconfig for the
TIMESTAMP region, reducing configuration redundancy and avoiding
confusion when setting up future boards.
(Removing armv4/bootblock_simple.c because it references this Kconfig
and it is a dead file that I just forgot to remove in CL:12076.)
BRANCH=None
BUG=None
TEST=Booted Oak and confirmed that all pre-RAM timestamps are still
there. Built Nyan and Falco.
Change-Id: I557a4b263018511d17baa4177963130a97ea310a
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13652
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We want the question for CBFS size to be next to the rom size in the
mainboard directory, but that doesn't seem to work for how people
want to set the defaults. Instead of having the list of exceptions
to the size, just set the defaults at the end of kconfig.
- Move the defaults for chipsets not setting HAVE_INTEL_FIRMWARE into
the chipset Kconfigs (gm45, nehalem, sandybridge, x4x)
- Override the default for HAVE_INTEL_FIRMWARE on skylake.
- Move the HAVE_INTEL_FIRMWARE default setting into the firmware
Kconfig file
- Move the location of the default CBFS_SIZE=ROM_SIZE to the end of
the top level kconfig file, while leaving the question where it is.
Test=rebuild Kconfig files before and after the change, verify that
they are how they were intended to be.
Note: the Skylake boards actually changed value, because they were
picking up the 0x100000 from HAVE_INTEL_FIRMWARE instead of the
0x200000 desired. This was due to the SOC_INTEL_SKYLAKE being after
the HAVE_INTEL_FIRMWARE default. Affected boards were:
Google chell, glados, & lars and Intel kunimitsu.
Change-Id: I2963a7a7eab037955558d401f5573533674a664f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13645
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Move the payloads section of the kconfig tree out of the top level
kconfig file and into a separate Kconfig just for payloads before
it starts to get added to.
Change-Id: I4f52818f862bf1aeba538c1c6ed93211a78b9853
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13608
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
- Add a target at the end of the build that can be used to run additional
scripts or additional targets after coreboot.rom is built.
- Source a site-local Kconfig file to allow site-specific configuration.
This eliminates the need to add a hook for a script at the end of the
build because you can add one yourself in site-local.
Example site-local/Makefile.inc:
build_complete::
ifeq ($(CONFIG_SITE_LOCAL),y)
echo "Running additional steps in site-local"
# run some script here to make my build unreproducible.
endif
.phony: build_complete
Example site-local/Kconfig:
menu "site-local"
config SITE_LOCAL
bool "site-local enabled"
help
Enable my site-local configuration to do stuff.
endmenu
Change-Id: Id4d1e727c69b5cdb05e7d52731bbb1d1e201864a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13413
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
We just had a user who spent a fair amount of time debugging a
failing build due to this option being enabled. Add a little
guidance that it probably shouldn't be enabled in the help text.
Change-Id: I9339e442876c1fcd18ea564041c6cc1201c18ae5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13066
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add a new Kconfig variable to enable the generation of
position and alignment attributes for cbfs files which
has constraints on this parameters.
In addition, modify Makefile.inc to support that option.
Change-Id: Ibd725fe69a4de35964bdb2dde106d9a7c37ffb47
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/12968
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
These are generated from depthcharge's board/*/fmap.dts using the
dts-to-fmd.sh script.
One special case is google/veyron's chromeos.fmd, which is used for a
larger set of boards - no problem since the converted fmd was the same
for all of them.
Set aside 128K for the bootblock on non-x86 systems (where the COREBOOT
region ends up at the beginning of flash). This becomes necessary
because we're working without a real cbfs master header (exists for
transition only), which carved out the space for the offset.
Change-Id: Ieeb33702d3e58e07e958523533f83da97237ecf1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12715
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
- While we're working on fixing clang for coreboot, mark it as not
currently working so that it doesn't look like a reasonable choice.
- Add help on how to make the toolchains
Change-Id: Ib37093ca98d0328fad40dd7886c98d00f78bd58e
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13053
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of depending BOOTBLOCK_CONSOLE on a set of architectures,
allow the arch or platform to specify whether it can provide a C
environment. This simplifies the selection logic.
Change-Id: Ia3e41796d9aea197cee0a073acce63761823c3aa
Signed-off-by: Alexandru Gagniuc <alexandrux.gagniuc@intel.com>
Reviewed-on: https://review.coreboot.org/12871
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Intel's SST (Smart Sound Technology) employs audio support
which may not consist of HDA. In order to define the topology
of the audio devices (mics, amps, codecs) connected to the
platform a NHLT specification was created to pass this
information from the firmware to the OS/userland.
BUG=chrome-os-partner:44481
BRANCH=None
TEST=Tested on glados. Audio does get emitted and some mic recording
works.
Change-Id: I8a9c2f4f76a0d129be44070f09d938c28a73fd27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 2472af5793dcffd2607a7b95521ddd25b4be0e8c
Original-Change-Id: If469f99ed1a958364101078263afb27761236421
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/312264
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/12935
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When microcode updates are enabled, this fixes an issue identical
to that described in GIT hash 7b22d84d:
* drivers/pc80: Add optional spinlock for nvram CBFS access
Change-Id: Ib7e8cb171f44833167053ca98a85cca23021dfba
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12063
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The FMD is board-specific, so it makes sense to have it in the
mainboard menu.
Change-Id: I52fba5ced869d51d10065f8c9ebd258d3a1d4156
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: https://review.coreboot.org/12805
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Boots to console on Gigabyte GA-G41M-ES2L
Ram initialization *not* included in this patch
VGA native init works on analog connector
Change-Id: I5262f73fd03d5e5c12e9f11d027bdfbbf0ddde82
Signed-off-by: Damien Zammit <damien@zamaudio.com>
Reviewed-on: https://review.coreboot.org/11305
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
When enabling the IOMMU on certain systems dmesg is spammed with I/O page faults like the following:
AMD-Vi: Event logged [IO_PAGE_FAULT device=00:14.0 domain=0x000a address=0x000000fdf9103300 flags=0x0030]
Decoding the faulting address:
0x000000fdf9103300
fdf91x Hypertransport system management region
33 SysMgtCmd (System Management Command) = 0x33
3 Base Command Type = 0x3: STPCLK (Stop Clock request)
3 SMAF (System Management Action Field) = [3:1] = 0x1
1 Signal State Bit Map = [0] = 0x1
Therefore, the error appears to be triggered by an upstream C1E request.
This was eventually traced to concurrent access to the SP5100's SPI Flash controller by
multiple APs during startup. Calls to the nvram read functions get_option and read_option
call CBFS functions, which in turn make near-simultaneous requests to the SPI Flash
controller, thus placing the SP5100 in an invalid state. This limitation is not documented
in any public AMD errata, and was only discovered through considerable debugging effort.
Change-Id: I4e61b1ab767b1b7958ac7c1cf20eee41d2261bef
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: https://review.coreboot.org/12061
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Martin Roth