The maximum ACPI table size is currently hardcoded to 144 KiB.
When using QEMU with TPM enabled there is ~200 KiB of ACPI tables
returned by the fw_cfg interface, so in order to allow this to be
overridden by a mainboard move it to Kconfig.
This is seen when using a TPM with qemu as it will hang when
processing the fw_cfg tables.
qemu-system-x86_64 \
-machine q35 -enable-kvm -vga virtio -serial stdio \
-drive 'id=hd,file=disk.bin' -bios coreboot.rom \
-chardev 'socket,id=swtpm,path=/tmp/swtpm/swtpm-sock' \
-tpmdev 'emulator,id=tpm0,chardev=swtpm' \
-device 'tpm-tis,tpmdev=tpm0'
Change-Id: Ib5baa8fe12cb9027a340875f1ccf5fef6f9460bd
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39832
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The ACPI Spec 2.0 states, that Processor declarations should be made
within the ACPI namespace \_SB and not \_PR anymore. \_PR is deprecated
and is removed here for Intel CPUs only.
Tested on:
* X11SSH (Kabylake)
* CFL Platform
* Asus P8Z77-V LX2 and Windows 10
FWTS does not return FAIL anymore on ACPI tests
Tested-by: Angel Pons <th3fanbus@gmail.com>
Change-Id: Ib101ed718f90f9056d2ecbc31b13b749ed1fc438
Signed-off-by: Christian Walter <christian.walter@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37814
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
This also drops individual copyright notices, all mentioned authors in
that part of the tree are listed in AUTHORS.
Change-Id: Ib5a92bb46ff2b9d2928aae3763daec71747044c2
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39284
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Also, don't define the default as this results in spurious lines in the
.config.
TEST: Build all boards with where config.h differed with
BUILD_TIMELESS=1 and remained the same
Change-Id: Ic77b696f493d7648f317f0ba0a27fdee5212961e
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31316
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Prepare for an implementation supporting the reset vector in RAM and
not the traditional 0xfffffff0. Add a Kconfig symbol that can be used
in place of hardcoded values.
Change-Id: I6a814f7179ee4251aeeccb2555221616e944e03d
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37485
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The romcc bootblock will be deprecated soon and most platforms use
C_ENVIRONMENT_BOOTBLOCK already. This patch drops the
CONFIG_C_ENVIRONMENT_BOOTBLOCK symbol and adds CONFIG_ROMCC_BOOTBLOCK
where needed.
Change-Id: I773a76aade623303b7cd95ebe9b0411e5a7ecbaf
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/37154
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
All targets now have the _cbmem_top_ptr symbol populated via calling
arguments or in the nvidia/tegra210 case worked around by populating
it with cbmem_top_chipset explicitly at the start of ramstage, so the
Kconfig guarding this behavior can be removed.
Change-Id: Ie7467629e58700e4d29f6e735840c22ed687f880
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36422
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Michael Niewöhner
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add support for x86_64 bootblock on qemu.
Introduce a new approach to long mode support. The previous patch set
generated page tables at runtime and placed them in heap. The new
approach places the page tables in memory mapped ROM.
Introduce a new tool called pgtblgen that creates x86 long mode compatible
page tables and writes those to a file. The file is included into the CBFS
and placed at a predefined offset.
Add assembly code to load the page tables, based on a Kconfig symbol and
enter long in bootblock.
The code can be easily ported to real hardware bootblock.
Tested on qemu q35.
Change-Id: Iec92c6cea464c97c18a0811e2e91bc22133ace42
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35680
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Currently all stages that need cbmem need an implementation of a
cbmem_top function. On FSP and AGESA platforms this proves to be
painful and a pointer to the top of lower memory if often passed via
lower memory (e.g. EBDA) or via a PCI scratchpad register.
The problem with writing to lower memory is that also need to be
written on S3 as one cannot assume it to be still there. Writing
things on S3 is always a fragile thing to do.
A very generic solution is to pass cbmem_top via the program argument.
It should be possible to implement this solution on every
architecture.
Instead trying to figure out which files can be removed from stages
and which cbmem_top implementations need with preprocessor, rename all
cbmem_top implementation to cbmem_top_romstage.
TESTED on qemu-x86.
Change-Id: I6d5a366d6f1bc76f26d459628237e6b2c8ae03ea
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/36144
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
As discussed on the mailing list and voted upon, the coreboot project
is going to move the majority of copyrights out of the headers and into
an AUTHORS file. This will happen a bit at a time, as we'll be unifying
license headers at the same time.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: Ifd4329905847d9dd06de67b9a443c8ee50c0e7a7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35177
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Create a new Kconfig symbol that allows an x86 device to begin execution
when its reset vector is in DRAM and not at the traditional 0xfffffff0.
The implementation will follow later, this is just to setup various
ENV_xxx definitions correctly for the build environment.
Change-Id: I098ecf8bf200550db1e15f178f7661c1ac516dc5
Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/35004
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
It is easier to track CAR_GLOBAL_MIGRATION which is
the approach to be deprecated with the next release.
This change enforces new policy; POSTCAR_STAGE=y is
not allowed together with CAR_GLOBAL_MIGRATION=y.
Change-Id: I0dbad6a14e68bf566ac0f151dc8ea259e5ae2250
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34804
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This code is currently only used by via/epia-m850,
it is also somewhat buggy.
Change-Id: I140e15d584d3f60f7824bcb71ce63724c11e3f46
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/34078
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Selecting which cbfs prefix to load is only implemented with the romcc
bootblock.
Change-Id: I09523b94605f00ab15b5f0ea3986ac08e3a6afc6
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/33341
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Fixes building vb2lib for postcar. Since postcar is an x86ism, add the
Kconfig options only for x86.
Change-Id: Ib92436bc7270c24689dcf01a47f0c6fe7661814b
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/29395
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
It's very common across many x86 silicon vendors, so place it in
`arch/x86/`.
Change-Id: I06c27afa31e5eecfdb7093c02f703bdaabf0594c
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/29054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Bounce buffers used to be used in those cases where the payload
might overlap coreboot.
Bounce buffers are a problem for rampayloads as they need malloc.
They are also an artifact of our x86 past before we had relocatable
ramstage; only x86, out of the 5 architectures we support, needs them;
currently they only seem to matter on the following chipsets:
src/northbridge/amd/amdfam10/Kconfig
src/northbridge/amd/lx/Kconfig
src/northbridge/via/vx900/Kconfig
src/soc/intel/fsp_baytrail/Kconfig
src/soc/intel/fsp_broadwell_de/Kconfig
The first three are obsolete or at least could be changed
to avoid the need to have bounce buffers.
The last two should change to no longer need them.
In any event they can be fixed or pegged to a release which supports
them.
For these five chipsets we change CONFIG_RAMBASE from 0x100000 (the
value needed in 1999 for the 32-bit Linux kernel, the original ramstage)
to 0xe00000 (14 Mib) which will put the non-relocatable x86
ramstage out of the way of any reasonable payload until we can
get rid of it for good.
14 MiB was chosen after some discussion, but it does fit well:
o Fits in the 16 MiB cacheable range coreboot sets up by default
o Most small payloads are well under 14 MiB (even kernels!)
o Most large payloads get loaded at 16 MiB (especially kernels!)
With this change in place coreboot correctly still loads a bzImage payload.
Werner reports that the 0xe00000 setting works on his broadwell systems.
Change-Id: I602feb32f35e8af1d0dc4ea9f25464872c9b824c
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/28647
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove the last bits of building romstage with romcc.
Change-Id: I70bb1ed23a5aeb87bf7641e0b0bd604a4e622e61
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26807
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Symbol defined in via/cx700 but also used elsewhere.
Change-Id: I31d6043e71dea474de00f609b9609a628ecc6eb8
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/26510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Add Kconfig IDT_IN_EVERY_STAGE to optionally specify having
the interrupt handling code available to all stages. In order
to do this the idt setup is moved to a C module. The vecX
entries are made global so that a table of references to all
the interrupt vector entry points can be used to dynamically
initialize the idt. The ramification for ramstage is that
exceptions are initialized later (lib/hardwaremain.c). Not
all stages initialize exceptions when this Kconfig variable
is selected, but bootblock for the C, stages using
assembly_entry.S, and of course ramstage do. Anything left
out just needs a call to exception_init() at the right
location.
BUG=b:72728953
Change-Id: I4146a040e5e43bed7ccc6cb0a7dc2271f1e7b7fa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25761
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Processors, such as glk, need to have paging enabled while
in cache-as-ram mode because the front end is agressive about
fetching lines into the L1I cache. If the line is dirty and in
the L1D then it writes it back to "memory". However, in this case
there is no backing store so the cache-as-ram data that was written
back transforms to all 0xff's when read back in causing corruption.
In order to mitigate the failure add x86 architecture support for
enabling paging while in cache-as-ram mode. A Kconfig variable,
NUM_CAR_PAGE_TABLE_PAGES, determines the number of pages to carve
out for page tables within the cache-as-ram region. Additionally,
the page directory pointer table is also carved out of cache-as-ram.
Both areas are allocated from the persist-across-stages region
of cache-as-ram so all stages utilizing cache-as-ram don't corrupt
the page tables.
The two paging-related areas are loaded by calling
paging_enable_for_car() with the names of cbfs files to load the
initial paging structures from.
BUG=b:72728953
Change-Id: I7ea6e3e7be94a0ef9fd3205ce848e539bfbdcb6e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/25717
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
Some x86 platforms don't have a TSC that is invariant w.r.t.
rate to get accurate timestamps. As such a different timestamp
is required. Therefore, allow one to specify non-TSC timestamp
source and not compile in the default x86 TSC code.
BUG=b:72378235,b:72170796
Change-Id: I737fcbba60665b3bc2b5864269536fda78b44d90
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Justin TerAvest <teravest@chromium.org>
This patch provides a kconfig option as EARLY_EBDA_INIT to
ensures user can make use of EBDA library even during early
boot stages like romstage, postcar.
Change-Id: I603800a531f56b6ebd460d5951c35a645fbfe492
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/21388
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The deprecation of late (post-romstage) CBMEM initialization was
announced in this blog post:
https://blogs.coreboot.org/blog/2017/05/08/announcing-coreboot-4-6/
There are two warnings:
* In LATE_CBMEM_INIT's help text, I've added a multi-line warning, that
aims to explain the problem.
* In src/mainboard/Kconfig (just below the mainboard selection), there's
a warning which points the user at LATE_CBMEM_INIT, if such a board is
selected.
Also update the function that needs to be implemented, as pointed out by
Keith Hui and Kyösti Mälkki.
Change-Id: I2d21a6ab2fc2811d44fc4febb05841bb2f8d1857
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/21112
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add a Kconfig option to change the \PR.CPxx name string. This
provides some flexibility when working with table not generated
by coreboot.
Change-Id: Ibc0c56783c6da80501e2177de96a414b592cb74f
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/21210
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
AGESA and binaryPI boards have no easy way to determine correct
cbmem_top() location early enough when GFXUMA is enabled, so they
will use these functions with EARLY_CBMEM_INIT as well.
At the end of AmdInitPost() the decisions of UMA base and size
have not been written to hardware yet. The decisions are stored
inside AGESA heap object we cannot locate from coreboot proper
until after AmdInitEnv().
Modify code such that weak backup functions are only defined
for LATE_CBMEM_INIT; they are somewhat troublesome to handle.
Change-Id: Ifef4f75b36bc6dee6cd56d1d9164281d9b2a4f2a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/19306
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When a platform is using postcar stage it's by definition not
tearing down cache-as-ram from within romstage prior to loading
ramstage. Because of this property there's no need to migrate
CAR_GLOBAL variables to cbmem.
Change-Id: I7c683e1937c3397cbbba15f0f5d4be9e624ac27f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19215
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
The four options are only used in X86:
- BOOTBLOCK_SIMPLE
- BOOTBLOCK_NORMAL
- BOOTBLOCK_SOURCE
- SKIP_MAX_REBOOT_CNT_CLEAR
Move them all into src/arch/x86/Kconfig - this puts them in the chipset
menu instead of general setup.
Verified that this makes no significant changes to any config file.
Change-Id: I2798ef67a8c6aed5afac34322be15fdf0c794059
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17909
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Sometime preram cbmem logs are truncated due to lack of
space (default preram cbmem console size is 0xc00).
Provide Kconfig option to configure preram cbmem console
size so that mainboard can configure it to required value.
Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17839
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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>
Not all x86 architectures support the mm register set. The default
routine that saves BIST in mm0 and a "weak" routine that saves the TSC
value in mm2:mm1. Select the Kconfig value
BOOTBLOCK_SAVE_BIST_AND_TIMESTAMP to provide a replacement routine to
save the BIST and timestamp values.
TEST=Build and run on Amenia and Galileo Gen2.
Change-Id: I8119e74664ac3522c011767d424d441cd62545ce
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15126
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use Kconfig values to enable debug spinloops in assembly_entry.S. This
makes it easy to debug the assembly code.
TEST=Build and run on Galileo Gen2
Change-Id: Ic56bf2260b8e3181403623961874c9289f3ca945
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15135
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Conditionally add a debug spinloop to enable easy connection of JTAG
debuggers.
TEST=Build and run on Galileo Gen2 with a JTAG debugger.
Change-Id: I7a21f9e6bfb10912d06ce48447c61202553630d0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15127
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Certain chipsets don't have a memory-mapped boot media
so their code execution for stages prior to DRAM initialization
is backed by SRAM or cache-as-ram. The postcar stage/phase
handles the cache-as-ram situation where in order to tear down
cache-as-ram one needs to be executing out of a backing
store that isn't transient. By current definition, cache-as-ram
is volatile and tearing it down leads to its contents disappearing.
Therefore provide a shim layer, postcar, that's loaded into
memory and executed which does 2 things:
1. Tears down cache-as-ram with a chipset helper function.
2. Loads and runs ramstage.
Because those 2 things are executed out of ram there's no issue
of the code's backing store while executing the code that
tears down cache-as-ram. The current implementation makes no
assumption regarding cacheability of the DRAM itself. If the
chipset code wishes to cache DRAM for loading of the postcar
stage/phase then it's also up to the chipset to handle any
coherency issues pertaining to cache-as-ram destruction.
Change-Id: Ia58efdadd0b48f20cfe7de2f49ab462306c3a19b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14140
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This option is no longer needed, as FMAP support has been
fully integrated in coreboot
Change-Id: I6121b31bf946532717ba15e12f5c63d2baa95ab2
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
