Remove the TODO message from FspUpdVpd.h
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16114
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Change-Id: Icd565c6062ef59b1e4a68310bb6f9ed62fb014af
Reviewed-on: https://chromium-review.googlesource.com/368883
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Change-Id: Ic0aefaf938f146b2461b99182db421a73743931c
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: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/368781
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
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.
BUG=None
BRANCH=None
TEST=None
Change-Id: I093657f526a8711866ad208589cc9a3f505cc825
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>
Reviewed-on: https://chromium-review.googlesource.com/368625
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables the CHROMEOS_RAMOOPS_NON_APCI Kconfig option as a
default across all non-x86 Chrome OS boards.
CQ-DEPEND=CL:367905
BRANCH=None
BUG=None
TEST=See depthcharge CL.
Change-Id: I16ff7f68762a995cd38e5fddaf6971d4b9f07e21
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368010
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use the ACPI generator for creating the Chrome OS gpio
package. Each mainboard has its own list of Chrome OS
gpios that are fed into a helper to generate the ACPI
external OIPG package. Additionally, the common
chromeos.asl is now conditionally included based on
CONFIG_CHROMEOS.
BUG=None
BRANCH=None
TEST=None
Change-Id: I8152a275190bcc7aa1e0eb33e2d64e37002bacd9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/15909
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366211
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
1. Currenty, boot reason is being added to elog only for some
ARM32/ARM64 platforms. Change this so that boot reason is logged by
default in elog for all devices which have CHROMEOS selected.
2. Add a new option to select ELOG_WATCHDOG_RESET for the devices that
want to add details about watchdog reset in elog. This requires a
special region WATCHDOG to be present in the memlayout.
3. Remove calls to elog add boot reason and watchdog reset from
mainboards.
BUG=chrome-os-partner:55639
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15897
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I91ff5b158cfd2a0749e7fefc498d8659f7e6aa91
Reviewed-on: https://chromium-review.googlesource.com/364021
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This renames the VB_SOURCE variable to VBOOT_SOURCE in the build system,
providing increased clarity about what it represents.
Since the submodule itself is called "vboot", it makes sense to use that
name in full instead of a very shortened (and confusing) version of it.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/15824
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Change-Id: Ib343b6642363665ec1205134832498a59b7c4a26
Reviewed-on: https://chromium-review.googlesource.com/363938
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
On some x86 platforms (skylake, apollolake), we observe reboots at
different steps during the FSP initialization. These additional reboots
result in loss of recovery request because vboot_reference library
clears recovery request on vbnv once verification is complete and it has
made a decision about which boot path to take(normal/dev, slot-a/slot-b,
recovery).
Provide a way to allow mainboards/chipsets to inform recovery module in
vboot2 to save recovery reason to survive unexpected reboots. The
recovery reason is set in vbnv after vboot_reference library completes
its verification and clears the reason in vbnv while jumping to
payload.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15802
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ie96be9aeb42c8209d8215943409e6327d6a8bf98
Reviewed-on: https://chromium-review.googlesource.com/362974
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add recovery module in vboot2 that checks if a recovery request is
pending and returns appropriate reason code:
1. Checks if recovery mode is initiated by EC.
2. Checks if recovery request is present in VBNV.
3. Checks if recovery request is present in handoff for post-cbmem
stages.
4. Checks if vboot verification is complete and looks up selected region
to identify if recovery is requested by vboot library.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15800
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I31e332a4d014a185df2434c3730954e08dc27281
Reviewed-on: https://chromium-review.googlesource.com/362972
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
1. Remove unused functions/structures.
2. Add checks for NULL return values.
3. Change prefixes to vb2 instead of vboot for functions used internally
within vboot2/
4. Get rid of vboot_handoff.h file and move the structure definition to
vboot_common.h
5. Rename all functions using handoff structure to have prefix
vboot_handoff_*. All the handoff functions can be run _only_ after cbmem
is online.
6. Organize vboot_common.h content according to different
functionalities.
BUG=chrome-os-partner:55431
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I4c07d50327d88cddbdfbb0b6f82c264e2b8620eb
Reviewed-on: https://chromium-review.googlesource.com/362971
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Specify the memory initialization parameters in
mainboard/intel/galileo/devicetree.cb. Pass these values into FSP to
initialize memory.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I83ee196f5fb825118a3a74b61f73f3728a1a1dc6
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15260
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/359317
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
TPM1.2 is using the somewhat misnamed tlcl_set_global_lock() command
function to lock the hardware rollback counter. For TPM2 let's
implement and use the TPM2 command to lock an NV Ram location
(TPM2_NV_WriteLock).
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM2_NV_WriteLock command is invoked before RO
firmware starts RW, and succeeds.
Change-Id: I62f22b9991522d4309cccc44180a5ebd4dca488d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358097
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
tlcl_force_clear() needs to be issued each time when the device mode
switches between normal/development/recovery.
This patch adds command implementation using TPM_Clear TPM2 command,
and also invokes it before factory initialization.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that TPM_Clear command succeeds at factory startup and
the boot proceeds normally.
Change-Id: I2a0e62527ad46f9dd060afe5e75c7e4d56752849
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358095
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
The TPM2 specification allows defining NV ram spaces in such manner,
that it is impossible to remove the space, unless a certain PCR is in
a certain state.
This comes in handy when defining spaces for rollback counters: make
their removal depend on PCR0 being in the default state. Then extend
PCR0 to any value. This will guarantee that the spaces can not be
deleted.
Also, there is no need in creating firmware and kernel rollback spaces
with different privileges: they both can be created with the same set of
properties, the firmware space could be locked by the RO firmware, and
the kernel space could be locked by the RW firmware thus providing
necessary privilege levels.
BRANCH=none
BUG=chrome-os-partner:50645, chrome-os-partner:55063
TEST=with the rest of the patches applied it is possible to boot into
Chrome OS maintaining two rollback counter spaces in the TPM NV
ram locked at different phases of the boot process.
Change-Id: I69e5ada65a5f15a8c04be9def92a8e1f4b753d9a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358094
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
The function mainboard_get_mac_address() is used to get a MAC address
for a given i210 PCI device. Instead of passing pure numbers for PCI
bus, device and function pass the device pointer to this function. In
this way the function can retrieve the needed values itself as well as
have the pointer to the device tree so that PCI path can be evaluated
there.
BUG=None
BRANCH=None
TEST=None
Change-Id: I2335d995651baa5e23a0448f5f32310dcd394f9b
Original-Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Original-Reviewed-on: https://review.coreboot.org/15516
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358599
Reviewed-by: Martin Roth <martinroth@chromium.org>
Boards broken with commit:
062ef1c AGESA boards: Split dispatcher to romstage and ramstage
Boot failure with asus/f2a85-m witnessed around MemMS3Save() call,
message "Save memory S3 data in heap" in verbose agesa logs was
replaced by a system reset.
Default stubs for MemS3ResumeConstructNBBlock() returned TRUE
without initializing the block contents. This would not work for case
with multiple NB support built into same firmware.
MemMCreateS3NbBlock() then returned with S3NBPtr!=NULL with uninitialized
data and MemMContextSave() referenced those as invalid pointers.
There is no reason to prevent booting in the case S3 resume data is not
passed to ramstage, so remove the ASSERT(). It only affects builds with
IDSOPT_IDS_ENABLED=TRUE anyways.
BUG=None
BRANCH=None
TEST=None
Change-Id: I8fd1e308ceab2b6f4b4c90f0f712934c2918d92d
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/15344
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Idwer Vollering <vidwer@gmail.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358388
Reviewed-by: Martin Roth <martinroth@chromium.org>
If read_vbnv finds that the vbnv_copy is not valid, it initializes it
with the correct HEADER_SIGNATURE and other attributes. However, the
vbnv copy is checked for validity and initialized at the vboot layer as
well. Since, vboot is the owner of this data, it should be the one
initializing it. Thus, if read_vbnv sees that the data is not valid,
simply reset it to all 0s and let vboot layer take care of it. This also
removes the need for additional checks to ensure that the dirty vbnv
copy is properly updated on storage.
Change-Id: I6101ac41f31f720a6e357c9c56e571d62e0f2f47
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15498
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357994
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for a fourth info block type to hwilib. This block
provides new values and is now variable in length.
Change-Id: Ia928b4a98b806ba3e80fb576b78f60bb8f2ea3fc
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15478
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357991
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Currently, read_vbnv performs a reset of the vbnv cache if it is not
valid. However, this information is not passed up to the vboot layer,
thus resulting in missed write-back of vbnv cache to storage if vboot
does not update the cache itself.
Update read_vbnv to return a value depending upon whether it wants a
write-back to be performed when save is called.
Return value:
0 = No write-back required
1 = Write-back of VBNV cache is required.
Change-Id: I239939d5f9731d89a9d53fe662321b93fc1ab113
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15457
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357665
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
safe_write() and safe_define_space() functions are defined in
secdata_mock.c, but not used in mocked TPM mode.
The actual functions have been redefined as static recently and their
declarations were removed from src/include/antirollback.h, which now
causes compilation problems when CONFIG_VBOOT2_MOCK_SECDATA is
defined.
Dropping the functions from secdata_mock.c solves the problem.
BRANCH=none
BUG=none
TEST=compilation in mock secdata mode does not fail any more.
Change-Id: Ia781ce99630d759469d2bded40952ed21830e611
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356291
Tested-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds a TPM2 specific path in the vboot2 initialization
sequence when the device is turned on in the factory for the first
time, namely two secure NVRAM spaces are created, with different
access privileges.
The higher privilege space can be modified only be the RO firmware,
and the lower privilege space can be modified by both RO and RW
firmware.
The API is being modified to hide the TPM implementation details from
the caller.
Some functions previously exported as global are in fact not used
anywhere else, they are being defined static.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=when this code is enabled the two secure spaces are successfully
created during factory initialization.
Change-Id: I917b2f74dfdbd214d7f651ce3d4b80f4a18def20
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/353916
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/349850
Reviewed-by: Martin Roth <martinroth@chromium.org>
Scan the boot block when building it with C_ENVIRONMENT_BOOTBLOCK
selected.
TEST=Build and run with Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I922f761c31e95efde0975d8572c47084b91b2879
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15130
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351379
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add car_stage_entry as an optional routine in the checklist.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I52f6aefc2566beac01373dbebf3a43d35032a0df
Original-Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15129
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351378
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Pass the serial port address to FSP using a UPD value in the MemoryInit
API.
TEST=Build and run on Galileo Gen2
BUG=None
BRANCH=None
TEST=None
Change-Id: I86449d80310b7b34ac503ebd2671a4052b080730
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15079
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Martin Roth <martinroth@google.com>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/351334
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The way dispatcher table is set up prevents linker from
optimizing unused code away, we currently have raminit in ramstage.
Optimize this manually by configuring AGESA_ENTRY booleans for
romstage and ramstage separately. This will remove references in
FuncParamsInfo and DispatchTable -arrays.
All boards now include multi-core dispatcher, it has minimal footprint:
AGESA_ENTRY_LATE_RUN_AP_TASK
ACPI S3 support depends on HAVE_ACPI_RESUME being enabled:
AGESA_ENTRY_INIT_RESUME
AGESA_ENTRY_INIT_LATE_RESTORE
AGESA_ENTRY_INIT_S3SAVE
Disabled for all boards as it was not used:
AGESA_ENTRY_INIT_GENERAL_SERVICES
Change-Id: I7ec36a5819a8e526cbeb87b04dce4227a1689285
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14417
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 062ef1cca6)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350085
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Follow-up on commits a5d72a3 and 53052fe for f12 and f15.
OEM Hooks are not BiosCallOuts.
Change-Id: Iab22b0d73282a5a1a5d1344397b4430c0ebb81b5
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14888
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 90e63deeba)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350082
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The definitions of CFG_ would evaluate to incorrect values
when Options.h is included outside buildOpts.c, where all
BLDCFG_ values are defined.
Already done for f16kb.
Change-Id: I5d725b9306027c7c46c6450ab17b692fa948cf5b
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14886
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit 206e157cc1)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350080
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Tree does not have any AGESA f10 boards. Keep the Danube platform
as a sample configuration file for unlikely future use.
Change-Id: I025aff48fcd0884b45e2a0a993d82f317ede48be
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14884
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit db1b344207)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350077
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Build the <board>_checklist.html file which contains a checklist table
for each stage of coreboot. This processing builds a set of implemented
(done) routines which are marked green in the table. The remaining
required routines (work-to-do) are marked red in the table and the
optional routines are marked yellow in the table. The table heading
for each stage contains a completion percentage in terms of count of
routines (done .vs. required).
Add some Kconfig values:
* CREATE_BOARD_CHECKLIST - When selected creates the checklist file
* MAKE_CHECKLIST_PUBLIC - Copies the checklist file into the
Documenation directory
* CHECKLIST_DATA_FILE_LOCATION - Location of the checklist data files:
* <stage>_complete.dat - Lists all of the weak routines
* <stage>_optional.dat - Lists weak routines which may be optionally
implemented
TEST=Build with Galileo Gen2.
Change-Id: Ie056f8bb6d45ff7f3bc6390b5630b5063f54c527
Original-Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-on: https://review.coreboot.org/15011
Original-Reviewed-by: Martin Roth <martinroth@google.com>
(cherry-picked from commit fc3741f379)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/350072
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The VBOOT_OPROM_MATTERS configuration option signals to vboot that the
board can skip display initialization in the normal boot path. It's name
is a left-over from a time when this could only happen by avoiding to
load the VGA option ROM on x86 devices, but nowadays we have other
boards that can skip their native display initialization paths too, and
the effect to vboot is the same. (Really, we should rename oprom_matters
and oprom_loaded to display_skippable and display_initialized or
something, but I don't think that's worth the amount of repositories
this would need to touch.)
The only effect this still has in today's vboot is to reboot and
explicitly request display initialization for EC software sync on
VBOOT_EC_SLOW_UPDATE devices (which we haven't had yet on ARM). Still,
the vboot flag just declares the capability (for skipping display init),
and it should be set correctly regardless of whether that actually makes
a difference on a given platform (right now). This patch updates all
boards/SoCs that have a conditional path based on
display_init_required() accordingly.
BRANCH=None
BUG=chrome-os-partner:51145
TEST=Booted Oak, confirmed that there's no notable boot time impact.
Change-Id: I75e5cdda2ba2d111ea50ed2c7cdf94322679f1cd
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/348786
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Having CFLAGS with -Os disables -falign-function, for
unlucky builds this may delay entry to ramstage by 600ms.
Build the low-level IO functions aligned with -O2 instead.
Change-Id: Ice6781666a0834f1e8e60a0c93048ac8472f27d9
Original-Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/14414
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 08311f5033)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346627
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Using a dedicated variable is slightly less readable and makes the code
less consistent, given that other test functions are called directly in
the if statements.
Change-Id: If52b2a4268acb1e2187574d15cc73a0c1d5fe9bb
Original-Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Original-Reviewed-on: https://review.coreboot.org/14817
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry-picked from commit 1811768c64)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346519
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I6b345670db7df652b8b712b721dfe2905373e0d5
Original-Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Original-Reviewed-on: https://review.coreboot.org/14630
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: York Yang <york.yang@intel.com>
(cherry-picked from commit 0b4db13994)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346468
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Change-Id: I1bd33e423b0fcb69597e001b61c6ea916f5fe44a
Original-Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Original-Reviewed-on: https://review.coreboot.org/14622
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
(cherry-picked from commit 1eaf58be2c)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346467
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
PCI device ID of this mini-PCI-e WLAN card is 8086:088e.
With this card inserted on pcengines/apu1 mini-PCI-e slot J17,
system halts late in ramstage, in agesawrapper AMD_INIT_MID.
Offending operation is enabling PCIe ASPM L0s and L1 for the card.
That is, writing PCIe capability block Link Control [1:0] = 11b
in the card's configuration space. AGESA already has a blacklist
for the purpose of masking such unstable ASPM implementations.
Change-Id: I9623699c4ee68e5cdc244b87faf92303b01c4823
Original-Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Original-Reviewed-on: https://review.coreboot.org/8496
Original-Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Original-Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
(cherry-picked from commit a53977e232)
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/346466
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Stefan Reinauer <reinauer@google.com>
Tested-by: Stefan Reinauer <reinauer@google.com>
Not used as we link AGESA into same romstage and ramstage ELF.
Change-Id: Ia427b9c0cc88b870de75df14bba4ca337a28adff
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14395
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
