Add car_stage_entry as an optional routine in the checklist.
TEST=Build and run on Galileo Gen2
Change-Id: I52f6aefc2566beac01373dbebf3a43d35032a0df
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15129
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Pass the serial port address to FSP using a UPD value in the MemoryInit
API.
TEST=Build and run on Galileo Gen2
Change-Id: I86449d80310b7b34ac503ebd2671a4052b080730
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15079
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
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
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14417
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Follow-up on commits a5d72a3 and 53052fe for f12 and f15.
OEM Hooks are not BiosCallOuts.
Change-Id: Iab22b0d73282a5a1a5d1344397b4430c0ebb81b5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14888
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
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
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14886
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Tree does not have any AGESA f10 boards. Keep the Danube platform
as a sample configuration file for unlikely future use.
Change-Id: I025aff48fcd0884b45e2a0a993d82f317ede48be
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14884
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
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
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/15011
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When the vboot cbfs selection runs in postcar stage it should be
utilizing cbmem to locate the vboot selected region.
Change-Id: I027ba19438468bd690d74ae55007393f051fde42
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14959
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
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
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14414
Tested-by: build bot (Jenkins)
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
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/8496
Tested-by: build bot (Jenkins)
Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
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>
File buildOpts.c is a can of worms, pull platform memory
configuration in to OemCustomize.c. This array should be
assigned at runtime instead of linking a modified defaults
table.
Change-Id: I73d9d3fbc165e6c10472e105576d7c40820eaa6a
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14528
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On modern x86 platforms like apollolake, pre-RAM stages verstage and
romstage run within the cache-as-ram region. Thus, we do not need to
pass in the --xip parameter to cbfstool while adding these
stages. Introduce a new Kconfig variable NO_XIP_EARLY_STAGES which is
default false for all x86 platforms. Apollolake selects this option
since it supports code execution with CAR.
Change-Id: I2848046472f40f09ce7fc230c258b0389851b2ea
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/14623
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Update the file to match the QuarkFsp code.
TEST=Build and run on Galileo Gen2
Change-Id: I090578d32165d34863548aec0e4a38fe915683c6
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/14452
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In the case where one of the FW_MAIN regions is empty, the last file
(empty) will also appear to be first and have a zero offset, making head
complain.
This is a very borderline use case, since the FW_MAIN_ regions should
have been filled previously, but an extra check doesn't hurt.
Change-Id: I15491c5b4a5e7d1f9fb369cc5fa4e3875e2dad3b
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: https://review.coreboot.org/14472
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Switch all types to uint8_t and the like instead of u8.
Change-Id: Ia12c4ee9e21e2d3166c2f895c819357fa2ed9a94
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/14515
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a library which unifies access to Siemens specific hardware information
data. This library is meant to be used with Siemens platforms and can be
selected in Kconfig. The needed source of information has to be present
in cbfs.
This lib can be used in romstage and ramstage.
Change-Id: I2c6e003b0c123b4cf6a84906c2b133b8c38c8b1a
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/14505
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
We have not really hit this error, due the test on AGESA_UNSUPPORTED
above.
Change-Id: I6e7d136a1bb46138cc347225bc4c82cfeaff385d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14394
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We never define B1_IMAGE or B2_IMAGE. These are about building
CIMx as separate binary modules, while coreboot builds these into
same romstage or ramstage module.
Change-Id: I9cfa3f0bff8332aff4b661d56d0e7b340a992992
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/14393
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Kerry Sheh <shekairui@gmail.com>
This symbol was added to fix a Kconfig lint error after the
Broadwell DE vendorcode was added. Now that the chipset's in
the codebase, it's no longer needed.
Change-Id: Iedb166129c9265cc2cfcc406d98bde92c1a82d2f
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14384
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
An unsigned enum expression is always strictly positive;
Comparison with '>= 0' is a tautology, hence remove it.
Change-Id: I910d672f8a27d278c2a2fe1e4f39fc61f2c5dbc5
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/8207
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The codepath was untested and incomplete. It now determines the right
GBB region sizes and puts the data in.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I2cc47ddd8aa7675375ca5ed5f75632c30c65dd1e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36e026404ed049d61b677ef043a781c8c209dd93
Original-Change-Id: Ib872627740dbd8ac19fc3e2a01464457f38366ed
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336358
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14239
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This mirrors vboot's flag table.
BUG=chromium:595715
BRANCH=none
TEST=none
Change-Id: I4473eb6c0e073f555e6a692a447e8cc85f8e4eeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0fc50a6cff5ba900e6407d58a8f18db63b5946a5
Original-Change-Id: Ieabd3f9391ba256557e18386f334558d64a81694
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/336630
Original-Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14238
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The MT8173 hardware watchdog can assert an external signal which we use
to reset the TPM on Oak. Therefore we do not need to do the same
double-reset dance as on other Chromebooks to ensure that we reset in a
correct state.
Still, we have a situation where we need to reconfigure the watchdog
early in the bootblock in a way that will clear information about the
previous reboot from the status register, and we need that information
later in ramstage to log the right event. Let's reuse the same watchdog
tombstone mechanism from other boards, except that we don't perform a
second reset and the tombstone is simply used to communicate between
bootblock and ramstage within the same boot.
BRANCH=None
BUG=None
TEST=Run 'mem w 0x10007004 0x8' on Oak, observe how it reboots and how
'mosys eventlog list' shows a hardware watchdog reboot event afterwards.
Change-Id: I1ade018eba652af91814fdaec233b9920f2df01f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 07af37e11499e86e730f7581862e8f0d67a04218
Original-Change-Id: I0b9c6b83b20d6e1362d650ac2ee49fff45b29767
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/334449
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/14234
Tested-by: build bot (Jenkins)
Reviewed-by: Julius Werner <jwerner@chromium.org>
The typo is not present anymore in Family 16h (Kabini), so fix it for
the older families (Family 10h, 12h, 14h, 15h, 15h Trinity) too using
the command below.
$ git grep -l ' ne ' src/vendorcode/amd/agesa | xargs sed -i 's/ ne / be /g'
Change-Id: I9cb419251eeec79925f48a5832fac339d40f01d1
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: https://review.coreboot.org/5543
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
When doing verification of memory init code in verstage vboot
should issue a TPM_Startup(ST_STATE) instead of TPM_Startup(ST_CLEAR)
in order to preserve the flags in TPM_STCLEAR_FLAGS which include
things like physical presence. In doing so we can also skip the rest
of the TPM init work in this function in the S3 resume path.
BUG=chrome-os-partner:50633
BRANCH=glados
TEST=S3 resume on chell and ensure TPM is resumed instead of being
cleared and that 'tpmc getvf|getpf|getf' does not show any difference
in flags between boot and resume.
Change-Id: I7a48eaf7f57d2bc6ebc182178cbe60ceb2ad8863
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f059f39a0f5c2f21e564b9554efacf26a41ad794
Original-Change-Id: I647869202d2f04328764155d3de4cad9edf10ae4
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Previous-Reviewed-on: https://chromium-review.googlesource.com/332434
Original-(cherry picked from commit 5fc7792e4104523569140cd84ce313da721ec34b)
Original-Reviewed-on: https://chromium-review.googlesource.com/332542
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/14107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The Kconfig lint tool is complaining because this symbol doesn't
exist. Create a temporary definition that can be removed when
the chipset is added.
Change-Id: I6a8abffcc91773aae16721ee1f48c4c64bd6b486
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/14091
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Initial vendor codes to support Broadwell-DE SoC. This is FSP 1.0 based
project and is based on Broadwell-DE Gold release. Change has been
verified on Intel Camelback Mountain CRB.
Change-Id: I9262c9d70a58f0c7427f0658948adf080f2f6d8f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/14030
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The previous copy of FspUpdVpd.h was not up to date w.r.t. the
FSP release being used for skylake boards. Fix that.
BUG=chrome-os-partner:50863
BRANCH=None
TEST=Built and booted on chell.
Change-Id: I39896c04d35189b0fb2c903eefda4e5b7c57084a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd647f354b8d9946b2217751cf1af845f29191b7
Original-Change-Id: I4ad131af6c563c9c33eb2b9207b13617ff24385d
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/331290
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13984
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
In ChromeOS VPD spec the right name is "region".
Signed-off-by: Hannah Williams <hannah.williams@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/322851
Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-by: mukesh agrawal <quiche@chromium.org>
(cherry picked from commit 21ea0663e7f3ffe3aaea6b6ce0e1216fcd9ca23e)
BUG=chrome-os-partner:50516
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4ba9a9c65af3732fa263030640495ab5bea91d1f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 848f18e731eb11dd3037d12607d7364f95e64e34
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: Ib96036f9cd76449f170af5c3dd6ef6e8e91ded94
Original-Reviewed-on: https://chromium-review.googlesource.com/329293
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Set the UPD values for MemoryInit.
* Update the FspUpdVpd.h file which specifies the parameters for
MemoryInit.
* Add the necessary values to chip.h to enable values to come from
the mainboard's devicetree.cb file
* Add the parameters to the mainboard's devicetree.cb file
* Locate the platform configuration database file (pdat.bin)
* Copy the data values from the chip_info structure into the UPDs
* Display the UPD values
Testing on Galileo:
* Edit the src/mainboard/intel/galileo/Makefile.inc file:
* Add "select ADD_FSP_PDAT_FILE"
* Add "select ADD_FSP_RAW_BIN"
* Add "select ADD_RMU_FILE"
* Place the FSP.bin file in the location specified by CONFIG_FSP_FILE
* Place the pdat.bin files in the location specified by
CONFIG_FSP_PDAT_FILE
* Place the rmu.bin file in the location specified by CONFIG_RMU_FILE
* Build EDK2 CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc to generate
UEFIPAYLOAD.fd
* Edit .config file and add the following lines:
* CONFIG_DISPLAY_UPD_DATA=y
* Testing successful when the UPD data is displayed before the call to
MemoryInit
Change-Id: Ic64f3d97eb43ea42d9b149769fc96bf78bf804f5
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/13896
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
If a platform does verification of the memory init step, and it must
resume with the same slot that it booted from then it needs to set
the vboot context flag when resuming instead of booting. This will
affect the slot that is selected to verify and resume from.
BUG=chromium:577269
BRANCH=glados
TEST=manually tested on chell:
1) ensure that booting from slot A resumes from slot A.
2) ensure that booting from slot B resumes from slot B.
3) do RW update while booted from slot A (so the flags are set to try
slot B) and ensure that suspend/resume still functions properly using
current slot A.
4) do RW update while booted from slot B (so the flags are set to try
slot A) and ensure that suspend/resume still functions properly using
current slot B.
Change-Id: I77e6320e36b4d2cbc308cfb39f0d4999e3497be3
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Commit-Id: 4c84af7eae7b2a52a28cc3ef8a80649301215a68
Original-Change-Id: I395e5abaccd6f578111f242d1e85e28dced469ea
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/328775
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch ports the LZ4 decompression code that debuted in libpayload
last year to coreboot for use in CBFS stages (upgrading the base
algorithm to LZ4's dev branch to access the new in-place decompression
checks). This is especially useful for pre-RAM stages in constrained
SRAM-based systems, which previously could not be compressed due to
the size requirements of the LZMA scratchpad and bounce buffer. The
LZ4 algorithm offers a very lean decompressor function and in-place
decompression support to achieve roughly the same boot speed gains
(trading compression ratio for decompression time) with nearly no
memory overhead.
For now we only activate it for the stages that had previously not been
compressed at all on non-XIP (read: non-x86) boards. In the future we
may also consider replacing LZMA completely for certain boards, since
which algorithm wins out on boot speed depends on board-specific
parameters (architecture, processor speed, SPI transfer rate, etc.).
BRANCH=None
BUG=None
TEST=Built and booted Oak, Jerry, Nyan and Falco. Measured boot time on
Oak to be about ~20ms faster (cutting load times for affected stages
almost in half).
Change-Id: Iec256c0e6d585d1b69985461939884a54e3ab900
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/13638
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This symbol is not defined.
Change-Id: I2b0a3fca82d85962fc882f237b70702cab0400db
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/13647
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Baytrail FSP MR 005 adds two new fields:
AutoSelfRefreshEnable
APTaskTimeoutCnt
Add the device tree definitions.
Change-Id: I12e2a8b0b5cbeb6b7289cf91f65b25e73007a8de
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
Reviewed-on: https://review.coreboot.org/12973
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
These files aren't updated (or updatable), and as such don't need to be
copied to the RW sections.
Change-Id: Ie78936792ad651fbf8500fc7e34f0899e33a904c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13633
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This adds a new kconfig option that will back up the VBNV data
from CMOS to flash, and restore it if the CMOS data is invalid
during boot.
This allows special flags to not get lost when power is lost,
RTC reset is triggered, or CMOS is corrupted.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell:
1-boot and run "enable_dev_usb_boot"
2-reboot and check that it is enabled with crossystem
3-run "mosys nvram clear"
4-reboot and check that it is still enabled
Change-Id: I38103d100117da34471734a6dd31eb7058735c12
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8a356e616c6885d5ae3b776691929675d48a28f9
Original-Change-Id: I06e7ddff7b272e579c704914a0cf8cc14d6994e8
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324122
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13600
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Certain platforms query the recovery mode switch more than just within
vboot during the boot flow. Therefore, it's important that the first call to
get_recovery_mode_switch() is consistent through memory training because
certain platforms use the recovery mode switch to take different action
for memory training. Therefore, defer the clearing of the rec mode
switch to a place when it's known that memory is up and online.
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Three finger salute is honored on chell by retraining memory.
Change-Id: I26ea51de7ffa2fe75b9ef1401fe92f9aec2b4567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6b0de9369242e50c7ff3b164cf1ced0642c7b087
Original-Change-Id: Ia7709c7346d1222e314bf3ac7e4335a63e9a5144
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/325120
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13604
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This modifies the vbnv_flash driver to make it safe for use
in cache-as-ram by handling the global variables safely.
To make this cleaner all of the variables were moved into
one structure and referenced from there.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell using following patches to
test backup and restore of vbnv_cmos into flash
Change-Id: I3a17fa51cfd754455502ac2e5f181dae35967f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 48876561fa4fb61e1ec8f92596c5610d97135201
Original-Change-Id: Id9fda8467edcc55e5ed760ddab197ab97d1f3d25
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324121
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13599
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The VBNV region size is determined by vboot and is not really
configurable. Only the CMOS implementation defined this config
variable so switch it to use VBNV_BLOCK_SIZE defined by vboot
in vbnv_layout.h instead.
This requires updating the broadwell/skylake cmos reset functions
to use the right constant.
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=manually tested on chell
Change-Id: I45e3efc2a22efcb1470bbbefbdae4eda33fc6c96
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e2b803ff3ac30ab22d65d1e62aca623730999a1d
Original-Change-Id: I4896a1a5b7889d77ad00c4c8f285d184c4218e17
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324520
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13598
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Add a wrapper around the vbnv implementations and call into the different
backend functions from there. Also move some of the common functions to
the common code and simplify the backend drivers. This will allow some
of the code to be re-used so the CMOS backend can backup the data into
the flash backend.
One side effect of this is that the cache of VBNV was removed from CMOS
and EC backends and moved into the VBNV wrapper, but the flash backend
also still has a separate cache because it has more state and complexity
in the implementation. The wrapper cached data is not used for normal
vbnv_read/vbnv_write because some callers need the ability to force a
write if the backend storage is cleared (i.e. CMOS clear).
BUG=chrome-os-partner:47915
BRANCH=glados
TEST=build and boot on chell
Change-Id: I4d2e0e99af7e8a44aec77ad9991507401babcca6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c30f60434a64f6c0eb9ede45d48ddafff19dd24f
Original-Change-Id: Ia97f6607c5ad837b9aa10b45211137221ccb93a0
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324120
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13597
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Vboot keeps track of the size of the hashed region in each
RW slot. While that size was being used to calculate the hash
it wasn't being honored in restricting the access within the
FMAP region for that RW slot. To alleviate that create a sub
region that covers the hashed data for the region in which
we boot from while performing CBFS accesses.
BUG=chrome-os-partner:49764
BUG=chromium:445938
BRANCH=glados
TEST=Built and booted chell with cbfstool and dev-util patches.
Change-Id: I1a4f45573a6eb8d53a63bc4b2453592664c4f78b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4ac9e84af5b632e5735736d505bb2ca6dba4ce28
Original-Change-Id: Idca946926f5cfd2c87c4a740ad2108010b6b6973
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324093
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13586
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When vboot_handoff_flag() is called in the bootblock or a separate
verstage there's no memory nor the possibility of dram coming online.
Therefore, don't bother to attempt call cbmem_find().
BUG=chrome-os-partner:44827
BRANCH=glados
TEST=Built chell with separate verstage which pulls in vboot_common.c
dependency. No more linking errors w/ cbmem_find() not being
around.
Change-Id: I494c93adc1c00459fdfaa8ce535c6b4c884ed0fb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 414ce6aeaff657dc90289b25e5c883562189b154
Original-Change-Id: I8a5f2d154026ce794a70e7ec38883fa3c28fb6e7
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/324070
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13580
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Sometimes it's necessary for the platform to perform clean up
tasks prior to reboot when employing vboot. For example, x86 systems
that resume and do vboot verification may need to clear their
sleep control register prior to doing a cold reset so that the
next boot doesn't appear to be a resume. Allow that hook by
introducing vboot_platform_prepare_reboot().
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Ensure vboot_platform_prepare_reboot() called from vboot_reboot().
Change-Id: I622c9181d9fa3048204e3df3223d5dd4b458abca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f31ffc40bde002dec398fd4dd9d2ee9d65df0d7b
Original-Change-Id: I97318cec34494a7fc4b1ecf2cb22715d20e730ff
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323501
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13575
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
For x86 systems which resume through the reset vector one needs to
ensure the the RW slot taken at resume time matches the one at
boot time. The reason is that any assets pulled out of the boot
media need to match how the platform previously booted. To do
that one needs obtain the hash digest of the chosen slot, and it
needs to be saved in a secure place on the normal boot path. On
resume one needs to retrieve the hash digest back to compare it
with the chosen slot. If they don't match resuming won't be
possible.
BUG=chrome-os-partner:46049
BRANCH=glados
TEST=Suspended and resumed on chell. Also, tested with an EC build
which returns a bad hash to ensure that is properly caught.
CQ-DEPEND=CL:323460
Change-Id: I90ce26813b67f46913aa4026b42d9490a564bb6c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 01a42c0ecfc6d60d1d2e5e36a86781d91d5c47a9
Original-Change-Id: I6c6bdce7e06712bc06cc620a3d7a6a6250c59c95
Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/323500
Original-Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/13574
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This requires payload integration somewhere to be useful, because
without that, adding it will (hopefully) break the signature.
Change-Id: I67b8267e5040e26353df02d258e92a0610e19a52
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13560
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Use the flags to preset the GBB flags field. The Kconfig defaults are
chosen for a "developer" configuration.
Change-Id: Ifcc05aab10b92a2fc201b663df5ea47f92439a3f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13559
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The GBB contains hardware-specific data plus some configuration. The
latter isn't supported by this change yet and will come later.
The fields that are supported (hardware ID, bmpfv, vboot keys) are
configurable through Kconfig and point to Chrome OS-style default (eg.
developer keys).
While adding vboot keys, the two keys used to sign RW regions are also
added to Kconfig, even if not yet used.
Change-Id: Icfba6061ca83182df560cd36052fbb257826d4b0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13558
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Strip out the AMD internal version tag, e.g.
* @e \$Revision: 63425 $ @e \$Date: 2011-12-22 11:24:10 -0600 (Thu, 22 Dec 2011) $
which are false/inconsistent and serve no real meaning or purpose now.
Change-Id: I4cca0899eba66a1c361ba784c5ac0222b0ee1aa6
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: https://review.coreboot.org/7516
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since this code is pulled in through commonlib, it will break compilation
of cbfstool on OSX.
Change-Id: I342bfa7e755aa540c4563bb5cd8cccacee39d188
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/13525
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Some trivial cleanup.
Change-Id: I866efc4939b5e036ef02d1acb7b8bb8335671914
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13427
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Just rename the two scripts that are in the src/ tree to give them
a .sh extension. Since we generally expect files in the src directory
to be source files, this allows to identify these as scripts easily.
Change-Id: I0ab20a083880370164488d37a752ba2d5a192fdc
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There were several spots in the tree where the path to a per class
object file was hardcoded. To make use of the src-to-obj macro for
this, it had to be moved before the inclusion of subdirs. Which is
fine, as it doesn't have dependencies beside $(obj).
Tested by verifying that the resulting coreboot.rom files didn't change
for all of Jenkins' abuild configurations.
Change-Id: I2eb1beeb8ae55872edfd95f750d7d5a1cee474c4
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/13180
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds a check to the VPD parsing code to avoid reading the
whole thing if the first byte ('type' of the first VPD entry) is 0x00
or 0xff. These values match the TERMINATOR and IMPLICIT_TERMINATOR types
which should never occur as the first entry, so this usually means that
the VPD FMAP section has simply never been initialized correctly. This
early abort avoids wasting time to read the whole section from SPI flash
(which we'd otherwise have to since we're not going to find a Google VPD
2.0 header either).
BRANCH=None
BUG=None
TEST=Booted Oak, confirmed that VPD read times dropped from 100ms to
1.5ms.
Change-Id: I9fc473e06440aef4e1023238fb9e53d45097ee9d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 20a726237e03941ad626a6146700170a45ee7720
Original-Change-Id: I09bfec3c24d24214fa4e9180878b58d00454f399
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322897
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/13467
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This patch adds three timestamps to coreboot and the cbmem utility that
track the time required to read in the Chrome OS Vital Product Data
(VPD) blocks (RO and RW). It's useful to account for these like all
other large flash accesses, since their size is variable.
BRANCH=None
BUG=None
TEST=Booted Oak, found my weird 100ms gap at the start of ramstage
properly accounted for.
Change-Id: I2024ed4f7d5e5ae81df9ab5293547cb5a10ff5e0
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b97288b5ac67ada56e2ee7b181b28341d54b7234
Original-Change-Id: Ie69c1a4ddb6bd3f1094b3880201d53f1b5373aef
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322831
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://review.coreboot.org/13139
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Add flag handling for CONFIG_VBOOT_EC_SLOW_UPDATE to indicate
to vboot that it should show the "critical update" screen during
software sync for EC+PD.
In order to make this work on x86 where we do not run graphics
init in the normal path add handling for CONFIG_VBOOT_OPROM_MATTERS
and indicate to vboot when the option rom has been loaded.
BUG=chrome-os-partner:49560
BRANCH=glados
TEST=Build and boot on chell in normal mode with an EC update payload
and ensure that it reboots to enable graphics, shows the "critical
update" screen, and then reboots to disable graphics init again.
Change-Id: I5ca46457798a22e9b08aa2febfec05b01aa788f9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 6a1bb8572c3485f64b9f3e759288321b44184e66
Original-Change-Id: I9f66caaac57bb9f05bc6c405814469ef7ddf4d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/322781
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/13073
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Setup an initial rule to make use of the updatable CBFS regions in fmap.
Change-Id: I1fe1c6e7574854b735760c85590da6e297f6e687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/13060
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
CB used to clear recovery status towards romstage end after FSP
memory init. Later inside FSP silicon init due to HSIO CRC mismatch
it will request for an additional reset.On next boot system resume
in dev mode rather than recovery because lost its original state
due to FSP silicon init reset.
Hence an additional 1 reset require to identify original state.
With this patch, we will get future platform reset info during romstage
and restore back recovery request flag so, in next boot CB can maintain
its original status and avoid 1 extra reboot.
BUG=chrome-os-partner:43517
BRANCH=none
TEST= build and booted Kunimitsu and tested RO mode
Change-Id: Ibf86ff2b140cd9ad259eb39987d78177535cd975
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 40ddc21a97b318510116b7d5c4314380778a40f7
Original-Change-Id: Ia52835f87ef580317e91931aee5dd0119dea8111
Original-Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/302257
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12975
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This corresponds with the changes that have already gone into the
soc/intel/skylake chip.h file and is needed to get skylake platforms
building again.
Change-Id: I15bfee4eff50d6632659953ec8f97a39d8810db3
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/13022
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I think this has a fairly low likelyhood of happening, but if AGESA
can't determine the voltage of the memory, it assignes a value of 255
to the variable that it later uses to read from an 3-value array. There
is an assert, but that doesn't halt AGESA, so it would use some random
value. If the voltage can't be determined, fall back to 1.5v as the
default value.
Fixes coverity warning 1294803 - Out-of-bounds read
Change-Id: Ib9e568175edbdf55a7a4c35055da7169ea7f2ede
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12855
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This has been broken out from http://review.coreboot.org/#/c/10581/
Change-Id: Ia6153115ff75e21657fa8c244c9eb993d0d63772
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://review.coreboot.org/11025
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Martin Roth <martinroth@google.com>
Provide a common routine to hash the contents of a cbfs
region. The cbfs region is hashed in the following order:
1. potential cbfs header at offset 0
2. potential cbfs header retlative offset at cbfs size - 4
3. For each file the metadata of the file.
4. For each non-empty file the data of the file.
BUG=chrome-os-partner:48412
BUG=chromium:445938
BRANCH=None
TEST=Utilized in chromeos cros_bundle_firmware as well as at
runtime during vboot verification on glados.
Change-Id: Ie1e5db5b8a80d9465e88d3f69f5367d887bdf73f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/12786
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This file became obsolete when FMAP code moved to src/lib/ and is no
longer built by any Makefile. Let's remove it to avoid confusing people.
Change-Id: I55639af28f9f3d4c4cb0429b805e3f120ecc374e
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/12753
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
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>
ELOG requires SPI_FLASH, so don't bother selecting if if SPI_FLASH isn't
available.
Change-Id: I080ac47e74aba820c94409d4913647abee215076
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/12661
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
verstage, romstage, and payload can be added through infrastructure now.
Change-Id: Ib9e612ae35fb8c0230175f5b8bca1b129f366f4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: https://review.coreboot.org/12549
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Put dependecies on CHROMEOS's selection of the Kconfig symbols
TPM_INIT_FAILURE_IS_FATAL and SKIP_TPM_STARTUP_ON_NORMAL_BOOT to match
the dependencies on those symbols where they are defined in
src/drivers/pc80/tpm/Kconfig
The file that uses these only gets built in if CONFIG_LPC_TPM is
selected selected.
The warnings were:
warning: (CHROMEOS) selects TPM_INIT_FAILURE_IS_FATAL which has unmet
direct dependencies (PC80_SYSTEM && LPC_TPM)
warning: (CHROMEOS) selects SKIP_TPM_STARTUP_ON_NORMAL_BOOT which has
unmet direct dependencies (PC80_SYSTEM && LPC_TPM)
Change-Id: I7af00c79050bf511758bf29e3d57f6ff34d2a296
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/12497
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There are few drawbacks reading VPD from SPI flash in user land, including
"lack of firmware level authority" and "slow reading speed".
Since for many platforms we are already reading VPD in firmware (for
example MAC and serial number), caching the VPD data in CBMEM should
will speed up and simplify user land VPD processing without adding
performance cost.
A new CBMEM ID is added: CBMEM_ID_VPD, referring to a structure containing
raw Google VPD 2.0 structure and can be found by the new LB_TAG_VPD in
Coreboot tables.
BRANCH=smaug
BUG=chrome-os-partner:39945
TEST=emerge-smaug coreboot chromeos-bootimage # and boots successfully.
[pg: lots of changes to make it work with what happened in upstream
since 2013]
Change-Id: If8629ac002d52abed7b480d3d06298665613edbf
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 117a9e88912860a22d250ff0e53a7d40237ddd45
Original-Change-Id: Ic79f424a6e3edfb6c5d168b9661d61a56fab295f
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/285031
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/12453
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Alignment of Intel Firmware Support Package 1.0 Rangeley
header and source files to the revision: POSTGOLD4
Detail changelog can be found at http://www.intel.com/fsp
FSP release date September 24, 2015
Change-Id: If1a6f95aed3e9a60af9af8cf9cd466a560ef0fe2
Signed-off-by: Marcin Wojciechowski <marcin.wojciechowski@intel.com>
Reviewed-on: http://review.coreboot.org/12418
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
1. This is required the BLOB change Ie86bb0cf
AMD Merlin Falcon: Update to CarrizoPI 1.1.0.1 (Binary PI 1.5)
2. This is tested on Bettong Alfa(DDR3) and Beta(DDR4). Both of the
boards can boot to Windows 10. PCIe slots, USB and NIC work.
Change-Id: I6cf3e333899f1eb2c00ca84c96deadeea0e23b07
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11752
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Intel i89xx is a communications chipset that pairs with
Sandy(Ivy)bridge processors. It has a lot in common with
the bd82x6x chipset, but fewer devices and options.
Change-Id: I11bcd1edc80f72a1b2521def9be0d1bde5789a79
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/12166
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
"-u" is only for GNU cp. Cp of BSD and Solaris don't
take this option.
It is not necessary to compare the files before copying.
Change-Id: I60cf57991275db0e075278f77a95ca5b8b941c7f
Signed-off-by: Zheng Bao <zheng.bao@amd.com>
Signed-off-by: Zheng Bao <fishbaozi@gmail.com>
Reviewed-on: http://review.coreboot.org/11601
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
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>
Change-Id: I3df66320d0bc18221f947b47e7f09533daafabad
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11108
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
There are some inconsistencies in AMDs APIs between the coreboot
code and the vendorcode code. Unify the API.
UINTN maps to uintptr_t in UEFI land. Do the same
here. Also switch the other UEFI types to map to
fixed size types.
Change-Id: Ib46893c7cd5368eae43e9cda30eed7398867ac5b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10601
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
While migrating from vboot1 to vboot2, the tpm_init was moved out of
vboot library and implemented in coreboot. However, while doing this,
the initial factory flow was missed.
We need to ensure following flow for tpm_init:
1. Perform tpm_init
2. If tpm_init fails, set secdata_context flag to indicate to vboot
that tpm needs reboot.
3. Call vb2_api_phase1
4. If vb2_api_phase1 returns error code saying boot into recovery,
continue booting into recovery. For all other error codes, save
context if required and reboot.
[pg: everything but step 2 was already done, so this upstream commit is
quite minimal]
CQ-DEPEND=CL:300572
BUG=chrome-os-partner:45462
BRANCH=None
TEST=Verified behavior on smaug. Steps to test:
1. Reboot into recovery
2. tpmc clear
3. Reboot device
Expected Behavior: Device should reboot after Enabling TPM. Should not
enter recovery
Confirmed that the device behaves as expected.
Change-Id: I72f08d583b744bd77accadd06958c61ade298dfb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85ac93137f3cfb28668dcfa18dfc773bf910d44e
Original-Change-Id: I38ab9b9d6c2a718ccc8641377508ffc93fef2ba1
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/300570
Original-Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12205
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
vboot handoff should look at flags in struct vb2_shared_data when
translating flags to VBSD_BOOT_REC_SWITCH_ON because
VBSD_BOOT_REC_SWITCH_ON is supposed to indicate whether manual recovery was
triggered or not while vb2_sd->recovery_reason will be able to provide
that information only in some cases after CL:307586 is checked in.
For example, this fixes a recovery loop problem: Without this fix,
vb2_sd->recovery_reason won't be set to VB2_RECOVERY_RO_MANUAL when user
hits esc+refresh+power at 'broken' screen. In the next boot,
recovery_reason will be set to whatever reason which caused 'broken'
screen. So, if we check recovery_reason == VB2_RECOVERY_RO_MANUAL, we
won't set vb_sd->flags to VBSD_BOOT_REC_SWITCH_ON. That'll cause a
recovery loop because VbBootRecovery traps us again in the 'broken'
screen after not seeing VBSD_BOOT_REC_SWITCH_ON.
BUG=chromium:501060
BRANCH=tot
TEST=test_that -b veyron_jerry suite:faft_bios
Change-Id: I69a50c71d93ab311c1f7d4cfcd7d454ca1189586
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d9679b02f6d21ed903bb02e107badb0fbf7da46c
Original-Change-Id: I3da642ff2d05c097d10db303fc8ab3358e10a5c7
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/307946
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/12199
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On my Foxconn nT-A3500 on cold boot the board doesn't survive the soft
reboot in the UsbRxMode path and the vendor bios doesn't touch this
Cg2Pll voltage setting either.
The fixup code for UsbRxMode in src/vendorcode/amd/cimx/sb800/SBPort.c
doesn't seem to "CG PLL multiplier for USB Rx 1.1 mode", but rather
lowers the Cg2Pll voltage from the hw default of 1.222V to 1.1V
by setting Cg2Pll_IVR_TRIM in CGPllConfig5 to 1000.
See also USB_PLL_Voltage which is only used in the UsbRxMode code path.
However if this is already the efuse/eprom default for the SB800 then
UsbRxMode is a no-op, so whether or not it gets executed depends on the
very exact hw revision of the southbridge chip and could change between
two instances of the same board.
UsbRxMode used to be unitialized and was first set to default to 1
in http://review.coreboot.org/6474 (change I32237ff9,
southbridge/amd/cimx/sb800: Uninitialized variables in config func):
> > Why initialize those to 1? (just curious)
> See src/vendorcode/amd/cimx/sb800/SBTYPE.h
> git grep 'SbSpiSpeedSupport\|UsbRxMode'
> src/vendorcode/amd/cimx/sb800/SBTYPE.h
I could not find a corresponding errata in the SB800 errata list,
however errata 15 (USB Resets Asynchronously With Port CF9h Hard Reset)
might play into this being unsafe to do since the code uses CF9h to
reset.
So its possible that while previously undefined it still ended up
defaulting to 0 and the codepath exercised on my board is simply
buggy or there is a difference between a true "SB800" and the
"A50 Hudson M1" presumably used on my board.
Change-Id: I33f45925e222b86c0a97ece48f1ba97f6f878499
Signed-off-by: Tobias Diedrich <ranma+coreboot@tdiedrich.de>
Reviewed-on: http://review.coreboot.org/10549
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Please don't remove chipsets and mainboards without discussion and input
from the owners. Someone was asking about cougar canyon 2 just a couple
of weeks ago - there's obviously still interest.
This reverts commit fb50124d22.
Change-Id: Icd7dcea21fa4a7808b25bb8727020701aeebffc9
Signed-off-by: Martin Roth <martinroth@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/12128
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
We need to special-case filling out the vboot structures when
we use CBFS instead of vboot's custom indexed format, otherwise
(due to the way the CBFS header looks), it will try to write several
million entries.
Change-Id: Ie1289d4a19060bac48089ff70e5cfc04a2de373f
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11914
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This chip is still being used and should not have been deleted. It's
a current intel chip, and doesn't even require an ME binary.
This reverts commit 959478a763.
Change-Id: I78594871f87af6e882a245077b59727e15f8021a
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11860
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To support x86 verstage one needs a working buffer for
vboot. That buffer resides in the cache-as-ram region
which persists across verstage and romstage. The current
assumption is that verstage brings cache-as-ram up
and romstage tears cache-as-ram down. The timestamp,
cbmem console, and the vboot work buffer are persistent
through in both romstage and verstage. The vboot
work buffer as well as the cbmem console are permanently
destroyed once cache-as-ram is torn down. The timestamp
region is migrated. When verstage is enabled the assumption
is that _start is the romstage entry point. It's currently
expected that the chipset provides the entry point to
romstage when verstage is employed. Also, the car_var_*()
APIs use direct access when in verstage since its expected
verstage does not tear down cache-as-ram. Lastly, supporting
files were added to verstage-y such that an x86 verstage
will build and link.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using separate verstage.
Change-Id: I097aa0b92f3bb95275205a3fd8b21362c67b97aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11822
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When a separate verstage is employed the verstage file
was just being added through the cbfs-files mechanism.
However, that doesn't allow one to specify other flags
that aren't supported that an architecture may require.
The x86 architecture is one of those entities in that
it needs its verstage to be XIP. To that end provide
a mechanism for adding verstage with options.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados using his mechansim on x86.
Change-Id: Iaba053a55a4d84d8455026e7d6fa548744edaa28
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11819
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
In order to support x86 verstage proper the work buffer
needs to live in cache-as-ram. However, after cache-as-ram
is torn down one still needs the verification results to
know which slot was selected. Though the platforms with
a dedicated SRAM can just use the work buffer in SRAM, the
x86 cache-as-ram platforms need a place to stash the
results. For that situation cbmem is employed. This works
because when cbmem is initialized cache-as-ram is still
enabled. The VBOOT_DYNAMIC_WORK_BUFFER case assumes
verified boot doesn't start until after cbmem is up. That
doesn't change, but it's a goal to get rid of that option
entirely once all other x86 platforms are moved over to
pre-romstage vboot.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados with pre-romstage verification
as well as VBOOT_DYNAMIC_WORK_BUFFER case.
Change-Id: I7eacd0edb2b6ca52b59b74075d17c00b50676d4c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11821
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
For the purpose of isolating the work buffer logic
the surface area of the API was slimmed down. The
vb2_working_data structure is no longer exposed,
and the function signatures are updated accordingly.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: If64184a79e9571ee8ef9822cfce1eda20fceee00
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11818
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Now that cbfs is adding more metadata in the cbfs file
header one needs to access that metadata. Therefore,
add struct cbfsf which tracks the metadata and data
of the file separately. Note that stage and payload
metadata specific to itself is still contained within
the 'data' portion of a cbfs file. Update the cbfs
API to use struct cbfsf. Additionally, remove struct
cbfsd as there's nothing else associated with a cbfs
region aside from offset and size which tracked
by a region_device (thanks, CBFS_ALIGNMENT!).
BUG=None
BRANCH=None
TEST=Built and booted through end of ramstage on qemu armv7.
Built and booted glados using Chrome OS.
Change-Id: I05486c6cf6cfcafa5c64b36324833b2374f763c2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11679
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Up to now, the multi-CBFS code path merely looked up files in the "boot
ro" image (ie. the default), disregarding the specified fmap region to
use for CBFS.
The code still relies on the master header being around, which on the
upside allows it to skip an offset at the beginning of the region (eg.
for ARM bootblocks).
This will change later (both the reliance on the master header and the
presence of the bootblock like this).
Change-Id: Ib2fc03eac8add59fc90b4e601f6dfa488257b326
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/11805
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
mohonpeak is the reference board for Rangeley. I doubt anyone uses it
or cares about it. We jokingly refer to it as "Moron Peak". It's code
with no known users, so we shouldn't be hauling it around for the
eventuality that someone might use it in the future.
Change-Id: Id3c9fc39e1b98707d96a95f2a914de6bbb31c615
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11790
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
We already have two other code paths for this silicon. Maintaining the
FSP path as well doesn't make much sense. There was only one board to
use this code, and it's a reference board that I doubt anyone still
owns or uses.
Change-Id: I4fcfa6c56448416624fd26418df19b354eb72f39
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/11789
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin@das-labor.org>
Certain chipsets provide their own main symbol for verstage.
Therefore, it's necessary to know this so that those chipsets
can leverage the common verstage flow.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built nyan using this option.
Change-Id: If80784aa47b27f0ad286babcf0f42ce198b929e9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In order to support FSP 1.1 relocation within cbfstool
the relocation code needs to be moved into commonlib.
To that end, move it. The FSP 1.1 relocation code binds
to edk2 UEFI 2.4 types unconditionally which is separate
from the FSP's version binding.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted glados.
Change-Id: Ib2627d02af99092875ff885f7cb048f70ea73856
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11772
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
vboot_handoff_flag was duplicating the logic to grab the handoff info, that is
already made available with vboot_get_handoff_info.
This uses vboot_get_handoff_info in vboot_handoff_flag instead.
Change-Id: I28f1decce98f988f90c446a3a0dbe7409d714527
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11498
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The vboot verification in a stage proper is unified
replacing duplicate code in the tegra SoC code. The
original verstage.c file is renamed to reflect its
real purpose. The support for a single verstage flow
is added to the vboot2 directory proper.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built glados.
Change-Id: I14593e1fc69a1654fa27b512eb4b612395b94ce5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11744
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This moves a few vboot-prefixed functions that were defined in chromeos.c to
vboot_common.c, since those are only relevant to vboot and depend on the vboot
handoff data. This allows more separation between CONFIG_CHROMEOS and what
CONFIG_CHROMEOS selects, so that each separate option (such as
CONFIG_VBOOT_VERIFY_FIRMWARE) can be enabled separately.
Thus, the actual definitions of these functions will only be declared when
CONFIG_VBOOT_VERIFY_FIRMWARE is set, so the check before calling
vboot_skip_display_init in bootmode was also adapted.
Change-Id: I52f8a408645566dac0a2100e819c8ed5d3d88ea5
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11497
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This removes the dependency on chromeos and vboot for the sw write protect state
function: vboot_get_sw_write_protect, renamed to get_sw_write_protect_state to
both reflect this change and become consistent with the definition of
get_write_protect_state that is already in use.
Change-Id: I47ce31530a03f6749e0f370e5d868466318b3bb6
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11496
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of reaching into src/include and re-writing code
allow for cleaner code sharing within coreboot and its
utilities. The additional thing needed at this point is
for the utilities to provide a printk() declaration within
a <console/console.h> file. That way code which uses printk()
can than be mapped properly to verbosity of utility parameters.
Change-Id: I9e46a279569733336bc0a018aed96bc924c07cdd
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/11592
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Currently, erase operation only works if the region is sector-aligned.
These asserts ensure we can erase the region when it's all used up.
Erase operation can be updated to handle unaligned erases by read,
update, write-back cycle. However, these asserts will still remain useful
in case the adjacent region contains critical data and mis-updating it
can cause a critical failure.
Additionaly we should write a FAFT test but it's more reliable to catch
it here since FAFT can fail in many ways.
BUG=none
BRANCH=master
TEST=tested on samus using misaligned nvram region
Change-Id: I3add4671ed354d9763e21bf96616c8aeca0cb777
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fc001a4d3446cf96b76367dde492c3453aa948c6
Original-Change-Id: Ib4df8f620bf7531b345364fa4c3e274aba09f677
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/297801
Reviewed-on: http://review.coreboot.org/11654
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This is required the BLOB change Icb7a4f07
"AMD Merlin Falcon: Update to CarrizoPI 1.1.0.0 (Binary PI 1.4)"
This is tested on Bettong Alfa(DDR3) and Beta(DDR4). Both of the
boards can boot to Windows 8.1. PCIe slots, USB and NIC work.
Change-Id: Ibe141c16f8f9eac2adc5d5f45a1f354fb2a7f33c
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11148
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
This is required the BLOB change I67817dc59
AMD Steppe Eagle: Update to MullinsPI 1.0.0.A (Binary PI 1.1).
This is tested on Olive Hill Plus. The board can boot to Windows 7.
PCIe slot, USB and NIC work.
Change-Id: I605df26b61bdffabd74846206ad0b7bf677ebed1
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/11225
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
FSP has some unique attributes which makes integration
cumbersome:
1. FSP header files do not include the types they need. Like
EDKII development it's expected types are provided by the
build system. Therefore, one needs to include the proper
files to avoid compilation issues.
2. An implementation of FSP for a chipset may use different
versions of the UEFI PI spec implementation. EDKII is a
proxy for all of UEFI specifications. In order to provide
flexibility one needs to binding a set of types and
structures from an UEFI PI implementation.
3. Each chipset FSP 1.1 implementation has a FspUpdVpd.h
file which defines it's own types. Commonality between
FSP chipset implementations are only named typedef
structs. The fields within are not consistent. And
because of FSP's insistence on typedefs it makes it
near impossible to forward declare structs.
The above 3 means one needs to include the correct UEFI
type bindings when working with FSP. The current
implementation had the SoC picking include paths in the
edk2 directory and using a bare <uefi_types.h> include.
Also, with the prior fsp_util.h implementation the SoC's
FSP FspUpdVpd.h header file was required since for providing
all the types at once (Generic FSP 1.1 and SoC types).
The binding has been changed in the following manner:
1. CONFIG_UEFI_2_4_BINDING option added which FSP 1.1
selects. No other bindings are currently available,
but this provides the policy.
2. Based on CONFIG_UEFI_2_4_BINDING the proper include
paths are added to the CPPFLAGS_common.
3. SoC Makefile.inc does not bind UEFI types nor does
it adjust CPPFLAGS_common in any way.
4. Provide a include/fsp directory under fsp1_1 and
expose src/drivers/intel/fsp1_1/include in the
include path. This split can allow a version 2,
for example, FSP to provide its own include files.
Yes, that means there needs to be consistency in
APIs, however that's not this patch.
5. Provide a way for code to differentiate the FSP spec
types (fsp/api.h) from the chipset FSP types
(fsp/soc_binding.h). This allows for code re-use that
doesn't need the chipset types to be defined such as
the FSP relocation code.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=Built and booted on glados.
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Change-Id: I894165942cfe36936e186af5221efa810be8bb29
Reviewed-on: http://review.coreboot.org/11606
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Tested-by: build bot (Jenkins)
There's no reason to have a separate verstage.ld now
that there is a unified stage linking strategy. Moreover
verstage support is throughout the code base as it is
so bring in those link script macros into the common
memlayout.h as that removes one more specific thing a
board/chipset needs to do in order to turn on verstage.
BUG=chrome-os-partner:44827
BRANCH=None
TEST=None
Change-Id: I1195e06e06c1f81a758f68a026167689c19589dd
Signed-off-by: Aaron Durbin <adubin@chromium.org>
Reviewed-on: http://review.coreboot.org/11516
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With VIRTUAL_DEV_SWITCH moved under 'config CHROMEOS' in all of the
mainboards, this is no longer needed.
Change-Id: I5fbea17969f6b0c3b8a5dcd519ab9d36eb2ad6f1
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: http://review.coreboot.org/11337
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
One may prefer to include vboot from another directory than 3rdparty for
convenience. This is especially the case in Libreboot, where 3rdparty is not
checked out at all.
Change-Id: I13167eb604a777a2ba87c3567f134ef3ff9610e4
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11116
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
$(obj) might be defined either as a relative or an absolute path. Thus, it has
to be filtered out before adding $(top) to it (in case of an absolute path) when
building vboot. It is then provided separately in CFLAGS (as an absolute path).
In addition, VB2_LIB inherits $(obj), so it might also already be an absolute
path, and prefixing $(top) to it doesn't apply. Thus, the absolute path to it
should be passed to the vboot make command.
Change-Id: I13e893ebdf22c4513ee40d9331a30ac7de8f9788
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Reviewed-on: http://review.coreboot.org/11120
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The AMD AGESA binaryPI sources were incorrectly committed to
3rdparty/blobs. Move them from blobs to vendorcode and fix
Kconfig and Makefile.inc to match.
Change-Id: I55a777553c1203464d7f7f4293b361fedcfa3283
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10982
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The *_SELECTED Kconfig variables are not needed with the
options contained within "if CPU_AMD_AGESA_BINARY_PI"
introduced in e4c17ce8. It also removes the need to
source and select the default prior to selecting the
AGESA source or AGESA PI option.
Change-Id: Iffa366f575f7f155bd6c7e7ece2a985f747c83be
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10981
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Make SB800 code compile with x64 compiler
These fixes probably apply 1:1 to the other SB components
in that directory.
Change-Id: I9ff9f27dff5074d2faf41ebc14bfe50871d9c7f7
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Signed-off-by: Scott Duplichan <scott@notabs.org>
Reviewed-on: http://review.coreboot.org/10573
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
1. Use enable_imc_thermal_zone to enable fan control.
2. The ACPI method ITZE works on Ubuntu 14.04 and Windows 7
but does not work on Windows 8, so I didn't use it.
After this issue is fixed, I'll add ACPI_ENABLE_THERMAL_ZONE
in bettong/Kconfig.
3. Fan control works on Bettong. I used "APU Validation Toolkit"
to test on Windows 8. This tool can put load to APU. The fan's
behaviour is just like bettong/fchec.c defined. When the temperature
is 40 Celsius, the fan start to run.
Change-Id: I0fc22974a7a7cf3f6bdf5f1c66be95219a177e12
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10721
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Binary PI doesn't provide fan control lib.
HwmLateService.c and ImcLib.c are ported from Kabini PI.
I have tested on AMD Bettong. The two files work.
Change-Id: Ia4d24650d2a5544674e9d44c502e8fd9da0b55d3
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10719
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
We've seen an increasing need to reduce stack sizes more and more for
space reasons, and it's always guesswork because no one has a good idea
how little is too litte. We now have boards with 3K and 2K stacks, and
old pieces of common code often allocate large temporary buffers that
would lead to very dangerous and hard to detect bugs when someone
eventually tries to use them on one of those.
This patch tries improve this situation at least a bit by declaring 2K
as the minimum stack size all of coreboot code should work with. It
checks all function frames with -Wstack-usage=1536 to make sure we don't
allocate more than 1.5K in a single buffer. This is of course not a
perfect test, but it should catch the most common situation of declaring
a single, large buffer in some close-to-leaf function (with the
assumption that 0.5K is hopefully enough for all the "normal" functions
above that).
Change one example where we were a bit overzealous and put a 1K buffer
into BSS back to stack allocation, since it actually conforms to this
new assumption and frees up another kilobyte of that highly sought-after
verstage space. Not touching x86 with any of this since it's lack of
__PRE_RAM__ BSS often requires it to allocate way more on the stack than
would usually be considered sane.
BRANCH=veyron
BUG=None
TEST=Compiled Cosmos, Daisy, Falco, Blaze, Pit, Storm, Urara and Pinky,
made sure they still build as well as before and don't show any stack
usage warnings.
Change-Id: Idc53d33bd8487bbef49d3ecd751914b0308006ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8e5931066575e256dfc2295c3dab7f0e1b65417f
Original-Change-Id: I30bd9c2c77e0e0623df89b9e5bb43ed29506be98
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236978
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9729
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Baytrail FSP Gold4 release added 5 PCD options. Update UPD_DATA_REGION
structure to include these new PCD options and initialized the setting
when given in devicetree.cb.
Change-Id: Ic343e79479464972455e42f9352b3bb116c6f80f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/10838
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
Bay Trail SOCs do not integrate LAN controller hence Baytrail FSP has
no LAN control function. Remove PcdEnableLan option from
UPD_DATA_REGION structure.
Change-Id: I9b4ec9d72c8c60b928a6d9755e94203fb90b658f
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/10837
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This can be a problem with freshly updated devices that are periodically
powered on while closed (as explained in the bug report).
In this case, just don't count down. In case of actual errors (where we
want the system to fall back to the old code), this now means that the
retries have to happen with the lid open.
Bump vboot's submodule revision for the vboot-side support of this.
BUG=chromium:446945
TEST=to test the OS update side, follow the test protocol in
https://code.google.com/p/chromium/issues/detail?id=446945#c43
With a servo, it can be sped up using the EC console interface to start
the closed system - no need to wait 60min and plugging in power to get
to that state.
Change-Id: I0e39aadc52195fe53ee4a29a828ed9a40d28f5e6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10851
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change the FrameBufferSize field from UINT64 to UINT32 to match the
Platform Initialization 2.4 specification.
BRANCH=none
BUG=None
TEST=Build and run on cyan
Change-Id: I28dc0608675ed5840863ecd15bd2f57e6b2f4c1d
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10834
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan A. Kollasch <jakllsch@kollasch.net>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix up all the code that is using / to use >> for divisions instead.
Change-Id: I8a6deb0aa090e0df71d90a5509c911b295833cea
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10819
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The many different places to put vboot verification in can be confusing.
Instead of using libverstage (which isn't enough since those functions are
sometimes called outside that, too), mention all stages where it can resides
explicitly.
Change-Id: I9360face822ada7018a1cfdfced8da29b347cbb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10722
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That way they're available wherever the verstage code ends up, bootblock,
verstage or romstage.
Change-Id: I6e59a40761f95a98d96a9b72e3bbcc59caae9b1a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Not all devices have a lid switch, so we need to state this
somehow. Since the alternative would be to extend get_lid_switch()'s
semantics to become a tri-state (open, closed, N/A), do this
through Kconfig.
BRANCH=none
BUG=chromium:446945
TEST=none
Change-Id: Icc50f72535f256051a59925a178fb27b2e8f7e55
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d20a1d1a22d64546a5d8761b18ab29732ec0b848
Original-Change-Id: Ie8ac401fbaad5b5a9f1dec2b67847c81f4cc94aa
Original-Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273850
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Queue: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10692
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Instead of calling the init function to clear out vboot2 data structures in
multiple places, move the function and call close to verstage_main().
Change-Id: If42e18a8e4581f22f7a7aced70ccbe3188bb0cd5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10701
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Otherwise it'll determine some offsets from uninitialized data and hilarity
ensues.
Change-Id: I6a671987857cfd3f3cd6078aebd13dd09fc79020
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10660
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add new GUID for FSP.
BRANCH=none
BUG=None
TEST=Build and run on strago
Change-Id: I539a59b513f67535436f581e0a79ab53f05682ca
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10587
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
VPD strings are not null terminated, so we can't use strcpy
on them in cros_vpd_gets.
BUG=none
BRANCH=none
TEST=add serial_number followed by cam_calib_data to VPD on smaug;
make sure that smaug boots and serial number matches exactly (no garbage)
Change-Id: Id72885517b3d0b1934ba329c1ef0d89a67bd2bb4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 56bbe6688b11043360a046a250d1ea93db4d9f0e
Original-Change-Id: I811dfc2f0830a91410eb69961a6565080ff78267
Original-Signed-off-by: Stephen Barber <smbarber@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/280836
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-on: http://review.coreboot.org/10627
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of having three copies of amdlib, the glue code for Agesa,
let's share the code between all implementations (and come up with
a versioned API if needed at some point in the future)
Change-Id: I38edffd1bbb04785765d20ca30908a1101c0dda0
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/10507
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc makefiles,
some Kconfig, and the AGESA standard library functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
Change-Id: Iad26689292eb123d735023dd29ef3d47396076ea
Signed-off-by: WANG Siyuan <wangsiyuanbuaa@gmail.com>
Signed-off-by: WANG Siyuan <SiYuan.Wang@amd.com>
Reviewed-on: http://review.coreboot.org/10416
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The SOUTHBRIDGE_INTEL_FSP_I89XX symbols are never defined in any Kconfig
file or used anywhere in the existing coreboot tree. Removing them as
unnecessary. If the southbridge code ever gets uploaded, these can be
re-added at that point.
Change-Id: I36f9ca8e25e08ce154d10ea9d764a73095590244
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/10436
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As there can be more than one source of firmware assets this
patch generalizes the notion of locating a particular asset.
struct asset is added along with some helper functions for
working on assets as a first class citizen.
Change-Id: I2ce575d1e5259aed4c34c3dcfd438abe9db1d7b9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10264
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
A new CBFS API is introduced to allow making CBFS access
easier for providing multiple CBFS sources. That is achieved
by decoupling the cbfs source from a CBFS file. A CBFS
source is described by a descriptor. It contains the necessary
properties for walking a CBFS to locate a file. The CBFS
file is then decoupled from the CBFS descriptor in that it's
no longer needed to access the contents of the file.
All of this is accomplished using the regions infrastructure
by repsenting CBFS sources and files as region_devices. Because
region_devices can be chained together forming subregions this
allows one to decouple a CBFS source from a file. This also allows
one to provide CBFS files that came from other sources for
payload and/or stage loading.
The program loading takes advantage of those very properties
by allowing multiple sources for locating a program. Because of
this we can reduce the overhead of loading programs because
it's all done in the common code paths. Only locating the
program is per source.
Change-Id: I339b84fce95f03d1dbb63a0f54a26be5eb07f7c8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9134
Tested-by: build bot (Jenkins)
Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With addition of bl31 and trusty, we need to increase the number of
parsed fw components in vboot to 6.
CQ-DEPEND=CL:273866
BUG=chrome-os-partner:40713
BRANCH=None
TEST=Compiles successfully and vboot finds trusty and bl31.
Change-Id: I3597e98370bbaef4d2e563c868eed59b2e18adca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0ff87fdbc7779e6ee410905d1618281411b38a93
Original-Change-Id: Ia403f895b50cc5349bb700d01f62e13c679f68f4
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/273865
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Trybot-Ready: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/10391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Only define the ASSERT macro when it is not already defined. This
change allows the UEFI/FSP definitions to be included with most other
coreboot includes.
BRANCH=none
BUG=None
TEST=Build and run on sklrvp
Change-Id: Iccfeb83eb1e52623ae0a0fe2a96b587ce61f82d7
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/10334
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Timestamps should not be forced on by a subset of chipsets.
However, they are a requirement on Chrome OS platforms, so
have CONFIG_CHROMEOS select it.
Change-Id: I408c6b17aa8721a3abec69020084174e414a8940
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: http://review.coreboot.org/10357
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This code is not specific to ChromeOS and is useful outside of it.
Like with small modifications it can be used to disable TPM altogether.
Change-Id: I8c6baf0a1f7c67141f30101a132ea039b0d09819
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/10269
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Now that vboot is using offsets for everything remove the
pass through vboot_get_region() and use region_devices
as first class citizens.
Change-Id: I1a86f3725e5bce38e6ca31e9641b1a8f4ac50e96
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10225
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of being pointer based use the region infrastrucutre.
Additionally, this removes the need for arch-specific compilation
paths. The users of the new API can use the region APIs to memory
map or read the region provided by the new fmap API.
Change-Id: Ie36e9ff9cb554234ec394b921f029eeed6845aee
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9170
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Because of the fmap API returning pointers to represent
regions within the boot device a vboot_region structure
was used to track the case where offsets could be pointers
on x86 but not on !x86. Normalize this tracking to use
offsets only as it provides consistency in the code.
Change-Id: I63c08b31ace3bd0e66ebc17e308f87eb5f857c86
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10221
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The vboot_context.h file hasn't been used since commit
6d65f796db. Remove it.
Change-Id: I57a6c619c6e1f57be6963da2954329bc9c007dd8
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10223
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
When we are taking the recovery path there is no slot or
components to fill out.
Change-Id: Ic97a247629365ef54a340c4398cb7491935edc11
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10198
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
The AGESA.c file in 3rdparty has cbfs access functions
for locating the AGESA binaries. coreboot access functions
need to be within coreboot where they can be updated with
cbfs changes. Move the offending function to coreboot.
Change-Id: Ibf6136d04dfbdb0198e90cc3ce719dc286c5610e
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/10058
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There was no indication of verstage being loaded. Provide this
output so that one can follow the flow from console messages.
Change-Id: I67ae6bb334608fe10a4a12fe690498afaf6b8366
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10195
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The support for RELOCATABLE_RAMSTAGE was accidentally omitted in
the vboot loader. Add said support.
Change-Id: I569918823253c33f698acefd6a619133543c7aef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10184
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
The vboot library currently relies on link-time known
address and sizes of the work buffer. Not all platforms
can provide such semantics. Therefore, add an option
to use cbmem for the work buffer. This implies such platforms
can only do verification of the firmware after main memory
has been initialized.
Change-Id: If0b0f6b2a187b5c1fb56af08b6cb384a935be096
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10157
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Instead of using the symbols directly provide a size
function to provide symmetry between getting the work
data and size. It also allows for an abstraction where
the linker symbols may not be the only source of this
information.
Change-Id: I4568064a0050d118c3544ab1ea59a08eb0bad8e4
Signed-off-by: Aaron Durbi <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10156
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
vboot_verify_firmware() was only defined to ease upstreaming.
It was only an empty inline as it is so remove it. Additionally,
vboot2 does not require romstage_handoff so there's no need in
adding it for the nyan boards.
Change-Id: I4d84ac9fb60c756cf10742f26503f7f11af5f57b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10155
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
As previously done the vboot loader can be optionally
inserted in the stage loading logic in order to
decide the source of each stage. This current patch
allows for verstage to be loaded and interrogated
for the source of all subsequent stages. Additionally,
it's also possible to build this logic directly into
one of the additional stages.
Note that this patch does not allow x86 to work.
Change-Id: Iece018f01b220720c2803dc73c60b2c080d637d0
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10154
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This make it pass through -fno-stack-protector, and also uses
libverstage fields consistently.
verstage is for 'stage' stuff, libverstage for all the vboot logic.
Change-Id: I3032e072414bed52effd2dc5057896781ad562c6
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/10174
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
In order to allow easier setting of variables without
changing mainboards and/or chipset Kconfig files allow
the vboot options to be selected by the user.
Change-Id: I6e995eb209b4cd63c73ef679d0c5699759d129f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10153
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The VB_FIRMWARE_ARCH variable was not being set correctly,
and the VBOOT_STARTS_IN_BOOTBLOCK Kconfig option was not properly
prefixed with CONFIG_. Correct both of these oversights.
Change-Id: Id27974c285d2629bd47b90b6a93aca1ec8a76512
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10152
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Somewhere along the development path the following
vboot functions were dropped:
int vboot_enable_developer(void)
int vboot_enable_recovery(void)
Add them back, but also refactor the flag extraction
so as not duplicate all that same logic.
Change-Id: Id58f3b99f29caeff98b2d3111cfa28241d15b54f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10151
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I9cbdf06f4d0956b5374915f8af7501c6f75b4687
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10113
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This allows providing a verified boot mechanism in the
default distribution, as well as reusing vboot code like
its crypto primitives for reasonably secure checksums over
CBFS files.
Change-Id: I729b249776b2bf7aa4b2f69bb18ec655b9b08d90
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10107
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
There's now room for other repositories under 3rdparty.
Change-Id: I51b02d8bf46b5b9f3f8a59341090346dca7fa355
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
To move 3rdparty to 3rdparty/blobs (ie. below itself
from git's broken perspective), we need to work around
it - since some git implementations don't like the direct
approach.
Change-Id: I1fc84bbb37e7c8c91ab14703d609a739b5ca073c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
verstage still needs to be built with its flags.
Change-Id: I125e4be283d3838fc7ce6587bf9996731540d517
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10098
Tested-by: build bot (Jenkins)
The name is more consistent with what we have elsewhere,
and the callsite didn't build at all (with vboot enabled)
Change-Id: I3576f3b8f737d360f68b67b6ce1683199948776d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10096
Tested-by: build bot (Jenkins)
It's not used at all.
Change-Id: I97bf02a9277f6ca348443c6886f77b4dfc70da78
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10095
Tested-by: build bot (Jenkins)
As the first step in adding support for FSP 1.1, add common header files
for EDK2. Internally FSP is based upon EDK2 and uses the defines and
data structures within these files for its interface.
These files come from revision 16227 of the open source EDK2 tree at
https://svn.code.sf.net/p/edk2/code/trunk/edk2. These files are
provided in an EDK2 style tree to allow direct comparison with the EDK2
tree.
Updates may be done manually to these files but only to support FSP 1.1
on UEFI 2.4. A uefi_2.5 tree should be added in the future as FSP
binaries migrate to UEFI 2.5.
Note: All the files were modified to use Linux line termination.
BRANCH=none
BUG=None
TEST=Build for Braswell or Skylake boards using FSP 1.1.
Change-Id: Ide5684b7eb6392e12f9f2f24215f5370c2d47c70
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9943
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Builds with CHROMEOS fail due to missing includes.
Change-Id: I8c88bca8f8cc3247d3f3311777f794c4fdfee3c1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10029
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ChromeOS machines employing vboot verfication require
different combinations of support:
1. When vboot verification starts.
2. Is the vboot code a separate stage or program?
3. If a separate stage, does the that vboot program (verstage) return
to the stage that loaded the verstage?
For the above, #1 is dependent on when to load/run vboot logic which
is orthogonal to #2. However, #3 is dependent on #2. The logic
to act on the combinations follows in subsequent patches.
Change-Id: I39ef7a7c2858e7de43aa99c38121e85a57f1f2f6
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10024
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
With vboot1 out of the way place all the associated Kconfig
options in vboot2's Kconfig file (excluding main vboot verify
option). More options will be added to accomodate vboot's various
combinations of use cases.
Change-Id: I17b06d741a36a5e2fefb2757651a61bfed61ae1e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/10023
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The second step in adding support for FSP 1.1 is to add the header
files.
Updates may be done manually to these files but only to support FSP 1.1.
An FSPx_y tree should be added in the future as FSP binaries migrate
to new FSP specifications.
The files are provided in an EDK2 style tree to allow direct comparison
with the EDK2 tree.
BRANCH=none
BUG=None
TEST=Build for Braswell or Skylake boards using FSP 1.1.
Change-Id: If0e2fbe3cf9d39b18009552af5c861eff24043a0
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: http://review.coreboot.org/9974
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- Remove Kconfig files that are no longer used:
src/vencorcode/Kconfig
src/soc/marvell/Kconfig
- Fix the drivers/sil/Kconfig to point to drivers/sil/3114 which had
the same code.
- Make sure all Kconfig files have linefeeds at the end. This can cause
problems, although it wasn't in this case.
- Include cpu/intel/model_65x/Kconfig which was not being included.
Change-Id: Ia57a1e0433e302fa9be557525dc966cae57059c9
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/9998
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This file was moved previously to get it out of the way
for easier merging from the chromium repo. It's not used
currently so remove it.
Change-Id: I8e691623f29ac2218b83bc46f5b4a348e0e1b3ef
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9960
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
There's no need to have the VBOOT2_VERIFY_FIRMWARE
distinction because it's the only game in town.
Change-Id: I82aab665934c27829e1a04115bf499ae527a91aa
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9958
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
In preparation for moving to vboot2 for all verified
boot paths bring over Kconfig options to the common
area from vboot1. Also remove vboot1 directory entirely.
Change-Id: Iccc4b570216f834886618f0ba5f2e1dd6c01db4b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9957
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This slightly streamlines integrating the vboot2 library and
prepares for merging verstage and bootblock on selected devices.
Change-Id: I2163d1411d0c0c6bf80bce64796e1b6a5a02b802
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10004
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The new function can be compiled in only when serial console is
disabled.
When invoked, this function initializes the serial interface and dumps
the contents of the CBMEM console buffer to serial output.
BRANCH=none
BUG=chromium:475347
TEST=compiled for different platforms with and without serial console
enabled. No actual test of this function yet.
Change-Id: Ia8d16649dc9d09798fa6970f2cfd893438e00dc5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a38a8254dd788ad188ba2509b9ae117d6f699579
Original-Change-Id: Ib85759a2727e31ba1ca21da7e6c346e434f83b52
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265293
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9984
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
In the spirit of include what you use actually #include
the header necessary for fmap calls.
Change-Id: I7acede51d7139234c0520281799dad3a8d33454f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9968
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Prepare for FSP 1.1 integration by moving the FSP to a FSP 1.0 specific
directory. See follow-on patches for sharing of common code.
Change-Id: Ic58cb4074c65b91d119909132a012876d7ee7b74
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/9970
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
elog breaks the build if ELOG_FLASH_BASE isn't configured -
and CHROMEOS isn't enabled, since with Chrome OS builds, it
just uses fmap to find out the base.
So it makes sense to enable it on all Chrome OS builds - if
the code never uses it, the linker will drop it soon enough.
Change-Id: I7ee129fadf75caf15fb9bd32b0acf6f7d9d015d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9965
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This fixes some compilation issues observed with CONFIG_CHROMEOS.
Nothing within the vbootX subdirectories is functional yet, but
a partial compilation within the chromeos direction works now.
Notable fixes: duplicate definitions and missing prototypes.
Change-Id: I53c7b6dcf06b8bcf41a8555094b48968c0740026
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9936
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
They were keyed to VBOOT_VERIFY_FIRMWARE which made them invisible
under some circumstances.
Change-Id: I61c56b4d245351fae0ec14f80bcd17ba93184651
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9956
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
They were already moved to src/lib/bootmode.c in
commit 5687fc9 Declare recovery and developer modes outside ChromeOS
Change-Id: Ia27a0c79baa364ce3779a8a699e9246d26d02ecb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9951
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The preprocessor flags that are manipulated in that line are
managed exclusively in CPPFLAGS since commit 58f73a69.
Change-Id: I2263401a292b4f7435659b24cf4f695a927015ef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9948
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is necessary to trigger console buffer contents dump on reset.
Let's make sure all vboot resets are routed through the same function.
BRANCH=none
BUG=chromium:475347
TEST=built and booted storm
Change-Id: I0d8580fb65417ba4b06dfae763dd6455afc8fc26
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 9788e2043cb1bd5df7e30574f7df4de4f25caa0d
Original-Change-Id: Iafca416700c51a0546249438ca583a415a1ca944
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265292
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9931
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch allows a board without a secdata storage (typically TPM) to pass
the verification stage if recovery path is taken. It's useful for bringup
when the actual board is not ready.
BUG=none
BRANCH=none
TEST=booted the kernel from a usb stick on a cygnus reference board
Change-Id: I5ab97d1198057d102a1708338d71c606fe106c75
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5d45acee31fd5b7bfe7444f12e3622bae49fc329
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chrome-internal-review.googlesource.com/212418
Original-Reviewed-by: Daisuke Nojiri <dnojiri@google.com>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@google.com>
Original-Tested-by: Daisuke Nojiri <dnojiri@google.com>
Original-Change-Id: Iddd9af19a2b6428704254af0c17b642e7a976fb8
Original-Reviewed-on: https://chromium-review.googlesource.com/265046
Reviewed-on: http://review.coreboot.org/9919
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
coreboot is expected to read all MAC addresses from the VPD and put
them in the coreboot table entry, depthcharge is expected to associate
different MAC addresses with different kernel device tree nodes.
This patch adds processing of wifi_macX keys. The order of MAC
addresses in the coreboot table is such that the wifi_macX entries
follow ethrnet_macX entries, ordered by X.
BRANCH=none
BUG=chrome-os-partner:36584
TEST=with the rest patches applied verified the contents of the kernel
device tree on an urara board.
Change-Id: I6523e168d2fea201a4956bc2a2d605b07ddac452
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36c12ee1d3ce9d2797902f0e098651067c2283ed
Original-Change-Id: Ib87e4815243f34ab258325839cbc12d16120bf89
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262843
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9896
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The preferred way of communicating WiFi calibration data to the kernel
is binary blob. But this data is stored in the VPD, and must be in
ASCII, so it is encoded using base64.
With the recent addition of the bas64 decoder it is possible to
convert the VPD representation to the form preferred by the kernel.
BRANCH=none
BUG=chromium:450169
TEST=with the rest of the patches applied verified that on both storm
and urara the device tree contains the required binary data.
Change-Id: I89da94bb425767eedc5e2d576e507663afad65ed
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c2ae38ded24394e0640b5d077e2231cf956397c5
Original-Change-Id: If8a7d0883ea8bb21a13bf203b25ee9f8a08903a9
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262842
Reviewed-on: http://review.coreboot.org/9895
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
On embedded devices with limited input capabilities it is necessary to
clear the developer mode condition when entering recovery. The new
configuration option will enable such behavior using the new vboot2
flag.
CQ-DEPEND=CL:261630
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applies observed desired behavior on
SP5
Change-Id: I99c3d1330bea9980a2af3b9fd99e29ab96f2cf07
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4c0a6315d6b4ede8d43e736ee6c82f1023f4716d
Original-Change-Id: I8e4a521e574b53a670daf692f7b45dc21635f272
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261620
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9878
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It is better to explicitly disable the call to read the physical
switch setting than to leave it up to implementation. In fact no
implementation would be even required.
BRANCH=none
BUG=none
TEST=verified that storm works as expected
Change-Id: I4b39827dba34ec0124960d0634e45d4554252d9b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c9fd014f1bfec6570b20ed8fed16d14d7e4e11b9
Original-Change-Id: I5d6d223f0c684e105a5e3d0b407e0fb181c7a7df
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261588
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9876
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It has become necessary to be able to "factory reset" certain devices
on firmware request.
The vboot package has been modified to provide the necessary API, this
patch introduces a configuration option and uses the API when
enabled.
CQ-DEPEND=CL:259857
BRANCH=storm
BUG=chrome-os-partner:37219
TEST=with all the patches applied, on storm, holding the recovery
button at startup for 10 seconds, causes 'crossystem
wipeout_request' to report '1'.
Change-Id: I5e57bc05af3753f451626021ba30c7726badb7b4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f70e03e9a8c55bf3c45b075ae4fecfd25da4f446
Original-Change-Id: I4c2192da4fabfdef34d527e5b80d137634eb6987
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/259843
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9862
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch is a raw application of the following spatch to src/:
@@
expression A, V;
@@
- writel(V, A)
+ write32(A, V)
@@
expression A, V;
@@
- writew(V, A)
+ write16(A, V)
@@
expression A, V;
@@
- writeb(V, A)
+ write8(A, V)
@@
expression A;
@@
- readl(A)
+ read32(A)
@@
expression A;
@@
- readb(A)
+ read8(A)
BRANCH=none
BUG=chromium:444723
TEST=None (depends on next patch)
Change-Id: I5dd96490c85ee2bcbc669f08bc6fff0ecc0f9e27
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 64f643da95d85954c4d4ea91c34a5c69b9b08eb6
Original-Change-Id: I366a2eb5b3a0df2279ebcce572fe814894791c42
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254864
Reviewed-on: http://review.coreboot.org/9836
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
ChromeOS/vboot devices expect the TPM PCRs 0 and 1 to be extended with
digests that attest the chosen boot mode (developer/recovery) and the
HWID in a secure way. This patch uses the newly added vboot2 support
functions to fetch these digests and store them in the TPM.
CQ-DEPEND=CL:244542
BRANCH=veyron
BUG=chromium:451609
TEST=Booted Jerry. Confirmed that PCR0 contains the same value as on my
vboot1 Blaze and Falco (and PCR1 contains some non-zero hash).
Original-Change-Id: I7037b8198c09fccee5440c4c85f0821166784cec
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/245119
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit 8b44e13098cb7493091f2ce6c4ab423f2cbf0177)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I549de8c07353683633fbf73e4ee62ba0ed72ff89
Reviewed-on: http://review.coreboot.org/9706
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
When CONFIG_MULTIPLE_CBFS_INSTANCES is enabled, the image is expected
to have CBFS instances in rw-a and rw-b sections of the bootrom.
This patch adds code which makes sure that CBFS header points at the
proper bootrpom section as determined by vboot, and the RW stages load
from that section.
BRANCH=storm
BUG=chrome-os-partner:34161, chromium:445938
TEST=with the rest of the patches in, STORM boots all the way into
Linux login prompt.
Original-Change-Id: I187e3d3e65d548c672fdf3b42419544d3bd11ea1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/237662
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 71ad0bb41b183374a84a5b9fb92c3afd813ceace)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia05cb713981c44da8cb379b72dfbe17fe1f6c5ff
Reviewed-on: http://review.coreboot.org/9704
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch aligns our verstage code to the new API addition in vboot2.
The hardware crypto functions are stubbed out by default and just
pretend that all algorithms are unsupported, causing vboot to fall back
to the normal software hashing code. These weak symbols can be
overridden by individual platform code to provide actual hardware
crypto engine support.
CQ-DEPEND=CL:236453
BRANCH=None
BUG=chrome-os-partner:32987
TEST=Booted Pinky, confirmed vboot falls back to software crypto.
Original-Change-Id: Idf6a38febd163aa2bff6e9a0e207213f01ca8324
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236435
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 9b5ee7f575f1aa3b0eb6ef78947ca93a4818f57b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I6f0e19255a9bc5c5cd1767db76f1e47897ef0798
Reviewed-on: http://review.coreboot.org/9703
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this allows each board to decide what to do after firmware verification is
done. some board needs to return back to the previous stage and let the
previous stage kick off the verified stage.
this also makes it more visible what is going to happen in the verstage since
stage_exit now resides in main().
BUG=none
BRANCH=tot
TEST=booted cosmos dev board. booted blaze in normal and recovery mode.
built for all current boards.
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I3cb466cedf2a9c2b0d48fc4b0f73f76d0714c0c7
Original-Reviewed-on: https://chromium-review.googlesource.com/232517
(cherry picked from commit 495704f36aa54ba12231d396376f01289d083f58)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ic20dfd3fa93849befc2b37012a5e0907fe83e8e2
Reviewed-on: http://review.coreboot.org/9702
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Many ChromeOS devices use a GPIO to reset the system, in order to
guarantee that the TPM cannot be reset without also resetting the CPU.
Often chipset/SoC hardware watchdogs trigger some kind of built-in
CPU reset, bypassing this GPIO and thus leaving the TPM locked. These
ChromeOS devices need to detect that condition in their bootblock and
trigger a second (proper) reboot.
This patch adds some code to generalize this previously
mainboard-specific functionality and uses it on Veyron boards. It also
provides some code to add the proper eventlog entry for a watchdog
reset. Since the second reboot has to happen before firmware
verification and the eventlog is usually only initialized afterwards, we
provide the functionality to place a tombstone in a memlayout-defined
location (which could be SRAM or some MMIO register that is preserved
across reboots).
[pg: Integrates
'mips: Temporarily work around build error caused by <arch/io.h> mismatch]
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Run 'mem w 0xff800000 0x9' on a Jerry, watch how a "Hardware
watchdog reset" event appears in the eventlog after the reboot.
Change-Id: I0a33820b236c9328b2f9b20905b69cb934326f2a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fffc484bb89f5129d62739dcb44d08d7f5b30b33
Original-Change-Id: I7ee1d02676e9159794d29e033d71c09fdf4620fd
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242404
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id: c919c72ddc9d2e1e18858c0bf49c0ce79f2bc506
Original-Change-Id: I509c842d3393bd810e89ebdf0dc745275c120c1d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242504
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9749
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Turns out there are uses for memlayout regions not specific to vboot2.
Rather than add yet another set of headers for a single region, let's
make the vboot2 one common for chromeos.
BRANCH=veyron
BUG=chrome-os-partner:35705
TEST=Booted Jerry, compiled Blaze, Cosmos, Ryu and Storm.
Change-Id: I228e0ffce1ccc792e7f5f5be6facaaca2650d818
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c6d7aab9f4e6d0cfa12aa0478288e54ec3096d9b
Original-Change-Id: I1dd7d9c4b6ab24de695d42a38913b6d9b952d49b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242630
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9748
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
I always had that TODO comment in there but I had already forgotten what
I even meant by it. It's really just a simple cleanup... this function
is (currently) veyron-specific and doesn't belong in common code.
BRANCH=veyron
BUG=None
TEST=Booted Jerry.
Change-Id: Iccd6130c90e67b8ee905e188857c99deda966f14
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d188398704575ad2fedc2a715e609521da2332b0
Original-Change-Id: I6ce701a15a6542a615d3d81f70aa71662567d4fa
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/241190
Reviewed-on: http://review.coreboot.org/9733
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Now that we have timestamps in pre-RAM stages, let's actually make use
of them. This patch adds several timestamps to both the bootblock and
especially the verstage to allow more fine-grained boot time tracking.
Some of the introduced timestamps can appear more than once per boot.
This doesn't seem to be a problem for both coreboot and the cbmem
utility, and the context makes it clear which operation was timestamped
at what point.
Also simplifies cbmem's timestamp printing routine a bit, fixing a
display bug when a timestamp had a section of exactly ",000," in it
(e.g. 1,000,185).
BRANCH=None
BUG=None
TEST=Booted Pinky, Blaze and Falco, confirmed that all timestamps show
up and contained sane values. Booted Storm (no timestamps here since it
doesn't support pre-RAM timestamps yet).
Change-Id: I7f4d6aba3ebe3db0d003c7bcb2954431b74961b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a2ce81722aba85beefcc6c81f9908422b8da8fa
Original-Change-Id: I5979bfa9445a9e0aba98ffdf8006c21096743456
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/234063
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9608
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Since we can now reduce our vboot2 work buffer by 4K, we can use all
that hard-earned space for the CBMEM console instead (and 4K are
unfortunately barely enough for all the stuff we dump with vboot2).
Also add console_init() and exception_init() to the verstage for
CONFIG_RETURN_FROM_VERSTAGE, which was overlooked before (our model
requires those functions to be called again at the beginning of every
stage... even though some consoles like UARTs might not need it, others
like the CBMEM console do). In the !RETURN_FROM_VERSTAGE case, this is
expected to be done by the platform-specific verstage entry wrapper, and
already in place for the only implementation we have for now (tegra124).
(Technically, there is still a bug in the case where EARLY_CONSOLE is
set but BOOTBLOCK_CONSOLE isn't, since both verstage and romstage would
run init_console_ptr() as if they were there first, so the romstage
overwrites the verstage's output. I don't think it's worth fixing that
now, since EARLY_CONSOLE && !BOOTBLOCK_CONSOLE is a pretty pointless
use-case and I think we should probably just get rid of the
CONFIG_BOOTBLOCK_CONSOLE option eventually.)
BRANCH=None
BUG=None
TEST=Booted Pinky.
Change-Id: I87914df3c72f0262eb89f337454009377a985497
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 85486928abf364c5d5d1cf69f7668005ddac023c
Original-Change-Id: Id666cb7a194d32cfe688861ab17c5e908bc7760d
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232614
Reviewed-on: http://review.coreboot.org/9607
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Some projects (like ChromeOS) put more content than described by CBFS
onto their image. For top-aligned images (read: x86), this has
traditionally been achieved with a CBFS_SIZE Kconfig (which denotes the
area actually managed by CBFS, as opposed to ROM_SIZE) that is used to
calculate the CBFS entry start offset. On bottom-aligned boards, many
define a fake (smaller) ROM_SIZE for only the CBFS part, which is not
consistently done and can be an issue because ROM_SIZE is expected to be
a power of two.
This patch changes all non-x86 boards to describe their actual
(physical) ROM size via one of the BOARD_ROMSIZE_KB_xxx options as a
mainboard Kconfig select (which is the correct place to declare
unchangeable physical properties of the board). It also changes the
cbfstool create invocation to use CBFS_SIZE as the -s parameter for
those architectures, which defaults to ROM_SIZE but gets overridden for
special use cases like ChromeOS. This has the advantage that cbfstool
has a consistent idea of where the area it is responsible for ends,
which offers better bounds-checking and is needed for a subsequent fix.
Also change the FMAP offset to default to right behind the (now
consistently known) CBFS region for non-x86 boards, which has emerged as
a de-facto standard on those architectures and allows us to reduce the
amount of custom configuration. In the future, the nightmare that is
ChromeOS's image build system could be redesigned to enforce this
automatically, and also confirm that it doesn't overwrite any space used
by CBFS (which is now consistently defined as the file size of
coreboot.rom on non-x86).
CQ-DEPEND=CL:231576,CL:231475
BRANCH=None
BUG=chromium:422501
TEST=Built and booted on Veyron_Pinky.
Change-Id: I89aa5b30e25679e074d4cb5eee4c08178892ada6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e707c67c69599274b890d0686522880aa2e16d71
Original-Change-Id: I4fce5a56a8d72f4c4dd3a08c129025f1565351cc
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/229974
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9619
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
make *config was complaining about mainboards selecting a virtual
dev switch when CONFIG_CHROMEOS is not enabled.
While the long term cleanup should be to move the option out of
CONFIG_CHROMEOS and make it not be a user changeable option, this
approach is contained to vendorcode/ and gets rid of the warning.
Change-Id: Id090eb31d1307af7a0d1f9fbe641534dc24b24a9
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/9301
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
chromeos.h includes vboot_handoff.h, which includes vboot_api.h. since
vboot_api.h is not available to non-chromeos projects, build fails for
some boards (e.g. glados).
this change removes (unnecessary) inclusion of vboot_handoff.h in chromeos.h
and fixes other files which rely on indirect inclusion of vboot_handoff.h
by making it direct.
BUG=none
BRANCH=tot
TEST=built for cosmos, falco, lumpy, nyan_blaze, parrot, rambi, rush_ryu,
samus, storm, veyron_pinky
Change-Id: I465e3657c6a0944bc75a669e5e52e74d46b3ec6c
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 6ace70d721aceae9257288815ce8fd7c6c74b8f5
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I12612773372e358584d12fffaf5f968a46083fab
Original-Reviewed-on: https://chromium-review.googlesource.com/245864
Original-Tested-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Leroy P Leahy <leroy.p.leahy@intel.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9566
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
sd->fw_version represents the version of the *current* firmware, which
is not necessarily the same as the one stored in the TPM (and may be 0
in recovery mode). Use the newly added sd->fw_version_secdata instead
which contains a more correct value.
CQ-DEPEND=CL:244601
BRANCH=veyron
BUG=chrome-os-partner:35941
TEST=Booted Jerry in recovery mode, confirmed crossystem tpm_fwver was
corrent (and not 0).
Change-Id: I30f5998da5ac518d6fcb7a651eba4e1fabc14478
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: eb8142f69cea34e11f9081caafcaae7a15cc3801
Original-Change-Id: Id95bd8c6412f2e8b2ae643c3b5a3dee13d0d47be
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/244591
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9565
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There are multiple vboot APIs (1.0, 2.0, 2.1). We have to be
explicit about which library we want to link with.
When building firmware, the vboot_reference Makefile should be
invoked in one of three ways:
TARGET OUTPUT VERSION
fwlib vboot_fw.a 1.0
fwlib20 vboot_fw20.a 2.0
fwlib21 vboot_fw21.a 2.1
BUG=chromium:228932
BRANCH=ToT
CQ-DEPEND=CL:243980
TEST=manual
emerge-veyron_pinky vboot_reference coreboot
emerge-samus vboot_reference coreboot
emerge-daisy_spring vboot_reference chromeos-u-boot
Change-Id: I7dde513c49b8148bf46e8768ae438e1a85af4243
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 5e339cadad4815f061d4e5e20a9c9733f64cc90b
Original-Change-Id: I850646117211930d9215693c48f2c30d55a984d3
Original-Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/243981
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9564
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The first platform that used flash-backed VBNV data has a physical
recovery switch, get_recovery_mode_from_vbnv() was never implemented.
This patch adds get_recovery_mode_from_vbnv() similarly to how it's
implemented for other vbnv storage in other places.
BUG=chrome-os-partner:34436
BRANCH=none
TEST=needs testing
Change-Id: Ifd795c5c1ff0f23619fd2125b4795571af03ece1
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 09f1bf96089bf9d159e4220c1f4d99388d709545
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I9cf18c988eaa4b7e720d6c66a02b1c5c63b473e9
Original-Reviewed-on: https://chromium-review.googlesource.com/239978
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9563
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Even though coreboot always hardcodes the FMAP offset, the same is not
possible for all other tools that manipulate ROM images. Some need to
manually find the FMAP by searching for it's magic number (ASCII
"__FMAP__"). If we do something like 'memcmp(fmap_buffer, "__FMAP__",
...) in coreboot code, it has the unfortunate side effect that the
compiler will output that very same magic number as a constant in the
.rodata section to compare against. Other tools may mistake this for the
"real" FMAP location and get confused.
This patch reverses the constant defined in coreboot and changes the
only use of it correspondingly. It is not impossible but extremely
unlikely (at the current state of the art) that any compiler would be
clever enough to understand this pattern and optimize it back to a
straight memcmp() (GCC 4.9 definitely doesn't), so it should solve the
problem at least for another few years/decades.
BRANCH=veyron
BUG=chromium:447051
TEST=Made sure the new binaries actually contain "__PAMF__" in their
.rodata. Booted Pinky. Independently corrupted both the first and the
last byte of the FMAP signature with a hex editor and confirmed that
signature check fails in both cases.
Change-Id: I314b5e7e4d78352f409e73a3ed0e71d1b56fe774
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 1359d2d4502eb34a043dffab35cf4a5b033ed65a
Original-Change-Id: I725652ef2a77f7f99884b46498428c3d68cd0945
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240723
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9562
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The current vbnv flash code mistakenly uses the offset into the NVRAM
area as the absolute offset into the SPI NOR. This causes overwrites
RO section of the flash (when it is not protected) and causes failures
to retrieve the NVRAM contents by the user space apps.
This patch makes sure that the correct offset is used when accessing
NVRAM area in the SPI flash.
BRANCH=storm
BUG=chrome-os-partner:35316
TEST=run the update code on storm.
- no more RO section corruption observed
- running 'crossystem recovery_request=1' at Linux prompt causes the
next boot happen in recovery mode
Change-Id: Iba96cd2e0e5e01c990f8c1de8d2a2233cd9e9bc9
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 9fd15ff4b7aa77536723edbb94fa81f0ae767aed
Original-Change-Id: I86fe4b9a35f7c16b72abf49cfbfcd42cc87937e3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/240143
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: http://review.coreboot.org/9561
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Some common VBNV variable offsets were defined in multiple vbnv_*
source files. This moves them to a header so that we can avoid
duplicating them in the future.
BUG=none
BRANCH=none
TEST=compiled for nyan_blaze and rambi
Change-Id: Ic292e546b665b40678b4de598783c1f6bfa35426
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: fd776f303a3d057d4b70997e7bb6bc85767e2278
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: Ifcc13c90a910b86d4f9bb0027d913572c1d6d00b
Original-Reviewed-on: https://chromium-review.googlesource.com/239977
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: http://review.coreboot.org/9560
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This sets the new VB_INIT_FLAG_BEFORE_OPROM_LOAD flag for VbInit()
to indicate that we are running from early firmware before option
rom loading has occurred so it can do the right thing when it
checks whether or not to tell the system to reboot after setting
the VbNv flag.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=pass FAFT tests on samus
Change-Id: Id432dc154736baa799d9ddf5a6a25bccc66217ef
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 8a576b0bf4b912f85a4e82bfe2cf13c838a069cc
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Change-Id: I6968fcb6cda74e88f56bea6ea9bbf77cc795b8d6
Original-Reviewed-on: https://chromium-review.googlesource.com/230887
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9559
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
make: *** No rule to make target `build/lib/memset.rmodules.o', needed by `build/vendorcode/google/chromeos/vboot1/vbootstub.elf'. Stop.
Fix the error by refering to ./src/arch/arm64/Makefile.inc:
rmodules_arm64-y += ../../lib/memset.c
rmodules_arm64-y += ../../lib/memcpy.c
BRANCH=none
BUG=none
TEST=build pass on our own MT8173 board
Change-Id: Ic870136db1ec9405e3d30caf6085f056bc46a5c2
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: d317dbe8732abbf7e785466e7d1e07425aac326f
Original-Change-Id: I69a7db83154a23f7878e9c604c9b541fb6fa308d
Original-Reviewed-on: https://chromium-review.googlesource.com/237974
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Original-Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Original-Commit-Queue: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: http://review.coreboot.org/9591
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
this change makes vb2_working_data struct point to the vboot work buffer by
the offset instead of by the absolute address, which can be different
depending on the context (e.g. subprocessor v.s. main cpu).
BUG=none
BRANCH=tot
TEST=booted veyron pinky
Change-Id: I2191ca756c4f49441b3a357338f9c84564b58918
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 93f8b1da2b2c81aa3a33892987a71e9e1e7a8eff
Original-Change-Id: I4e4c12613304586b7395c5173cf08b8093f59521
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236583
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9588
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
fmap_find used to read 4096 bytes from the fmap offset blindly. instead, we read
the fmap header first to calcurate the size of the fmap. Then, we read flash
again exactly as much as the discovered fmap.
BUG=none
BRANCH=ToT
TEST=Booted Storm and Peppy. Built all current boards.
Change-Id: Iaa50c1bc3401c77b433af11406d4b9d2e4e722e8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 755ff66ab0a4d05e6d5410c11a6badb9fcb77a0d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Ie5058d181e6565acb70bf108464682dd0e6c1f64
Original-Reviewed-on: https://chromium-review.googlesource.com/231685
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9556
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Before the change to use vb2_api.h, coreboot needed to know where to
find the vboot2 header files. Now those are all included by
vb2_api.h, so coreboot doesn't need to know about
firmware/2lib/include (and in fact, the 2lib directory is about to go
away).
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
Original-Change-Id: I7f69ca9cf8d45c325219efceca0cb8d1340f7736
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233223
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit b4d4a2da1c8b5a5f8f8da51f009227d3a616b096)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I4006f38835ea0f927142a8133bc24caaf2b7a214
Reviewed-on: http://review.coreboot.org/9447
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This will allow vboot2 to continue refactoring without breaking
coreboot, since there's now only a single file which needs to stay in
sync.
BUG=chromium:423882
BRANCH=none
TEST=emerge-veyron_pinky coreboot
CQ-DEPEND=CL:233050
Original-Change-Id: I74cae5f0badfb2d795eb5420354b9e6d0b4710f7
Original-Signed-off-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/233051
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit df55e0365de8da85844f7e7b057ca5d2a9694a8b)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I999af95ccf8c326f2fd2de0f7da50515e02ad904
Reviewed-on: http://review.coreboot.org/9446
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
Apparently our initial submission of 16K was a little too generous for
the vboot2 work buffer, and I hear that we should also be well within
bounds for 12K. This patch reduces the minimum asserted by memlayout so
some of our low-mem boards can get a few more kilobytes back for
discretionary spending. Also changes the required minimum alignment to 8
since that's what the current vboot code aligns it to anyway, and add a
warning comment to make it clearer that this is a dangerous number
people should not be playing with lightly.
BRANCH=None
BUG=None
TEST=Built and booted on Pinky.
Original-Change-Id: Iae9c74050500a315c90f5d5517427d755ac1dfea
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/232613
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 64e972f10363451cd544fdf8642bd484463703bc)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I362b8c33cf79534bb76bd7acda44d467563fe133
Reviewed-on: http://review.coreboot.org/9445
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
PHYSICAL_REC_SWITCH is set n by default and y for panther and stumpy.
BUG=none
BRANCH=ToT
TEST=Built nyan_blaze using vboot1/2. Built falco, lumpy, nyan,
blaze, parrot, rambi, samus, storm, pinky with default configuration.
panther and stumpy are not tested because they currently don't build on ToT.
Original-Change-Id: Ic45f78708aaa7e485d2ab459fd1948524edb412f
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/227940
Original-Reviewed-on: https://chromium-review.googlesource.com/229602
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit edb2ba347b48887ffe450586af0351e384faad59)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I277f665cd4f3e1c21745cdc5c7a2cfe148661abe
Reviewed-on: http://review.coreboot.org/9444
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
The architectiure check in fmap.c is in fact used to delineate between
platforms where SPI flash is mapped to memory address space and where
it needs to be accessed through CBFS.
In fact cosmos board uses an ARM SOC which also maps SPI flash to
processor address space, this will have to be addressed when that
SOC's support is introduced, for now let's just presume that all but
X86 platforms require CBFS layer to access fmap.
BRANCH=none
BUG=chrome-os-partner:31438
TEST=none
Original-Change-Id: Id135dc63278555a7fc5039a568fb28864f7cb8d1
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226180
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit b3c04f84504380066c54a6dec93781a4f25a5fc6)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I3a0a70fe583b69b1c9cd8729817bd7062126e1a9
Reviewed-on: http://review.coreboot.org/9436
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Tested-by: build bot (Jenkins)
This patch adds functions looking in the VPD for WiFi calibration
data, and if found, copying the calibration blobs into CBMEM.
Two possible key names templates are used: wifi_base64_calibrationX
and wifi_calibrationX, where X is replaced by the WiFi interface
number. Up to four interfaces can be provisioned.
The calibration data will be retrieved from CBMEM by the bootloader
and placed into the device tree before starting the kernel.
The structure of the WiFi calibration data CBMEM entry is defined
locally: it is a concatenation of the blob names and their contents.
Each blob is padded as necessary to make sure that the size divisible
by four.
To make sure that the exactly required amount of memory is allocated
for the CBMEM entry, the function first scans the VPD, caching the
information about the available blobs and calculating their combined
size.
Then the required size CBMEM entry is allocates and the blobs are
copied into it.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=when this function is called, and the VPD includes calibration
data blobs, the WIFI entry shows up in the list of CBMEM entries
reported by coreboot.
Original-Change-Id: Ibe02dc36ff6254e3b9ad0a5bd2696ca29e1b2be3
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225271
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 9fe185ae5fdc1a896bf892b498bff27a3462caeb)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: Ia60f0c5c84decf9854426c4f0cb88f8ccee69046
Reviewed-on: http://review.coreboot.org/9435
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Adds option FORCE_AM1_SOCKET_SUPPORT to disable
package type mismatch check between cpu and northbridge.
Default agesa for kabini doesn't know about AM1 socket
so it returns FALSE, that stops memory config code.
With this hack current agesa version supports the AM1 socket.
Change-Id: I99e9cec5cd558087092cf195094df20489f6d3b5
Signed-off-by: Sergej Ivanov <getinaks@gmail.com>
Reviewed-on: http://review.coreboot.org/9291
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
The new API allows to find VPD objects in the VPD cache. There is no
need for the caller to allocate or free the per object memory.
The existing API (cros_vpd_gets) now uses the new function as well.
BRANCH=storm
BUG=chrome-os-partner:32611
TEST=verified that MAC addresses still show up in the device tree on
the booted storm device
Change-Id: Id06be315981cdaa2285fc1ec61b96b62b1178a4b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 99a34344448a5521cee8ad3918aefb1fde28417d
Original-Change-Id: I6c0b11bb844d6235930124d642da632319142d88
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/225258
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: http://review.coreboot.org/9403
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Retrieval of the MAC address from the VPD is a Chrome OS specific
feature, required just on one platform so far. There is no need to
look for the MAC address in the VPD on all other Chrome OS boards.
BRANCH=storm
BUG=chromium:417117
TEST=with the upcoming patch applied verified that MAC addresses still
show up in the device tree on storm
Change-Id: If5fd4895bffc758563df7d21f38995f0c8594330
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fb4906ac559634321a01b4814f338611b9e98b2b
Original-Change-Id: I8e6f8dc38294d3ab11965931be575360fd12b2fc
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223796
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/9398
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
If you try to boot a VBOOT2_VERIFY_FIRMWARE with less than 4K CBFS cache
right now, your system will try and fail to validate the FMAP signature
at (u8 *)0xFFFFFFFF and go into recovery mode. This patch avoids the
memcmp() to potentially invalid memory, and also adds an error message
to cbfs_simple_buffer_map() to make it explicit that we ran out of CBFS
cache space.
BUG=None
TEST=Booted on Veyron_Pinky with reduced CBFS cache, saw the message.
Original-Change-Id: Ic5773b4e0b36dc621513f58fc9bd29c17afbf1b7
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/222899
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 0ed3c0c2b63be0d32e8162faf892e41cef1f1f23)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I20ccac83bff4a377caca6327d0e21032efff44c1
Reviewed-on: http://review.coreboot.org/9373
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch creates a new mechanism to define the static memory layout
(primarily in SRAM) for a given board, superseding the brittle mass of
Kconfigs that we were using before. The core part is a memlayout.ld file
in the mainboard directory (although boards are expected to just include
the SoC default in most cases), which is the primary linker script for
all stages (though not rmodules for now). It uses preprocessor macros
from <memlayout.h> to form a different valid linker script for all
stages while looking like a declarative, boilerplate-free map of memory
addresses to the programmer. Linker asserts will automatically guarantee
that the defined regions cannot overlap. Stages are defined with a
maximum size that will be enforced by the linker. The file serves to
both define and document the memory layout, so that the documentation
cannot go missing or out of date.
The mechanism is implemented for all boards in the ARM, ARM64 and MIPS
architectures, and should be extended onto all systems using SRAM in the
future. The CAR/XIP environment on x86 has very different requirements
and the layout is generally not as static, so it will stay like it is
and be unaffected by this patch (save for aligning some symbol names for
consistency and sharing the new common ramstage linker script include).
BUG=None
TEST=Booted normally and in recovery mode, checked suspend/resume and
the CBMEM console on Falco, Blaze (both normal and vboot2), Pinky and
Pit. Compiled Ryu, Storm and Urara, manually compared the disassemblies
with ToT and looked for red flags.
Change-Id: Ifd2276417f2036cbe9c056f17e42f051bcd20e81
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f1e2028e7ebceeb2d71ff366150a37564595e614
Original-Change-Id: I005506add4e8fcdb74db6d5e6cb2d4cb1bd3cda5
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/213370
Reviewed-on: http://review.coreboot.org/9283
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Tauner <stefan.tauner@gmx.at>
Reviewed-by: Aaron Durbin <adurbin@google.com>
This patch adds the macros __ROMSTAGE__ and __RAMSTAGE__ which get
predefined in their respective stages by make, so that we have one
specific macro for every stage. It also renames __BOOT_BLOCK__ and
__VER_STAGE__ to __BOOTBLOCK__ and __VERSTAGE__ for consistency.
This change is intended to provide finer control and clearer
communication of intent after we added a new (optional) stage that falls
under __PRE_RAM__, and will hopefully provide some robustness for the
future (we don't want to end up always checking for romstage with #if
defined(__PRE_RAM__) && !defined(__BOOT_BLOCK__) &&
!defined(__VER_STAGE__) && !defined(__YET_ANOTHER_PRERAM_STAGE__)). The
__PRE_RAM__ macro stays as it is since many features do in fact need to
differentiate on whether RAM is available. (Some also depend on whether
RAM is available at the end of a stage, in which case #if
!defined(__PRE_RAM__) || defined(__ROMSTAGE__) should now be
authoritative.)
It's unfeasable to change all existing occurences of __PRE_RAM__ that
would be better described with __ROMSTAGE__, so this patch only
demonstratively changes a few obvious ones in core code.
BUG=None
TEST=None (tested together with dependent patch).
Change-Id: I6a06d0f42c27a2feeb778a4acd35dd14bb53f744
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a4ad042746c1d3a7a3bfda422d26e0d3b9f9ae42
Original-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219172
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9304
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Drop the inner underscore for consistency. Follows the
commit stated below.
Change-Id: I75cde6e2cd55d2c0fbb5a2d125c359d91e14cf6d
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-on-Change-Id: I6a1f25f7077328a8b5201a79b18fc4c2e22d0b06
Based-on-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-on-Reviewed-on: https://chromium-review.googlesource.com/219172
Reviewed-on: http://review.coreboot.org/9290
Reviewed-by: Aaron Durbin <adurbin@google.com>
Tested-by: build bot (Jenkins)
this adds a driver for vboot to read and write nvdata in spi flash.
it's assumed that flash contents are erased to 1-bits and write
operations can only change 1-bits to 0-bits.
when all nvram space is used, the driver will erase the whole block
and start the next write from the beginning.
BUG=chrome-os-partner:32774
BRANCH=ToT
TEST=Built for cosmos.
Change-Id: I40858f847151aa0770e1101e905476d270550f60
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 09713828b7b0cabd13a08de3f34e32bc4dbef4a4
Original-Change-Id: Ia9049f342b21fa4c289cb7b9254ab89ec1ef1699
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/226525
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9229
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Introduce generic-$(type)-ccopts and $(class)-generic-ccopts
to declare compiler flags that apply to all files of a certain
type or of a certain class. Then use them.
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I655688e82a0cc5bad89b6f55dc217b9f66b64604
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9114
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This is inspired by the commit listed below, but rewritten to match
upstream, and split in smaller pieces to keep intent clear.
Change-Id: I5405c0ee6bee203281e723feaecaee57fad8f6cb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Based-On-Change-Id: I50af7dacf616e0f8ff4c43f4acc679089ad7022b
Based-On-Signed-off-by: Julius Werner <jwerner@chromium.org>
Based-On-Reviewed-on: https://chromium-review.googlesource.com/219170
Reviewed-on: http://review.coreboot.org/9109
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@google.com>
Includes moved into $(CPPFLAGS_*), so add that to VBOOT_CFLAGS.
Shift vboot build parameters from the environment to be make parameters,
and use $(MAKE) instead of make to fix non-Linux build systems.
Change-Id: I5aee9935ab36ad571fbcf9f6fa8d8ace2bac16b3
Signed-off-by: Stefan Reinauer <reinauer@google.com>
Reviewed-on: http://review.coreboot.org/8703
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
In order to display a "update in progress" screen on devices with
a slow EC or PD chip it may be necessary to also load the VGA
Option ROM when doing EC software sync.
This adds config options for VBOOT_EC_SLOW_UPDATE which simply sets
a flag in the input parameters that is already handled by vboot.
It also adds a config option for VBOOT_OPROM_MATTERS which is a bit
more tricky in that it sets a flag in input parameters, but also
needs to keep track of the option rom being loaded and pass that
flag into VbInit as well.
Since VbInit will clear the NV bit for option rom loaded the check
that is done in vboot_wants_oprom() needs to first compare against
the vboot handoff copy of the input flags.
BUG=chrome-os-partner:32379
BRANCH=samus
TEST=manual testing:
1) in normal mode, with EC/PD in RW, ensure that they are rebooted
to RO and the VGA Option ROM is loaded and the wait screen is
displayed, and then the system is rebooted at the end and the
VGA Option ROM is not loaded.
2) same as #1 with EC/PD in RO already, same result
3) same as #1 with system in developer mode, same result except
there is no reboot at the end of software sync
4) same as #1 with system in developer mode and EC/PD in RO,
ensure that there is no extra reboot at the beginning or end of
software sync.
Original-Change-Id: Ic2b34bf9e7c6cc5498413fa1b8dff6e6207c9d0a
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/223831
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
(cherry picked from commit 7d7aa89238efb5081885f9386c8e872fc96f573f)
Change-Id: Ib7fb24e6e80e1f7e836bc62246ab9b3e056fd73d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8887
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
this change makes coreboot initialize kernel space and backup space in the tpm
when no firmware space is found in the tpm.
BUG=chrome-os-partner:32410
TEST=Forced factory initialization and verified it went through without errors.
BRANCH=None
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I777e3cb7004870c769163827543c83665d3732b9
Original-Reviewed-on: https://chromium-review.googlesource.com/220412
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d8c0c407bf0fed60d76441ada7bedd36f6fc3a38)
Change-Id: Icc3779125262b4499e47781991ebbf584abf074a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8885
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change makes prevent execution from falling through to unverified
code when hard_reset is not implemented. it also includes a few touch-ups.
BUG=None
TEST=Booted Veyron Pinky. Verified firmware selection in the log.
BRANCH=None
Original-Change-Id: I9b02ab766172a62c98b434c29f310bc4a44f342d
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/219625
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit d1f5207d83d2247b55f2bb9d02ac843305fc3ded)
Change-Id: I99dd5a2ca3a5369accb14408ea9d266bf60e7132
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8884
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
With CONFIG_RETURN_FROM_VERSTAGE false, the verstage loads the romstage over
the bootblock, then exits to the romstage. this is necessary for some SOC
(e.g. tegra124) which runs the bootblock on a different architecture.
With CONFIG_RETURN_FROM_VERSTAGE true, the verstage returns to the bootblock.
Then, the bootblock loads the romstage over the verstage and exits to the
romstage. this is probably necessary for some SOC (e.g. rockchip) which does not
have SRAM big enough to fit the verstage and the romstage at the same time.
BUG=none
TEST=Built Blaze with USE=+/-vboot2. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I673945c5e21afc800d523fbb25d49fdc83693544
Original-Reviewed-on: https://chromium-review.googlesource.com/212365
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Note: This purposefully is probably broken in vendorcode/google/chromeos
as I'm just trying to set a base for dropping more patches in. The vboot
paths will have to change from how they are currently constructed.
(cherry picked from commit 4fa17395113d86445660091413ecb005485f8014)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I9117434ce99695f9b7021a06196d864f180df5c9
Reviewed-on: http://review.coreboot.org/8881
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
this change reduces the code duplication of the bootblock and the romstages for
Nyans.
BUG=none
TEST=Built Nyan, Big, and Blaze. Ran faft on Blaze.
BRANCH=none
Original-Signed-off-by: dnojiri@chromium.org (Daisuke Nojiri)
Original-Change-Id: Ieb9dac3b061a2cf46c63afb2f31eb67ab391ea1a
Original-Reviewed-on: https://chromium-review.googlesource.com/214050
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit f3413d39458f03895fe4963a41285f71d81bcf5f)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I912f63b12321aa26a7add302fc8a6c4e607330ef
Reviewed-on: http://review.coreboot.org/8880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This introduces a new kconfig variable to select the VBNV backing
store explicitly instead of inferring it from CPU/SoC architecture.
x86 platforms have historically relied only on CMOS to store VBNV
variables, while ARM-based platforms have traditionally relied on
the EC. Neither of those solutions are going to scale well into
the future if/when CMOS disappears and we make ARM-based systems
without an EC.
BUG=chrome-os-partner:29546
BRANCH=none
TEST=compiled for nyan_blaze and samus
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I4a8dadfb6bb666baf1ed4bec98b29c145dc4a1e7
Original-Reviewed-on: https://chromium-review.googlesource.com/213877
Original-Reviewed-by: Stefan Reinauer <reinauer@google.com>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Original-Tested-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit d088fc71b2e2b45e826d3dedb8e536ad58b8d296)
Change-Id: Iea325a8c4d07055143e993d89b827f86b8312330
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8777
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
rmodules ccopts contain information about specific arch like armv4,v7. Hence, it
is important to include them in VBOOT_CFLAGS
BUG=None
BRANCH=None
TEST=Compiles correctly for armv4 in rush
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Id:
Original-Change-Id: I8f5509f753e28046678c3782d6f0b6210559f798
Original-Signed-off-by: Furquan Shaikh <furquan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/209979
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Original-Tested-by: Furquan Shaikh <furquan@chromium.org>
(cherry picked from commit ca9f2f86ff1bc445abf5f97f61c04b6eccbd3e25)
Change-Id: I6cd7c47f33cf897d8ee96e7154222b3bfbe5221f
Reviewed-on: http://review.coreboot.org/8775
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
In order to more cleanly apply upcoming changes some files
will need to do a dance.
Change-Id: Ib50670743c10221785447490190ecdbff8c764fe
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8654
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Instead of two headers for payload and ramstage loading
combine the 2 files into one. This also allows for easier
refactoring by keeping header files consistent.
Change-Id: I4a6dffb78ad84c78e6e96c886d361413f9b4a17d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/8708
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
x86 systems run their romstage as execute-in-place from flash, which
prevents them from having writable data segments. In several code pieces
that get linked into both romstage and ramstage, this has been worked
around by using a local variable and having the 'static' storage class
guarded by #ifndef __PRE_RAM__.
However, x86 is the only architecture using execute-in-place (for now),
so it does not make sense to impose the restriction globally. Rather
than fixing the #ifdef at every occurrence, this should really be
wrapped in a way that makes it easier to modify in a single place. The
chromeos/cros_vpd.c file already had a nice approach for a wrapper
macro, but unfortunately restricted it to one file... this patch moves
it to stddef.h and employs it consistently throughout coreboot.
BRANCH=nyan
BUG=None
TEST=Measured boot time on Nyan_Big before and after, confirmed that it
gained 6ms from caching the FMAP in vboot_loader.c.
Original-Change-Id: Ia53b94ab9c6a303b979db7ff20b79e14bc51f9f8
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/203033
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c8127e4ac9811517f6147cf019ba6a948cdaa4a5)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I44dacc10214351992b775aca52d6b776a74ee922
Reviewed-on: http://review.coreboot.org/8055
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
If devicetree.cb has GPP port off, really disable it before even
trying to do link training.
Change-Id: I810945da28d86768e88249dc4d29a50ad9f9959b
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8385
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Rangeley POST-GOLD 2 FSP added PCIe ports de-emphasis configuration
by UPD input. Update UPD_DATA_REGION structure for matching up this
FSP change.
PcdCustomerRevision is a debugging aid that will be output to debug
message in FSP. When needed, it can be customized by BCT tool for tracking
BCT configurations.
Change-Id: I6d4138c9d8bbb9c89f24c77f976dbc760d626a9b
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: http://review.coreboot.org/8107
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <gaumless@gmail.com>
To maintain consistancy with southbridge/amd/agesa/hudson rename
pi/avalon to pi/hudson in advance of adding support for the
base hudson southbridge.
Change-Id: Icff8c4c06aae2d40cbd9e90903754735ac3510c3
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/8251
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Add all of the PI source that will remain part of coreboot to
build with a binary AGESA PI BLOB. This includes the gcc makefiles,
some Kconfig, and the AGESA standard library functions.
Change vendorcode Makefile and Kconfig so that they can compile
AMD library files and use headers from outside the coreboot/src
tree.
This fix changes the makefile so that the AGESA dispatcher is
built using its own rules rather than generic library generation
rules in coreboot/Makefile and coreboot/Makefile.inc. The AGESA
source files are initially copied from whereever they live into
coreboot/build/agesa. They are compiled from there. The binary
PI directory now has a mandatory structure that places the AGESA
BLOB into the same directory as the support headers. These will
nominally be placed in the amd directory in SageBIOS or the
3rdparty directory in coreboot.org.
Change-Id: I56788cd197159939b64c7d16c1d32418f8cc2197
Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
Signed-off-by: Dave Frodin <dave.frodin@se-eng.com>
Reviewed-on: http://review.coreboot.org/5967
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
vboot2 abtracts tpm storage as some 'secure' space. Thus, it's firmware's
responsibility to handle vboot specific operations with tpm. This CL just copies
related files from vboot_reference so that we can see how code was modified in
the next CL. Note rollback_index.c/h were renamed to antirollback.c/h.
TEST=none
BUG=none
Branch=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I1792a622058f70a8fcd3c4037547539ad2870420
Original-Reviewed-on: https://chromium-review.googlesource.com/206462
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 2ae188b29242bf09c5e79e31f98b330a30bf7b93)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I5fa5a636003e8472127194e961fea4309489b1d9
Reviewed-on: http://review.coreboot.org/8164
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
Doing reset while VBERROR_TPM_REBOOT_REQUIRED occured.
BUG=chromium:389568
TEST=Manual force VBERROR_TPM_REBOOT_REQUIRED returned from VbInit()
and system will reboot.
Original-Change-Id: I9d7c4b3a380a931a728f792b4013b3b9bf65dfae
Original-Signed-off-by: Kevin Cheng <kevin.cheng@intel.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/206337
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 32728dd9fc43a95d6f763a85f9cc7a660a66b175)
Original-Reviewed-on: https://chromium-review.googlesource.com/206948
Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org>
(cherry picked from commit 1ea5e233386d236ce20f3d1695fac3a1bc49d4bd)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: Ib93fdf7b22918f563d3e29207a75fc831bee186a
Reviewed-on: http://review.coreboot.org/8163
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This patch has a basic structure of vboot2 integration. It supports only Nyans,
which have bootblock architecture and romstage architecture are
compatible from linker's perspective.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I4bbd4d0452604943b376bef20ea8a258820810aa
Original-Reviewed-on: https://chromium-review.googlesource.com/204522
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Commit-Queue: Daisuke Nojiri <dnojiri@chromium.org>
Original-Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
(cherry picked from commit a6bce0cbed34def60386f3d9aece59e739740c58)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I63ddfbf463c8a83120828ec8ab994f8146f90001
Reviewed-on: http://review.coreboot.org/8160
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
This reverts the revert commit 5780d6f387
and fixes the build issue that cuased it to be reverted.
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains,
compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the
boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with
verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I2a83b87c29d98d97ae316091cf3ed7b024e21daf
Reviewed-on: http://review.coreboot.org/8224
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This reverts commit 320647abda, because it
introduced the following regression.
$ LANG=C make V=1
Warning: no suitable GCC for arm.
Warning: no suitable GCC for aarch64.
Warning: no suitable GCC for riscv.
/bin/sh: --: invalid option
Usage: /bin/sh [GNU long option] [option] ...
/bin/sh [GNU long option] [option] script-file ...
GNU long options:
--debug
--debugger
--dump-po-strings
--dump-strings
--help
--init-file
--login
--noediting
--noprofile
--norc
--posix
--rcfile
--restricted
--verbose
--version
Shell options:
-ilrsD or -c command or -O shopt_option (invocation only)
-abefhkmnptuvxBCHP or -o option
make: -print-libgcc-file-name: Command not found
It also introduced trailing whitespace.
Change-Id: I50ec00a38e24c854fa926357cd24f9286bf4f66f
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-on: http://review.coreboot.org/8223
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Verstage will host vboot2 for firmware verification.
It's a stage in the sense that it has its own set of toolchains, compiler flags,
and includes. This allows us to easily add object files as needed. But
it's directly linked to bootblock. This allows us to avoid code
duplication for stage loading and jumping (e.g. cbfs driver) for the boards
where bootblock has to run in a different architecture (e.g. Tegra124).
To avoid name space conflict, verstage symbols are prefixed with verstage_.
TEST=Built with VBOOT2_VERIFY_FIRMWARE on/off. Booted Nyan Blaze.
BUG=None
BRANCH=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: Iad57741157ec70426c676e46c5855e6797ac1dac
Original-Reviewed-on: https://chromium-review.googlesource.com/204376
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
(cherry picked from commit 27940f891678dae975b68f2fc729ad7348192af3)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I42b2b3854a24ef6cda2316eb741ca379f41516e0
Reviewed-on: http://review.coreboot.org/8159
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Tested-by: build bot (Jenkins)
When included for the CAR transition, this was causing the error:
error: invalid storage class for function 'DebugDeadLoop'
Change-Id: Idf37a8104b4468b40c29c8cbe9a40f7a357a4f17
Signed-off-by: Martin Roth <gaumless@gmail.com>
Reviewed-on: http://review.coreboot.org/8193
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
This adds a generic helper function for adding boot reason in the
ChromeOS case. If vboot is enabled, it will use information passed
in via the vboot handoff table in cbmem to determine mode and
reason in the case of recovery.
BUG=chromium:373467
BRANCH=nyan
TEST=built along with follow-up CL and booted on Big under various
modes, verified entry was added to eventlog with "mosys eventlog list"
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Change-Id: I50a7aa6d55eb46413fe9929e732d6eb18c758d4b
Original-Reviewed-on: https://chromium-review.googlesource.com/199690
Original-Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 961c0bd1dd5512b1c2feb2ed4391bf507900eb7a)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I6ae4e2a891966d2d1de7d37dcc551383e94e4d75
Reviewed-on: http://review.coreboot.org/7991
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Add the empty weak function clear_recovery_mode_switch().
Problem:
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC is set,
the following will happen:
1. Boot device in recovery mode with Esc + F3 + Pwr.
2. Turn device off with Pwr button.
3. Turn device on with Pwr button.
Device still boots to recovery screen with
recovery_reason:0x02 recovery button pressed.
If GBB_FLAG_DISABLE_EC_SOFTWARE_SYNC isn't set, turning the
device off and on again with the Pwr button does a normal boot.
Solution:
Unconditionally clear the recovery flag.
BUG=chromium:279607
BRANCH=TOT
TEST=Compile OK.
Original-Change-Id: Ie1e3251a6db12e75e385220e9d3791078393b1bf
Original-Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/197780
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Commit-Queue: Sheng-liang Song <ssl@google.com>
Original-Tested-by: Sheng-liang Song <ssl@google.com>
(cherry picked from commit 18908bb64cef34ca41812814817ef887961bed34)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I71ca9f3ea8d816c865375ec66a0603ca211f23ae
Reviewed-on: http://review.coreboot.org/7895
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins)
