Initially, I wanted to move only the Kconfig DISPLAY_MTRRS into the
"Debug" menu. It turned out, though, that the code looks rather generic.
No need to hide it in soc/intel/.
To not bloat src/Kconfig up any further, start a new `Kconfig.debug`
hierarchy just for debug options.
If somebody wants to review the code if it's 100% generic, we could
even get rid of HAVE_DISPLAY_MTRRS.
Change-Id: Ibd0a64121bd6e4ab5d7fd835f3ac25d3f5011f24
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/29684
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Its spreading copies got out of sync. And as it is not a standard header
but used in commonlib code, it belongs into commonlib. While we are at
it, always include it via GCC's `-include` switch.
Some Windows and BSD quirk handling went into the util copies. We always
guard from redefinitions now to prevent further issues.
Change-Id: I850414e6db1d799dce71ff2dc044e6a000ad2552
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/28927
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently car_stage_entry is defined only in romstage_after_verstage and
as a result when SEPARATE_VERSTAGE is not selected, there is no
entry point into romstage and romstage will not be started at all.
The solution is move out romstage_after_verstage.S from fsp1.1 driver
to skylake/romstage. And add CONFIG_PLATFORM_USES_FSP1_1 to fix the
build and boot issue with this change.
Besides that, rename the romstage_after_verstage to romstage_c_entry
in more appropriate naming convention after this fix.
Tested on SkyLake Saddle Brook (FSP 1.1) and KabyLake Rvp11 (FSP 2.0),
romstage can be started successfully.
Change-Id: I1cd2cf5655fdff6e23b7b76c3974e7dfd3835efd
Signed-off-by: Teo Boon Tiong <boon.tiong.teo@intel.com>
Reviewed-on: https://review.coreboot.org/17976
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
On x86 platforms, google_chromeec_early_init() is used to put the EC
into RO mode when there's a recovery request. This is to avoid training
memory multiple times when the recovery request is through an EC host
event while the EC is running RW code. Under that condition the EC will
be reset (along with the rest of the system) when the kernel verification
happens. This leads to an execessively long recovery path because of the
double reboot performing full memory training each time.
By putting this logic into the verstage program this reduces the
bootblock size on the skylake boards. Additionally, this provides the
the correct logic for all future boards since it's not tied to FSP
nor the mainboard itself. Lastly, this double memory training protection
works only for platforms which verify starting from bootblock. The
platforms which don't start verifying until after romstage need to
have their own calls (such as haswell and baytrail).
Change-Id: Ia8385dfc136b09fb20bd3519f3cc621e540b11a5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16318
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Now that only CBFS access is supported for finding resources
within the boot media the assets infrastructure can be removed.
Remove it.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
Change-Id: I383fd6579280cf9cfe5a18c2851baf74cad004e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12690
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Chrome OS verified boot path supported multiple CBFS
instances in the boot media as well as stand-alone assets
sitting in each vboot RW slot. Remove the support for the
stand-alone assets and always use CBFS accesses as the
way to retrieve data.
This is implemented by adding a cbfs_locator object which
is queried for locating the current CBFS. Additionally, it
is also signalled prior to when a program is about to be
loaded by coreboot for the subsequent stage/payload. This
provides the same opportunity as previous for vboot to
hook in and perform its logic.
BUG=chromium:445938
BRANCH=None
TEST=Built and ran on glados.
CQ-DEPEND=CL:307121,CL:31691,CL:31690
Change-Id: I6a3a15feb6edd355d6ec252c36b6f7885b383099
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12689
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
In order to support verstage the cache-as-ram split
is taken advantage of such that verstage has the
cache-as-ram setup and rosmtage has the cache-as-ram
tear down path. The verstage proper just initializes
the console and attempts to run romstage which triggers
the vboot verification of the firmware. In order to
pass the current FSP to use during romstage a global
variable in cache-as-ram is populated before returning
to the assembly code which tears down cache-as-ram.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with verstage support as well as
VBOOT_DYNAMIC_WORK_BUFFER with direct link in romstage.
Change-Id: I8de74a41387ac914b03c9da67fd80f8b91e9e7ca
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11824
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to introduce a verstage which performs vboot
verification the cache-as-ram environment needs to be
generalized and split into pieces that can be utilized
in romstage and/or verstage. Therefore, the romstage
pieces were removed from the cache-as-ram specific pieces
that are generic:
- Add fsp/car.h to house the declarations for functions in
the cache-as-ram environment
- Only have cache_as_ram_params which are isolated form the
cache-as-ram environment aside from FSP_INFO_HEADER.
- Hardware requirements for console initialization is done
in the cache-as-ram specific files.
- Provide after_raminit.S which can be included from a
romstage separated from cache-as-ram as well as one that
is tightly coupled to the cache-as-ram environment.
- Update the fallout from the API changes in
soc/intel/{braswell,common,skylake}.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Original-Change-Id: I2fb93dfebd7d9213365a8b0e811854fde80c973a
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/302481
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Id93089b7c699dd6d83fed8831a7e275410f05afe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11816
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
