Only SOC_INTEL_BRASWELL is using FSP1.1. It has too little CAR
available set up by FSP-T to have VBOOT_STARTS_IN_BOOTBLOCK and
therefore verstage is not possible either.
Change-Id: I54361c835055907c2a4414ec26a1495425d4ef09
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52785
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
We had the addrspace_32bit rdev in prog_loaders.c for a while to help
represent memory ranges as an rdev, and we've found it useful for a
couple of things that have nothing to do with program loading. This
patch moves the concept straight into commonlib/region.c so it is no
longer anchored in such a weird place, and easier to use in unit tests.
Also expand the concept to the whole address space (there's no real need
to restrict it to 32 bits in 64-bit environments) and introduce an
rdev_chain_mem() helper function to make it a bit easier to use. Replace
some direct uses of struct mem_region_device with this new API where it
seems to make sense.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ie4c763b77f77d227768556a9528681d771a08dca
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52533
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new configuration low_power_probe to avoid camera privacy LED
blink during the boot.
Change-Id: I27d5c66fb380ae6cd76d04ee82b7736407dac1b0
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Signed-off-by: Sugnan Prabhu S <sugnan.prabhu.s@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52189
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Traditionally, for each Intel platform using FSP, FSP-S has at some
point configured GPIOs differently than the mainboard configuration in
coreboot. This has resulted in various side-effects in coreboot,
payload and OS because of misconfigured GPIOs. On more recent Intel
platforms, a UPD `GpioOverride` is added that coreboot can use to
ensure that FSP does not touch any GPIO configuration.
This change adds a debug option `CHECK_GPIO_CONFIG_CHANGES` to fsp2_0
driver in coreboot that makes a platform callback `gpio_snapshot` to
snapshot GPIO configuration before making a call to FSP SiliconInit
and Notify phases. This snapshot is then compared against the GPIO
configuration using platform callback `gpio_verify_snapshot` after
returning from FSP. The callbacks are not added to romstage (FSP-M)
because mainboard configures all pads in ramstage.
This debug hook allows developers to dump information about any pads
that have a different configuration after call to FSP in ramstage. It
is useful to identify missed UPD configurations or bugs in FSP that
might not honor the UPDs set by coreboot.
This debug hook expects the platform to implement the callbacks
`gpio_snapshot` and `gpio_verify_snapshot`. These can be implemented
as part of the common GPIO driver for platforms using
FSP2.0+. Platforms that implement this support must select the config
`HAVE_GPIO_SNAPSHOT_VERIFY_SUPPORT` to make the debug config
`CHECK_GPIO_CONFIG_CHANGES` visible to user.
Proposal for the GPIO snapshot/verify support was discussed in the RFC
CB:50829.
Signed-off-by: Furquan Shaikh <furquan@google.com>
Change-Id: I5326fc98b6eba0f8ba946842253b288c0d42c523
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50989
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch changes the Intel MMA driver to use the new CBFS API.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Icc11d0c2a9ec1bd7a1d6af362f849dac16375433
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch ports the last remaining use of cbfs_boot_locate() in the
Intel FSP drivers to the new CBFS API. As a consequence, there is no
longer a reason for fsp_validate_component() to operate on rdevs, and
the function is simplified to take a direct void pointer and size to a
memory-mapping of the FSP blob instead.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If1f0239eefa4542e4d23f6e2e3ff19106f2e3c0d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52281
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
DPTF HIDs are different per-platform going forward, so refactor these
into SoC-specific structures which the DPTF driver can query at runtime
for platform-specific information.
Change-Id: I6307f9d28f4274b851323ad69180ff4ae35053da
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52220
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
The only FSP 1.1 platform with MMA support is Skylake. As it now uses
Kaby Lake FSP 2.0, this code is no longer useful. Drop it.
Change-Id: I819c3152bdea0fdad629793d96136ef134429fbd
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51951
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
The Intel FSP 2.0 driver contains a custom construct that basically
serves the same purpose as the new CBFS allocator concept: a callback
function to customize placement of a loaded CBFS file whose size is
initially unknown. This patch removes the existing implementation and
replaces it with a CBFS allocator.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I0b7b446a0d2af87ec337fb80ad54f2d404e69668
Reviewed-on: https://review.coreboot.org/c/coreboot/+/52082
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Until now every AML package had to be closed using acpigen_pop_len().
This commit introduces set of package closing functions corresponding
with their opening function names. For example acpigen_write_if()
opens if-statement package, acpigen_write_if_end() closes it.
Now acpigen_write_else() closes previously opened acpigen_write_if(),
so acpigen_pop_len() is not required before it.
Signed-off-by: Jakub Czapiga <jacz@semihalf.com>
Change-Id: Icfdc3804cd93bde049cd11dec98758b3a639eafd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50910
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Lance Zhao
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Since prog_locate() was eliminated, prog_rdev() only ever represents the
loaded program in memory now. Using the rdev API for this is unnecessary
if we know that the "device" is always just memory. This patch changes
it to be represented by a simple pointer and size. Since some code still
really wants this to be an rdev, introduce a prog_chain_rdev() helper to
translate back to that if necessary.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If7c0f1c5698fa0c326e23c553ea0fe928b25d202
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46483
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch rewrites the last few users of prog_locate() to access CBFS
APIs directly and removes the call. This eliminates the double-meaning
of prog_rdev() (referring to both the boot medium where the program is
stored before loading, and the memory area where it is loaded after) and
makes sure that programs are always located and loaded in a single
operation. This makes CBFS verification easier to implement and secure
because it avoids leaking a raw rdev of unverified data outside the CBFS
core code.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I7a5525f66e1d5f3a632e8f6f0ed9e116e3cebfcf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49337
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
EFI_PEI_MP_SERVICES_STARTUP_ALL_APS passes in a boolean flag singlethread
which indicates whether the work should be scheduled in a serially on all APs
or in parallel. Current implementation of this function mp_startup_all_aps
always schedules work in parallel on all APs. This implementation ensures
mp_startup_all_aps honors to run serialized request.
BUG=b:169114674
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Change-Id: I4d85dd2ce9115f0186790c62c8dcc75f12412e92
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51085
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use lowercase `port` in both the spec and the body.
Change-Id: I3d1e2abe03eedcaf57716af444a3e3b8a61b60d4
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/51146
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
RAM is not yet configured in bootblock. This function was copy-pasted
from Broadwell. Also, Skylake no longer uses FSP 1.1 and the stubs in
there can be removed as nothing else uses them.
Change-Id: I22cb7e63ed1e9565934296fd40771130ba91d227
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50949
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From JSL FSP v2376 "FirmwareVersionInfo.h" header file is
added and "FirmwareVersionInfoHob.h" is deprecated. This patch
adds support to display firmware version information using
"FirmwareVersionInfo.h" header file.
Changes included in this patch:
- Add Kconfig to select FirmwareVersionInfo.h
- Add code change to display firmware version info using
FirmwareVersionInfo.h header
No change in version info print format.
BUG=b:153038236
BRANCH=None
TEST=Verify JSLRVP build with all the patch in relation chain
and verify the version output prints no junk data observed.
couple of lines from logs are as below.
Display FSP Version Info HOB
Reference Code - CPU = 8.7.16.10
uCode Version = 0.0.0.1
Change-Id: I50f7cae9ed4fac60f91d86bdd3e884956627e4b5
Signed-off-by: Ronak Kanabar <ronak.kanabar@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45905
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Maulik V Vaghela <maulik.v.vaghela@intel.com>
FSP expects mp_get_processor_info to give processor specfic apic ID,
core(zero-indexed), package(zero-indexed) and thread(zero-indexed) info.
This function is run from BSP for all logical processor, With current
implementation the location information returned is incorrect per logical
processor. Also the processor id returned does not correspond to the
processor index, rather is returned only for the BSP.
BUG=b:179113790
Change-Id: Ief8677e4830a765af61a0df9621ecaa372730fca
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50880
Reviewed-by: EricR Lai <ericr_lai@compal.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
If the UPD size in coreboot sizes mismatches the one from the FSP-M
binary, we're running into trouble. If the expected size is smaller than
the UPD size the FSP provides, call die(), since the target buffer isn't
large enough so only the beginning of the UPD defaults from the FSP will
get copied into the buffer. We ran into the issue in soc/amd/cezanne,
where the UPD struct in coreboot was smaller than the one in the FSP, so
the defaults didn't get completely copied.
TEST=Mandolin still boots.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ia7e9f6f20d0091bbb4abfd42abb40b485da2079d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50241
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Enforcing the exact match of FSPS UPD block size between FSP and
coreboot mandates simultaneous updates to coreboot and FSP repos. Allow
coreboot to proceed if its UPD structure is smaller than FSP one. This
usually indicates that FSPS has an updated (larger) UPD structure which
should be soon matched/updated on the coreboot side to keep them in
sync.
While this is an undesirable situation that should be corrected
ASAP, it is safe from coreboot perspective. It is safe (as long as
default values in FSP UPD are sane enough to boot) because FSPS UPD
buffer is allocated on the heap with the size specified in FSPS
(larger) and filled with FSPS default values. This allows FSP UPD
changes to be submitted first followed by changes in coreboot repo.
Note that this only applies to the case when entire FSPS UPD structure
grows which should be rare as FSP should allocate enough reserve space,
anticipating future expansion, to keep the structure from growing when
new members are added.
BUG=b:171234996
BRANCH=Zork
TEST=build Trembyle
Change-Id: I557fd3a1f208b5b444ccf76e1552e74ecf4decad
Signed-off-by: Nikolai Vyssotski <nikolai.vyssotski@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50576
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Martin Roth <martinroth@google.com>
ACPI S3 is a global state and it is no longer needed to
pass it as a parameter.
Change-Id: Id0639a47ea65c210b9a79e6ca89cee819e7769b1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Hide the detail of allocation from cbmem from the FSP.
Loading of a BMP logo file from CBFS is not tied to FSP
version and we do not need two copies of the code, move
it under lib/.
Change-Id: I909f2771af534993cf8ba99ff0acd0bbd2c78f04
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50359
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add support for MP services2 PPIs, which is slight modification
over MP services 1 PPIs. A new API StartupAllCPUs have been added
to allow running a task on BSP and all APs. Also the EFI_PEI_SERVICES
parameter has been removed from all MP PPI APIs.
This implementation also selects the respective MP services PPI version
supported for SoCs
BUG=b:169196864
Change-Id: Id74baf17fb90147d229c78be90268fdc3ec1badc
Signed-off-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49474
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
This change drops the config FSP_PEIM_TO_PEIM_INTERFACE.
FSP_PEIM_TO_PEIM_INTERFACE is used for:
* Auto-selecting FSP_USES_MP_SERVICES_PPI
* Including src/drivers/intel/fsp2_0/ppi/Kconfig
* Adding ppi to subdirs-y
* Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y
and is selected by SoCs that want to enable MP PPI services.
Instead of using the indirect path of selecting MP PPI services, this
change allows SoC to select FSP_USES_MP_SERVICES_PPI directly. The
above uses are handled as follows:
* Auto-selecting FSP_USES_MP_SERVICES_PPI
--> This is handled by SoC selection of FSP_USES_MP_SERVICES_PPI.
* Including src/drivers/intel/fsp2_0/ppi/Kconfig
--> The guard isn't really required. The Kconfig options in this
file don't present user prompts and don't really need to be guarded.
* Adding ppi to subdirs-y
--> Makefile under ppi/ already has conditional inclusion of files
and does not require a top-level conditional.
* Setting USE_INTEL_FSP_TO_CALL_COREBOOT_PUBLISH_MP_PPI to y
--> This is set to y if FSP_USES_MP_SERVICES_PPI is selected by SoC.
TEST=Verified that timeless build for brya, volteer, icelake_rvp,
elkhartlake_crb and waddledee shows no change in generated coreboot.rom
Change-Id: I0664f09d85f5be372d19925d47034c76aeeef2ae
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50274
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add new Kconfig symbols to mark FSP binary as x86_32.
Fix the FSP headers and replace void pointers by fixed sized integers
depending on the used mode to compile the FSP.
This issue has been reported here:
https://github.com/intel/FSP/issues/59
This is necessary to run on x86_64, as pointers have different size.
Add preprocessor error to warn that x86_64 FSP isn't supported by the
current code.
Tested on Intel Skylake. FSP-M no longer returns the error "Invalid
Parameter".
Change-Id: I6015005c4ee3fc2f361985cf8cff896bcefd04fb
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Allow platforms to use the coreboot postcar code instead of calling
into FSP-M TempRamExit API.
There are several reasons to do this:
- Tearing down CAR is easy.
- Allows having control over MTRR's and caching in general.
- The MTRR's set up in postcar be it by coreboot or FSP-M are
overwritten later on during CPU init so it does not matter.
- Avoids having to find a CBFS file before cbmem is up (this
causes problems with cbfs_mcache)
Change-Id: I6cf10c7580f3183bfee1cd3c827901cbcf695db7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48466
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In case of a mismatch print both the UPD signature in the FSP and the
expected signature and then calls die(), since it shouldn't try calling
into the wrong FSP binary for the platform.
Signed-off-by: Justin Frodsham <justin.frodsham@protonmail.com>
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I469836e09db6024ecb448a5261439c66d8e65daf
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50090
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Factor out the condition when an attempt to load
stage from cache can be tried.
Change-Id: I936f07bed6fc82f46118d217f1fd233e2e041405
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/50000
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The function has only one local call-site.
Change-Id: I623953796e6cd3a8e5b4f72293d953b61f14a5a1
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49999
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
According to FSP_INFO_HEADER structure in FSP EAS v2.0-v2.2,
BIT1 indicates an "official" build.
Change-Id: I94df6050a1ad756bbeff60cda0ebac76ae5f8249
Signed-off-by: Benjamin Doron <benjamin.doron00@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49650
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add the "ERROR:" tag so that it ease debug effect.
TEST=Test tools like "suspend_stress_test" (specific to Chrome OS) can
identify the obvious coreboot ERROR prior running S3 resume test.
Change-Id: I64717ce0412d43697f42ea2122b932037d28dd48
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49798
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In order to update the BB retimers for usb4/tbt they need to be turned
on and into TBT mode. Expand the current DSM to allow for the use of an
EC RAM byte RFWU to get the current state of each port and whether or
not it has a retimer. It also allows Kernel to issue state transitions
for the retimer to be put into TBT mode for firmware update.
BUG=b:162528867
TEST=Along with work in progress kernel and EC patches, the Retimer
firmware update is verified under device attached and no device attached
scenarios.
Change-Id: I768cfb56790049c231173b0ea0f8e08fe6b64b93
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48630
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
prog_locate() will load FSP, before CBMEM is initialized.
The vboot workbuffer is used for loading, but
CBMEM_ID_VBOOT_WORKBUF is not available.
A NULL pointer is returned as workbuffer resulting in error
'Ramstage was not loaded!' at second boot.
Initialize CBMEM before calling prog_locate().
BUG = N/A
TEST = Build and boot on Facebook FBG1701
Change-Id: I2f04a326a95840937b71f6ad65a7c011268ec6d6
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49639
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
For arch/x86 the realmode part has to be located within the same 64
KiB as the reset vector. Some older intel platforms also require 4 KiB
alignment for _start16bit.
To enforce the above, and to separate required parts of .text without
matching *(.text.*) rules in linker scripts, tag the pre-C environment
assembly code with section .init directive.
Description of .init section for ELF:
This section holds executable instructions that contribute to the
process initialization code. When a program starts to run, the
system arranges to execute the code in this section before calling the
main program entry point (called main for C programs).
Change-Id: If32518b1c19d08935727330314904b52a246af3c
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47599
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add a new macro `GMA_DEFAULT_PANEL(ssc)` as shortcut for specifying one
internal panel at port A (0) in the devicetree.
Change-Id: I5308b53667657d0b255ae5bc543f1a00431f5818
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/49054
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are multiple different devicetree setting formats for graphics
panel settings present in coreboot. Replace the ones for the platforms
that already have (mostly) unified gma/graphics setup code by a unified
struct in the gma driver. Hook it up in HSW, BDW, SKL, and APL and adapt
the devicetrees accordingly.
Always ensure that values don't overflow by applying appropriate masks.
The remaining platforms implementing panel settings (GM45, i945, ILK and
SNB) can be migrated later after unifying their gma/graphics setup code.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I445defe01d5fbf9a69cf05cf1b5bd6c7c2c1725e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48885
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
which select INTEL_GMA_ACPI. Rework brightness level includes and
platform-level asl files to avoid duplicate device definition for GFX0.
Include gfx.asl for Skylake/Kabylake, since all other soc/intel/common
platforms already do. Adjust mb/51nb/x210 to prevent device redefinition.
Some OSes (e.g. Windows, MacOS) require/prefer the ACPI device for
the IGD to exist, even if ACPI brightness controls are not utilized.
This change adds a GFX0 ACPI device for all boards whose platforms
select INTEL_GMA_ACPI without requiring non-functional brightness
controls to be added at the board level.
Change-Id: Ie71bd5fc7acd926b7ce7da17fbc108670fd453e0
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48862
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Add the right register values for backlight control to CNL's Kconfig.
To make iasl happy about the reversed register order, split the field.
Change-Id: I05a06cc42397c202df9c9a1ebc72fb10da3b10ec
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48772
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The register `ESR` conflicts with the `Exception syndrome register` in
UDK2017. To resolve the conflict, drop the unused `ESR` register from
gma registers. It can be readded and prefixed or renamed if it's
required at a later point.
Change-Id: Icfdd834aea59ae69639a180221f5e97170fbac15
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
We missed that Cannon Point, the PCH usually paired with Coffee, Whiskey
and Comet Lake, differs a bit from its predecessors. Hence, libgfxinit
now has a new Kconfig setting for the PCH.
Change-Id: I1c02c0d9abb7340aabe94185ee5e17ef4c2b0d36
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48764
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
When a different FSP binary was chosen in menuconfig, the split fd files
do not get updated. Thus, make them depend on `.config` to trigger a
rebuild when the config changes.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I54739eae50fa1a47bf8f3fe2e79334bc7f7ac3d6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48663
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently it's not possible to add multiple graphics drivers into
one coreboot image. This patch series will fix this issue by providing
a single API that multiple graphics drivers can use.
This is required for platforms that have two graphic cards, but
different graphic drivers, like Intel+Aspeed on server platforms or
Intel+Nvidia on consumer notebooks.
The goal is to remove duplicated fill_fb_framebuffer(), the advertisment
of multiple independent framebuffers in coreboot tables, and better
runtime/build time graphic configuration options.
Replace all duplications of fill_fb_framebuffer and provide a single one
in edid_fill_fb.c. Should not change the current behaviour as still only
one graphic driver can be active at time.
Change-Id: Ife507f7e7beaf59854e533551b4b87ea6980c1f4
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39003
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Stack is set up for bootblock.
Tested on Facebook FBG1701.
Change-Id: I0dd3fc91c90bf76e0d93925da35dc197d68d3e88
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47802
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Use a wrapper code that does nothing on x86_32, but drops to protected
mode to call into FSP when running on x86_64.
Tested on Intel Skylake when running in long mode. Successfully run the
FSP-M which is compiled for x86_32 and then continued booting in
long mode.
Change-Id: I9fb37019fb0d04f74d00733ce2e365f484d97d66
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48202
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
When FSP-T is used, the first thing done in postcar is to call FSP-M
to tear down CAR. This is done before cbmem is initialized, which
means CBFS_MCACHE is not accessible, which results in FSP-M not being
found, failing the boot.
TESTED: ocp/deltalake boots again.
Change-Id: Icb41b802c636d42b0ebeb3e3850551813accda91
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48282
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This patch renames cbfs_boot_map_with_leak() and cbfs_boot_load_file()
to cbfs_map() and cbfs_load() respectively. This is supposed to be the
start of a new, better organized CBFS API where the most common
operations have the most simple and straight-forward names. Less
commonly used variants of these operations (e.g. cbfs_ro_load() or
cbfs_region_load()) can be introduced later. It seems unnecessary to
keep carrying around "boot" in the names of most CBFS APIs if the vast
majority of accesses go to the boot CBFS (instead, more unusual
operations should have longer names that describe how they diverge from
the common ones).
cbfs_map() is paired with a new cbfs_unmap() to allow callers to cleanly
reap mappings when desired. A few new cbfs_unmap() calls are added to
generic code where it makes sense, but it seems unnecessary to introduce
this everywhere in platform or architecture specific code where the boot
medium is known to be memory-mapped anyway. In fact, even for
non-memory-mapped platforms, sometimes leaking a mapping to the CBFS
cache is a much cleaner solution than jumping through hoops to provide
some other storage for some long-lived file object, and it shouldn't be
outright forbidden when it makes sense.
Additionally, remove the type arguments from these function signatures.
The goal is to eventually remove type arguments for lookup from the
whole CBFS API. Filenames already uniquely identify CBFS files. The type
field is just informational, and there should be APIs to allow callers
to check it when desired, but it's not clear what we gain from forcing
this as a parameter into every single CBFS access when the vast majority
of the time it provides no additional value and is just clutter.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: Ib24325400815a9c3d25f66c61829a24a239bb88e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/39304
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Mariusz Szafrański <mariuszx.szafranski@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This pollutes the log on all platforms not implementing an override.
Change-Id: I0d8371447ee7820cd8e86e9d3d5e70fcf4f91e34
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/48128
Reviewed-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Commit bd31642ad8 (intel/i210: Set bus master bit in command register)
is only necessary because a buggy OS expects Bus Master to be set, not
because the hardware requires Bus Master during initialization. It is
thus safe to defer the Bus Master request into the .final callback.
Change-Id: Iecfa6366eb4b1438fd12cd9ebb1a77ada97fa2f6
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47401
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Tested-by: siemens-bot
Define and use the MAC_ADDR_LEN macro in place of the `6` magic value.
Change-Id: Icfa2ad9bca6668bea3d84b10f613d01e437ac6a2
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47404
Tested-by: siemens-bot
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Move the FSP FD PATH option down, so it gets shown in place of the split
FD files, when the users chooses to use a full FD binary.
Change-Id: Ie03a418fab30a908d020abf94becbaedf54fbb99
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47999
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Currently, setting a custom FSP binary is only possible by using split
FSP-T/M/S FD files. This change introduces the possibility to pass a
combined FD file (the "standard" FSP format).
This is done by adding a new boolean Kconfig FSP_FULL_FD, specifying
that the FSP is a single FD file instead of split FSP-T/M/S FD files,
and making FSP_FD_PATH user-visible when the option is chosen. In this
case, the other options for split files get hidden.
When the user chooses to use a full FD file instead of the split ones,
the FD file gets split during build, just like it is done when selecting
the Github FSP repo (FSP_USE_REPO).
Test: Supermicro X11SSM-F builds and boots fine with custom FSP FD set.
Signed-off-by: Michael Niewöhner <foss@mniewoehner.de>
Change-Id: I1cb98c1ff319823a2a8a95444c9b4f3d96162a02
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47993
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols.
Tested on Facebook FBG1701
Change-Id: Ice748e542180f6e1dc1505e7f37b6b6c68772bda
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47758
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Whole car region is cleared, while only small part needs to be done.
Clear .bss area only
Tested on Facebook FBG1701
Change-Id: I021c2f7d3531c553015fde98d155915f897b434d
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47760
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Only need to check this once so check it at romstage where
the console is usually ready. Also define union fsp_revision
to avoid code duplication.
Change-Id: I628014e05bd567462f50af2633fbf48f3dc412bc
Signed-off-by: Johnny Lin <johnny_lin@wiwynn.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47559
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Top of Temp RAM is used as bootloader stack, which is the
_car_region_end area. This area is not equal to CAR stack area as
defined in car.ld file.
Use _ecar_stack (end of CAR stack) as starting stack location.
Tested VBOOT, Vendorboot security and no security on Facebook FBG1701.
Change-Id: I16b077f60560de334361b1f0d3758ab1a5cbe895
Signed-off-by: Frans Hendriks <fhendriks@eltan.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47737
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Wim Vervoorn <wvervoorn@eltan.com>
Reviewed-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This Kconfig option was just added incorrectly, so would never add
the verstage.c file.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: I4c39dca9d429ed786ea42c0d421d6ee815e8c419
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47368
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Currently the decision of whether or not to use mrc_cache in recovery
mode is made within the individual platforms' drivers (ie: fsp2.0,
fsp1.1, etc.). As this is not platform specific, but uses common
vboot infrastructure, the code can be unified and moved into
mrc_cache. The conditions are as follows:
1. If HAS_RECOVERY_MRC_CACHE, use mrc_cache data (unless retrain
switch is true)
2. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_BOOTBLOCK, this
means that memory training will occur after verified boot,
meaning that mrc_cache will be filled with data from executing
RW code. So in this case, we never want to use the training
data in the mrc_cache for recovery mode.
3. If !HAS_RECOVERY_MRC_CACHE && VBOOT_STARTS_IN_ROMSTAGE, this
means that memory training happens before verfied boot, meaning
that the mrc_cache data is generated by RO code, so it is safe
to use for a recovery boot.
4. Any platform that does not use vboot should be unaffected.
Additionally, we have removed the
MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN config because the
mrc_cache driver takes care of invalidating the mrc_cache data for
normal mode. If the platform:
1. !HAS_RECOVERY_MRC_CACHE, always invalidate mrc_cache data
2. HAS_RECOVERY_MRC_CACHE, only invalidate if retrain switch is set
BUG=b:150502246
BRANCH=None
TEST=1. run dut-control power_state:rec_force_mrc twice on lazor
ensure that memory retraining happens both times
run dut-control power_state:rec twice on lazor
ensure that memory retraining happens only first time
2. remove HAS_RECOVERY_MRC_CACHE from lazor Kconfig
boot twice to ensure caching of memory training occurred
on each boot.
Change-Id: I3875a7b4a4ba3c1aa8a3c1507b3993036a7155fc
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46855
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
From Tigerlake FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Commit cf5d58328f had changed
the size from 8 to 9 Kib. This change adds Kconfig option to choose
vbt data size based on platform.
BUG=b:171401992
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: Ia294fc94ce759666fb664dfdb910ecd403e6a2e9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47151
Reviewed-by: Wonkyu Kim <wonkyu.kim@intel.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Individual drivers check whether the concerned device is enabled before
filling in the SSDT. Move the check before calling acpi_fill_ssdt() and
remove the check in the individual drivers.
BUG=None
TEST=util/abuild/abuild
Change-Id: Ib042bec7e8c68b38fafa60a8e965d781bddcd1f0
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47148
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Christian Walter <christian.walter@9elements.com>
Create SOC_INTEL_COMMON_FSP_RESET Kconfig to have IA common code block
to handle platform reset request raised by FSP. The FSP will use the
FSP EAS v2.0 section 12.2.2 (OEM Status Code) to indicate that a reset
is required.
Make FSP_STATUS_GLOBAL_RESET depends on SOC_INTEL_COMMON_FSP_RESET.
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: I934b41affed7bb146f53ff6a4654fdbc6626101b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/47017
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
This allows to compare the FSP-T output in %ecx and %edx to coreboot's
CAR symbols:
Change-Id: I8d79f97f8c12c63ce215935353717855442a8290
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46884
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
With TGL FSP v3373 onwards vbt binary size changed from 8KiB
to 9KiB. Due to which cbfsf_decompression_info check failed
when trying to load vbt binary from cbfs because vbt
decompressed_size was greater than vbt_data size. This caused
Graphics init and fw screen issues. Increase the vbt_data to
9KiB to accommodate new vbt binary.
BUG=b:170656067
BRANCH=none
TEST=build and boot delbin and verify fw screen is loaded
Signed-off-by: Srinidhi N Kaushik <srinidhi.n.kaushik@intel.com>
Change-Id: If6ffce028f9e8bc14596bbc0a3f1476843a9334e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46374
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dossym Nurmukhanov <dossym@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This CL would remove these calls from fsp 2.0. Platforms that select
MRC_STASH_TO_CBMEM, updating the TPM NVRAM space is moved from
romstage (when data stashed to CBMEM) to ramstage (when data is
written back to SPI flash.
BUG=b:150502246
BRANCH=None
TEST=make sure memory training still works on nami
Change-Id: I3088ca6927c7dbc65386c13e868afa0462086937
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46510
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Use this config to specify whether we want to save a hash of the
MRC_CACHE in the TPM NVRAM space. Replace all uses of
FSP2_0_USES_TPM_MRC_HASH with MRC_SAVE_HASH_IN_TPM and remove the
FSP2_0_USES_TPM_MRC_HASH config. Note that TPM1 platforms will not
select MRC_SAVE_HASH_IN_TPM as none of them use FSP2.0 and have
recovery MRC_CACHE.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: Ic5ffcdba27cb1f09c39c3835029c8d9cc3453af1
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46509
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
As ongoing work for generalizing mrc_cache to be used by all
platforms, we are pulling it out from fsp 2.0 and renaming it as
mrc_cache_hash_tpm.h in security/vboot.
BUG=b:150502246
BRANCH=None
TEST=emerge-nami coreboot chromeos-bootimage
Change-Id: I5a204bc3342a3462f177c3ed6b8443e31816091c
Signed-off-by: Shelley Chen <shchen@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46508
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The USB4 retimer device needs to declare a _DSM with specific functions
that allow for GPIO control to turn off the power when an external
device is not connected. This driver allows the mainboard to provide
the GPIO that is connected to the power control.
BUG=b:156957424
Change-Id: Icfb85dc3c0885d828aba3855a66109043250ab86
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44918
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently, drivers/intel/wifi is a PCI driver (provides `struct
pci_driver`) as well as a chip driver (provides `struct
chip_operations`). However, there is no need for a separate chip
driver for the WiFi device since drivers/wifi/generic already provides
one.
Having two separate chip drivers makes it difficult to multi-source
WiFi devices and share the same firmware target without having to add
a probe property for each of these devices. This is unnecessary since
the WiFi driver in coreboot is primarily responsible for:
1. PCI resource allocation
2. ACPI SSDT node generation to expose wake property and SAR tables
3. SMBIOS table generation
For the most part, coreboot can perform the above operations without
really caring about the specifics of which WiFi device is being used
by the mainboard. Thus, this change drops the driver for intel/wifi
and moves the PCI driver support required for Intel WiFi chips into
drivers/wifi/generic. The PCI driver is retained for backward
compatibility with boards that never utilized the chip driver to
support Intel WiFi device. For these devices, the PCI driver helps
perform the same operations as above (except exposing the wake
property) by utilizing the same `wifi_generic_ops`.
This change also moves DRIVERS_INTEL_WIFI config to
wifi/generic/Kconfig.
BUG=b:169802515
BRANCH=zork
Change-Id: I780a7d1a87f387d5e01e6b35aac7cca31a2033ac
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46036
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change moves the addition of CBFS SAR file from
intel/wifi/Makefile.inc to wifi/generic/Makefile.inc to keep it in the
same sub-directory as the Kconfig definition.
BUG=b:169802515
BRANCH=zork
Change-Id: I7ee33232b6a07bbf929f3a79fabe89130fb6fa6f
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46039
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
This change drops the dependency of DRIVERS_WIFI_GENERIC on
HAVE_ACPI_TABLES as the driver provides operations other than the ACPI
support for WiFi devices. Since the dependency is now dropped, ACPI
operations in generic.c are guarded by CONFIG(HAVE_ACPI_TABLES).
BUG=b:169802515
BRANCH=zork
Change-Id: I16444a9d842a6742e3c97ef04c4f18e93e6cdaa9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46037
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This change drops maxsleep parameter from chip config and instead
hardcodes the deepest sleep state from which the WiFi device can wake
the system up from to SLP_TYP_S3. This is similar to how other device
drivers in coreboot report _PRW property in ACPI. It relieves the
users from adding another register attribute to devicetree since all
mainboards configure the same value. If this changes in the future, it
should be easy to bring the maxsleep config parameter back.
BUG=b:169802515
BRANCH=zork
Change-Id: I42131fced008da0d51f0f777b7f2d99deaf68827
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46033
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
This change uses the newly added `pci_dev_is_wake_source()` helper function
to determine and log WiFi wake source instead of assuming a hard-coded
register value to check. This is done in preparation to merge the
generic WiFi and Intel WiFi drivers in coreboot in follow-up changes.
BUG=b:169802515
BRANCH=zork
Change-Id: I9bdb453092b4ce7bdab2969f13e0c0aa8166dc0a
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46031
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
`pci_dev_init()` is used to load and run option ROM on VGA class
devices (PCI_CLASS_DISPLAY_VGA). WiFi device is not a VGA class device
and hence the call to `pci_dev_init()` is not required. This change
drops the call to `pci_dev_init()` from `wifi_pci_dev_init()` in Intel
WiFi driver.
BUG=b:169802515
BRANCH=zork
Change-Id: I6588ea0a5c848904088d05fd1cbdf677b2dc8ea9
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/46029
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rob Barnes <robbarnes@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Michael Niewöhner <foss@mniewoehner.de>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
APEI (ACPI Platform Error Interface) defines BERT (Boot Error Record
Table) memory region:
* Bootloader (firmware) generates UEFI CPER (Common Platform Error
Record) records, and populates BERT region.
* OS parses ACPI BERT table, finds the BERT region address, inteprets
the data and processes it accordingly.
When CONFIG_ACPI_BERT is defined, update FSP UPD BootLoaderTolumSize,
so FSP allocates memory region for it. The APEI BERT region is placed
on top of CBMEM, for the size of CONFIG_ACPI_BERT_SIZE.
Apart from APEI BERT region, we also have plan to add APEI HEST region
which holds OS runtime hardware error record, based on firmware
first hardware error handling model. HEST region will be reserved
same way as BERT region.
Note that CBMEM region can not be used for such purpose, the OS
(bert/hest) drivers are not able to access data held in CBMEM region,
as CBMEM is set as type 16 (configuration table).
An option considered was to reserve the BERT region under CBMEM.
However, we do not know the size of CBMEM till acpi tables are set up.
On the other hand, BERT region needs to be filled up before ACPI BERT
table is finalized.
Change-Id: Ie72240e4c5fa01fcf937d33678c40f9ca826487a
Signed-off-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45391
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Add CONFIG_FSP_STATUS_GLOBAL_RESET Kconfig to get correct FSP global
reset type from respective SoC Kconfig.
Supported value: 0x40000003-0x40000008, These are defined in FSP EAS
v2.0 section 11.2.2 - OEM Status Code
Unsupported value: 0xFFFFFFFF
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Change-Id: Idc04eb3a931d2d353808d02e62bd436b363600d1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45553
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Coverity detects variable dsd going out of scope leaks the storage it
points to. Move dsd resource allocation after sanity check for
config->nvm_compact to avoid leak.
Found-by: Coverity CID 1432727
TEST=Built and boot up to kernel on Volteer.
Signed-off-by: John Zhao <john.zhao@intel.com>
Change-Id: I86af322dc78845b8b312b6815135336c2c56b4dd
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45531
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Wawrzynczak <twawrzynczak@chromium.org>
Add compatible field for NVM
Make PRP0001 as default HID if device type is INTEL_ACPI_CAMERA_NVM
Signed-off-by: Pandya, Varshit B <varshit.b.pandya@intel.com>
Change-Id: Iad7afa7b3170982eb5d6215e766f3e98f7a89213
Reviewed-on: https://review.coreboot.org/c/coreboot/+/45091
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Create two new functions to fetch mrc_cache data (replacing
mrc_cache_get_current):
- mrc_cache_load_current: fetches the mrc_cache data and drops it into
the given buffer. This is useful for ARM platforms where the mmap
operation is very expensive.
- mrc_cache_mmap_leak: fetch the mrc_cache data and puts it into a
given buffer. This is useful for platforms where the mmap operation
is a no-op (like x86 platforms). As the name mentions, we are not
freeing the memory that we allocated with the mmap, so it is the
caller's responsibility to do so.
Additionally, we are replacing mrc_cache_latest with
mrc_cache_get_latest_slot_info, which does not check the validity of
the data when retrieving the current mrc_cache slot. This allows the
caller some flexibility in deciding where they want the mrc_cache data
stored (either in an mmaped region or at a given address).
BUG=b:150502246
BRANCH=None
TEST=Testing on a nami (x86) device:
reboot from ec console. Make sure memory training happens.
reboot from ec console. Make sure that we don't do training again.
Signed-off-by: Shelley Chen <shchen@google.com>
Change-Id: I259dd4f550719d821bbafa2d445cbae6ea22e988
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44006
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Value stored to 'size' is never read.
Also drop unused parameter.
Change-Id: If3e96ac90f06966ee408964e0748730bc237ec19
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41697
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
soc/amd/picasso selected FSP_USES_CB_STACK even though it is FSP 2.0
based, so it doesn't reuse coreboot's stack, but sets up its own stack.
In contrast to all other FSP 2.0 based platforms, this stack isn't in
the CAR region, since AMD Picasso doesn't support CAR and the DRAM is
already available when the x86 cores are released from reset. Selecting
FSP_USES_CB_STACK ended up doing the right thing, but is semantically
wrong. Instead of wrongly selecting FSP_USES_CB_STACK in soc/amd/picasso
we take the corresponding code path if ENV_CACHE_AS_RAM is false which
is only the case for non-CAR platforms.
BUG=b:155501050
TEST=Timeless build results in an identical binary for amd/mandolin,
asrock/h110m-dvs and intel/coffeelake_rvp11 which cover all 3 cases
here.
Change-Id: Icd0ff8e17a535e2c247793b64f4b0565887183d8
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44406
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Latest EDK2 code inside
"UefiCpuPkg\Library\RegisterCpuFeaturesLib\CpuFeaturesInitialize.c"
is now looking for EFI_CPU_PHYSICAL_LOCATION structure variables hence
coreboot need to fill required information (package, core and thread
count).
TEST=Able to see package, core and thread information as part of FSP
debug log.
Change-Id: Ieccf20a116d59aaafbbec3fe0adad9a48931cb59
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44390
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Reviewed-by: Aamir Bohra <aamir.bohra@intel.com>
This patch ensures that coreboot is able to take control of APs back
by doing a full AP re-initialization after FSP-S is done.
TEST=Able to see all cores available after booting to OS using below command
when coreboot is built with USE_INTEL_FSP_MP_INIT enable.
> cat /proc/cpuinfo
Without this CL :
shows only 1 core (only BSP)
With this CL :
shows all possible cores available (BSP + APs)
Change-Id: I247d8d1166c77bd01922323b6a0f14ec6640a666
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/44077
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
