There's only 2 users of checking if the event buffer is cleared
to the EOL value. Each were passing pointers of the in-memory
mirror while also doing calculations for the size to check. Since
the in-memory mirror is one big buffer the only thing required
to know is the offset to start checking from. The check is always
done through the end of the buffer.
BUG=chrome-os-partner:55932
Change-Id: Icd4a7edc74407d6578fc93e9eb533abd3aa17277
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16096
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Idfd1bd8240413026b992ae1382a57bccf9d8ddb5
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16082
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The mainboard chip.h files were (mostly) removed long ago.
Change-Id: I1d5a9381945427c96868fa17756e6ecabb1048b2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16080
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The command line parameters for these modes haven't worked in two
years and nobody noticed. They're obviously not getting used, so
remove them.
TEST=Generate static.c before and after the change, verify they're
identical.
Change-Id: I1d746fb53a2f232155f663f4debc447d53d4cf6b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16079
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of having directories and file names hardcoded, pass in the full
path and filename of both the input and output files.
In the makefile, create variables for these values, and use them in
places that previously had the names and paths written out.
Change-Id: Icb6f536547ce3193980ec5d60c786a29755c2813
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16078
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.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>
Instead of taking pointers and back-calculating the
proper offset perform writes in terms of the offsets
within the elog region in flash.
BUG=chrome-os-partner:55932
Change-Id: I5fd65423f5a6e03825c788bc36417f509b58f64d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16095
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Allocating a 15980-byte scratchpad on the stack when your default stack
size is set to 16KB is really not a great idea. We're regularly
overflowing into the end of our heap when using LZMA in libpayload, and
just happen not to notice it because the heap rarely gets filled up all
the way. Of course, since we always *have* a heap in libpayload, the
much saner solution is to just use it directly to allocate the
scratchpad rather than accidentally grow backwards into it anyway.
Change-Id: Ibe4f02057a32bd156a126302178fa6fcab637d2c
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16089
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The elog_flash_erase() was only called to erase the entire
elog region in flash. Therefore, drop the parameters and
perform the full erase.
BUG=chrome-os-partner:55932
Change-Id: I6590347ae60d407bc0df141e9196eb70532f8585
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16094
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
There was a check against the next event offset against
the shrink size in elog_shrink(). However, all calls
to elog_shrink() were conditionalized on the next
event offset exceeding the full threshold. The shrink
size is set to the minimum of the full threshold and
a percentage of the elog region size. Therefore, it's
impossible for the next event offset to be less than
the shrink size because full threshold is always greater
than or equal to the shrink size.
BUG=chrome-os-partner:55932
Change-Id: Ie6ff106f1c53c15aa36a82223a235a7ac97fd8c7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16093
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
For the elog shrink case we log the number of bytes shrunk
from the event log. However, when clearing the log the
size recorded was the entire region size including the header
as well as the event region space. To be more consistent
mark the clearing event with the number of bytes actually
cleared out (excluding the header size).
BUG=chrome-os-partner:55932
Change-Id: I7c33da97bd29a90bfe975b1c6f148f181016f13f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16092
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The gsmi_exec() expects the parameter to be a pointer
to the 32-bit register storage of the SMI save state.
The previous code was passing a pointer with the value
obtained from the saved-state -- not a pointer to the
storage of the register value. This bug causes gsmi
to not log events because it's interrogating the
parameter buffer itself as if it were a pointer.
BUG=chrome-os-partner:55932
Change-Id: I37981424f1414edad1456b31cad1b99020d57db6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16087
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Since RTC is now a Kconfig ensure RTC is selected on the
x86 chipsets which are in Chrome OS devices. This allows
the eventlog to have proper timestamps instead of all
zeros.
BUG=chrome-os-partner:55993
Change-Id: I24ae7d9b3bf43a5791d4dc04aae018ce17fda72b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16086
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
The buffer for writeat() should be marked as const as
the contents won't be manipulated within the call.
BUG=chrome-os-partner:55932
Change-Id: I968570c1cf80f918a07b97af625a56f11b5889c1
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16084
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
List of changes done here in this patch
1. Remove CARD definition from EMMC and SD Card Controller in scs.asl
since _RMV method does not get evaluated while setting up removable
attribute in sysfs in kernel.
"cat /sys/block/mmcblk1/removable" this command always returns 0.
This CARD Device includes _ADR which follows SDIO Bus format. But,
SD/EMMC sits on PCI Bus.
Hence this CARD Device specific _ADR code is also not needed.
2. Remove Base Address for ACPI debug output memory buffer in
systemagent.asl as it is not getting used throughout the code.
BUG=none
BRANCH=none
TEST=Build and boot kunimitsu
Change-Id: I29effaffdafcc21e26445ec3c54aedecdbc50274
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16068
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Program PIRQ Routing with correct values, as done by FSP, and also in
'soc/intel/skylake/romstage/pch.c' file. If not done, these values get
overridden by "0" during PxRC -> PIRQ programming in ramstage, in
'soc/intel/skylake/lpc.c' file pch_pirq_init()function.
BUG=none
BRANCH=none
TEST=Build and boot kunimitsu
Change-Id: Ibeb9a64824a71c253e45d6a1c6088abd737cf046
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16044
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Here is the list of items of code cleanup
1. Define TCO registers in smbus.h and not in pmc.h (as per EDS).
2. Include smbus.h wherever these TCO register defines were used.
3. Remove duplication of define in gpio_defs.h.
4. Remove unnecessary console.h include from memmap.h as no prints done.
5. Remove unnecessary comment from pch.c.
BUG=none
BRANCH=none
TEST=Built and boot kunimitsu.
Change-Id: Ibe6d2537ddde3c1c7f8ea5ada1bfaa9be79c0e3b
Signed-off-by: Barnali Sarkar <barnali.sarkar@intel.com>
Reviewed-on: https://review.coreboot.org/16027
Tested-by: build bot (Jenkins)
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
If the CONFIG_CCACHE variable is NOT set, define the CCACHE variable as
blank on the Chrome EC make command line. This will overrride and
disable the CCACHE variable in the Chrome EC makefile.
Change-Id: Idb1da06941084cea104d77748820971edf151f7b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16035
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The ARM64 MMU code maintains a list of used ranges, to avoid mapping the
DMA buffer over the coreboot tables and things like that. Unfortunately,
the overlap with ranges in that list is checked with
(start1 >= start2 && start1 <= end2) || (end1 >= start2 && end1 <= end2)
which is not a full overlap check and misses the case where the second
region is completely contained within the first. This patch replaces
that code with a properly vetted primitive from Stack Overflow.
BRANCH=none
BUG=chrome-os-partner:54416
TEST=Observe how Kevin recovery screen now gets drawn at 10x the speed.
Change-Id: I7e2706426762794e160d743bbfc40da1e26eee12
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16075
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of writing the first word of 6 "post code structs" where only
one exists (leading to 0xDEAD and 5 garbage words), write the correct
set.
Change-Id: Ifdfa53a970dda33dc9dc8c05788875077c001ecf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1361054, #1361055, #1361056
Reviewed-on: https://review.coreboot.org/16058
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This relieves caller from having to check if the parameter being passed
in is NULL.
Change-Id: I3ea935c12d46c6fb5534e0f2077232b9e25240f1
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16076
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This replaces all occurrences of a hardcoded vboot path to the
VBOOT_SOURCE variable, that may be overridden from the command line,
witch fallback to the source from 3rdparty.
Change-Id: Ia57d498d38719cc71e17060b76b0162c4ab363ed
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15825
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Adding kabylake device ids for chip inits.
Skylake and Kabylak do not differ much, the intention
is to support both SoCs in the same code base.
Change-Id: I9ff4c6ca08fe681798001ce81cca2c085ce32325
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16049
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Enable I2C bus 2 for early init so it can be used by vboot for TPM
communication for verifying the memory init code.
BUG=chrome-os-partner:53336
BRANCH=none
TEST=build and boot on reef
Change-Id: Id4940ab01d8ccf288ab0a7a9a2f19867ed464e8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16059
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Generate an object to describe the coreboot table region in ACPI
with the HID "CORE0000" so it can be used by kernel drivers.
To keep track of the "CORE" HID usage add them to an enum and add
a function to generate the HID in AML: Name (_HID, "CORExxxx")
BUG=chromium:589817
BRANCH=none
TEST=build and boot on chell, dump SSDT to verify contents:
Device (CTBL)
{
Name (_HID, "CORE0000") // _HID: Hardware ID
Name (_UID, Zero) // _UID: Unique ID
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
Memory32Fixed (ReadOnly,
0x7AB84000, // Address Base
0x00008000, // Address Length
)
})
}
Change-Id: I2c681c1fee02d52b8df2e72f6f6f0b76fa9592fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16056
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The -b FSP_LOC argument to cbfstool is only valid for the COREBOOT
CBFS. Don't pass that value for all other CBFS regions.
Change-Id: Ib5321e7a7dbee8d26eb558933c8ce3fea50b11fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14641
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
If EC_GOOGLE_CHROMEEC is enabled, ensure that the EC is in correct mode
before running memory init. This saves additional memory training
required in recovery path because of reboot later in ramstage.
BUG=chrome-os-partner:54245
Change-Id: Ic71c054afdcd0001cea95563fe513783b56f3e60
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/16034
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
SD CLK and CLK_FB needs to be pulled down by 20K.
SD CD_N is active LOW, needs to be pulled up by 20K
SD WP pin is not connected for uSD cards, enable writes
by default by pulling low by 20K.
BUG=chrome-os-partner:54866
BRANCH=None
TEST=Test with uSD cards.
Change-Id: Ia4bbd966ffb21e276dfc31a74f4ea54718900d66
Signed-off-by: Chiranjeevi Rapolu <chiranjeevi.rapolu@intel.com>
Reviewed-on: https://review.coreboot.org/16057
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add missing breaks in reg_access.c.
TEST=Build and run on Galileo Gen2
Found-by: Converity Scan #1361261
Change-Id: I8be57f0758e5918a605e20ab9002747e0cc958e0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16069
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
The first attempt of providing a options-for-region function to call
to determining a file's cbfstool options would work, but it means there
can only be one instance which has to handle all of the files that may
need an override. That logic can be problematic in impelementation.
Instead, provide a mechanism to target cbfstool options for a given
CBFS region where the implementation is tightly coupled in the build
system to where the file as requested to be added to cbfs. This allows
there to be a base set of cbfstool options while more easily extending
arguments on specific regions.
Example which adds '-b 0x10000' only for the COREBOOT CBFS region:
cbfs-files-y += file.bin
file.bin-COREBOOT-cbfstool-opts := -b 0x10000
Change-Id: Idfafb0205be42768adb04bb0a30fe46a9ca1bd57
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14640
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Although we have already support for the flash chip N25Q128 there is a
similar type available which has the same geometry and opcodes but
unfortunately a slightly different device type ID. While the already
supported N25Q128 has the ID 0xbb18 this one has the ID 0xba18.
To make both types available in the flash support table, use N25Q128A as
the flash name. This name can be found in the datasheet which can be
found here:
https://www.micron.com/~/media/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_128mb_3v_65nm.pdf
TEST=Booted and verified that MRC cache could be written
Change-Id: I02a47692efb23a9a06a289c367488abd256b8e0c
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/16061
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Add the Kconfig value to point to the checklist data files.
TEST=Build and run on Galileo Gen2
Change-Id: I3737b46162214fad139382193de944ec5d175645
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16039
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add the bootblock_c_entry routine to make it more explicit where the
code transitions from assembler to C.
TEST=Build and run on Galileo Gen2
Change-Id: Ib5f580c30b58d3c82fedddf63c368e617d401515
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16064
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change the debug output levels for quark:
* Remove excess debug output
* Change BIOS_DEBUG to BIOS_SPEW - exception in report_platform.c
TEST=Build and run on Galileo Gen2
Change-Id: I37d7ed21a7fc4c92efeb5b71dd01922d7d4b9192
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16006
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Disable FSP output when CONFIG_DEFAULT_CONSOLE_LOGLEVEL is not set to 8
(BIOS_SPEW). Use the console log level to choose between the serial
port address and NULL and pass it to FSP for the serial port address.
TEST=Build and run on Galileo Gen2.
Change-Id: I5498aad218524c211082d85d0ae9aacaf08a80f6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16005
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add the pieces necessary to successfully build and run romstage using
the FSP 2.0 build. Because romstage is using postcar, add the postcar
pieces so that romstage can attempt to load postcar.
TEST=Build and run on Galileo Gen2
Change-Id: I66b3437e3c7840223535f6ab643599c9e4924968
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15866
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add the pieces necessary to successfully build and run bootblock using
the FSP 2.0 build.
TEST=Build and run bootblock on Galileo Gen2
Change-Id: I2377f0b0147196f100396b8cd7eaca8f92d6932f
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15865
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Linux' newest checkpatch.pl flags comments like these:
/* This is a concise 2-line comment that explains what the code does in
* sufficient detail without wasting too much vertical space. */
do_stuff_that_needs_explaining();
Comments like these have been used in our code base for a long time and
I don't think we should disallow them now. Ending the comment on the
same line doesn't really hurt readability and wastes less screen real
estate (which in turn usually helps overall code comprehension).
Change-Id: Ifd57f3d3a62738165024cb4b2e75a4f815a57922
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16060
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Half a year has passed. Fixes went in. Probably bugs, too.
However, nobody really supports our local vboot version anymore.
Change-Id: I5042f23686dfe98e540c482f744e9df2d7df3b19
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/16055
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Paul Kocialkowski <contact@paulk.fr>
The old text said:
*** building <STAGE> without the required toolchain. Stop.
Where <STAGE> could be any of the coreboot stages - bootblock, verstage,
ramstage, romstage.
This error message was very misleading though, because what it actually
meant was that it didn't know what architecture was required to build
the stage, not that the toolchain was missing.
Update the text to better reflect the actual issue, and to give the
user a hint as to what to look for:
*** The toolchain architecture for <STAGE> is unknown.
*** Check your .config file for CONFIG_ARCH_<STAGE>_* settings. Stop.
Change-Id: Ic2a4f60c1f25e0f5e1ebde76781bcb8da0987d82
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16024
Tested-by: build bot (Jenkins)
Reviewed-by: Omar Pakker
Port commit e08493 to the SB700 platform
Change-Id: Ie18c6cc0ccb31a0d16a80fcb4c2e147c19e228fe
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
Reviewed-on: https://review.coreboot.org/16054
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In some cases, we don't want the Chrome EC firmwares (both EC and PD)
built directly by the coreboot build system or included in images at
all. This is already supported with EC_EXTERNAL_FIRMWARE but it does
implement a binary (build and include) or (neither build nor include)
policy.
Some cases require the ability to separately control whether the EC
and PD firmwares should be built and included by the coreboot build
system, only included from externally-built images or not included
at all.
This introduces config changes implementing that behaviour, renaming
options to make it clear that they are specific to the Chrome EC.
Change-Id: I44ccee715419360eb7d83863f4f134fcda14a8e4
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/16033
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Aaron Durbin