summaryrefslogtreecommitdiff
path: root/src/vendorcode
AgeCommit message (Collapse)Author
2016-05-03vendorcode/intel/fsp/fsp1_1/quark: Update FspUpdVpd.hLee Leahy
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>
2016-05-03chromeos: Ensure that the last file in FW_MAIN is not also the first onePaul Kocialkowski
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>
2016-04-28drivers/intel/i210: Use uint8_t and friends instead of u8Werner Zeh
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>
2016-04-28vendorcode/siemens: Add hwilib for Siemens specific info structWerner Zeh
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)
2016-04-21AGESA vendorcode: Fix type mismatchKyösti Mälkki
Fix is required to compile AGESA ramstage without raminit. Change-Id: I783883fa7a12e8a647aa432535bb990a47257e9b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/14416 Tested-by: build bot (Jenkins) Reviewed-by: Kerry Sheh <shekairui@gmail.com>
2016-04-20vboot: Compile loader in postcar as wellAndrey Petrov
Change-Id: Ide3202fca75c77ccebf17d61d93945ba7834a13b Signed-off-by: Andrey Petrov <andrey.petrov@intel.com> Reviewed-on: https://review.coreboot.org/14398 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2016-04-20AGESA vendorcode: Suppress maybe-uninitialized warningsKyösti Mälkki
Compiling libagesa with -O2 would throws error on these. Change-Id: I04afa42f0ac76677f859ca72f9df2e128762ad3c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: https://review.coreboot.org/14413 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-04-20AGESA vendorcode: Fix logic errorKyösti Mälkki
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>
2016-04-20AMD CIMX: Drop unused codeKyösti Mälkki
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>
2016-04-18vendorcode/intel: Remove temporary Broadwell DE Kconfig symbolMartin Roth
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>
2016-04-16vendorcode/amd/agesa: Fix tautological compareEdward O'Callaghan
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)
2016-04-05chromeos: Fix adding a bmpblk to GBBPatrick Georgi
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>
2016-04-05chromeos: Add enable-serial GBB flagPatrick Georgi
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>
2016-04-05google/oak: Log hardware watchdog in eventlogJulius Werner
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>
2016-03-31vendorcode/amd/agesa/*/AGESA.h: Correct "ne" to "be" in commentPaul Menzel
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>
2016-03-29vboot: Handle S3 resume path for TPM initializationDuncan Laurie
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>
2016-03-15vendorcode/intel/Kconfig: Add broadwell_de symbol to fix lintMartin Roth
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>
2016-03-14vendorcode/intel/fsp1_0: Add Broadwell-DE SoC vendor codeYork Yang
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>
2016-03-12vendorcode/intel/fsp/fsp1_1/skylake: update FspUpdVpd.h 1.9.0Aaron Durbin
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>
2016-03-08Chromeos: Modify wifi_regulatory_domain to use "region" key in VPDHuang, Huki
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>
2016-03-08soc/intel/quark: Set the UPD values for MemoryInitLee Leahy
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)
2016-02-29vboot: Set S3_RESUME flag for vboot context if necessaryDuncan Laurie
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>
2016-02-22cbfs: Add LZ4 in-place decompression support for pre-RAM stagesJulius Werner
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>
2016-02-10chromeos/Kconfig: Remove dependency on GBB_HAVE_BMPFVMartin Roth
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)
2016-02-10google/chromeos: backup -> back upPatrick Georgi
See discussion on https://review.coreboot.org/13600 and https://review.coreboot.org/13601 Change-Id: Ia8274b0b296d6b398f75c0d91a6fded4c5f57e10 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: https://review.coreboot.org/13643 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2016-02-10soc/fsp_baytrail: Add support for FSP MR 005Ben Gardner
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>
2016-02-09vboot2: Store depthcharge graphic assets only in ROPatrick Georgi
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>
2016-02-09chromeos: Add option to back up VBNV CMOS into flashDuncan Laurie
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>
2016-02-09google/chromeos/vboot2: defer clearing rec mode switchAaron Durbin
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>
2016-02-09chromeos: Make vbnv_flash driver safe for CAR usageDuncan Laurie
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>
2016-02-09chromeos: Remove CONFIG_VBNV_SIZE variableDuncan Laurie
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>
2016-02-09chromeos: Add vbnv wrapper for the different backendsDuncan Laurie
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>
2016-02-04google/chromeos/vboot2: honor boot region device sizeAaron Durbin
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>
2016-02-04google/chromeos: guard cbmem_find() in verstage and bootblockAaron Durbin
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>
2016-02-04chromeos/vboot: allow platform to hook into vboot_reboot()Aaron Durbin
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>
2016-02-04chromeos/vboot: provide support for x86 memory init verificationAaron Durbin
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>
2016-02-04soc/intel/quark: Add minimal Quark SoC X1000 filesLee Leahy
Add the files for minimal Quark X1000 SoC support: * Declare pei_data structure * Declare sleep states and chipset_power_state structure * Specify top of memory * Empty FspUpdVpd.h file TEST=None Change-Id: If741f84904394780e1f29bd6ddbd81514c3e21c9 Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com> Reviewed-on: https://review.coreboot.org/13439 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-02-03chromeos: Sign FW_MAIN_A and FW_MAIN_BPatrick Georgi
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)
2016-02-03chromeos: Add Kconfig options for GBB flagsPatrick Georgi
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>
2016-02-03chromeos: Create GBB at build timePatrick Georgi
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>
2016-02-03vendorcode/amd/agesa/f1{4,2,0} Sync Include directoryEdward O'Callaghan
Sync and merge useless differences. Change-Id: I4eea66c35af66d473dd56db9ccf105c878266f22 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: https://review.coreboot.org/7513 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2016-02-03vendorcode/amd/agesa/f15?tn: Strip false/redudant AMD ver tagEdward O'Callaghan
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>
2016-01-31vendorcode/intel: remove unused apple specific assembler macrosStefan Reinauer
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>
2016-01-29src/: Chmod 644 all .c, .h, .asl, .inc, .cb, .hex, & Kconfig filesMartin Roth
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>
2016-01-28src/: give scripts a .sh extension for easy identificationMartin Roth
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>
2016-01-28Makefile: Make full use of src-to-obj macroNico Huber
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>
2016-01-27soc/braswell: Update FspUpdVpd.h for PcdSdDetectChk and PcdCaMirrorEnHannah Williams
Change-Id: I42200feafed613136f23e37d4ab4c90931698821 Signed-off-by: Hannah Williams <hannah.williams@intel.com> Reviewed-on: https://review.coreboot.org/13038 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-27chromeos: vpd: Avoid reading uninitialized VPDsJulius Werner
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>
2016-01-27chromeos: Add timestamps to measure VPD read timesJulius Werner
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>
2016-01-22vboot2: Handle slow EC SW sync and graphics driver loadingDuncan Laurie
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>
2016-01-21vboot: Install files into FW_MAIN_A and FW_MAIN_B unless they're for ROPatrick Georgi
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>
2016-01-21Chromeos: Implement wifi_regulatory_domain using "regions" key in VPDFelix Durairaj
Implement wifi_regulatory_domain function by getting country code from VPD Original-Reviewed-on: https://chromium-review.googlesource.com/314385 Original-Reviewed-by: Pratikkumar V Prajapati <pratikkumar.v.prajapati@intel.com> Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org> Original-Tested-by: Hannah Williams <hannah.williams@intel.com> Change-Id: Ia6a24df110a3860d404d345571007ae8965e9564 Signed-off-by: fdurairx <felixx.durairaj@intel.com> Signed-off-by: Hannah Williams <hannah.williams@intel.com> Reviewed-on: https://review.coreboot.org/12743 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <martinroth@google.com>
2016-01-17intel/skylake: During RO mode after FSP reset CB lose original stateSubrata Banik
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>
2016-01-16vendorcode/intel/.../skylake: Update FspUpdVpd.h to v1.8.1Martin Roth
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>
2016-01-08vendorcode/amd/agesa/f15tn: Fix out of bounds read on on memory voltageMartin Roth
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>
2016-01-07src/vendorcode/amd: correct spelling of MTRRPaul Menzel
Change-Id: I7576591b42fa62da2b3bd74f961fb297b85e250d Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-on: https://review.coreboot.org/4806 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2016-01-07f14: Increase AP stack to 8k on 64bitStefan Reinauer
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>
2016-01-06commonlib: Add function to hash contents of a CBFS region.Aaron Durbin
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)
2015-12-17vendorcode: google: chromeos: Remove old fmap.c fileJulius Werner
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)
2015-12-10lib: remove assets infrastructureAaron Durbin
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>
2015-12-10cbfs/vboot: remove firmware component supportAaron Durbin
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>
2015-12-08vendorcode/google/chromeos: Only select ELOG if SPI_FLASH is availableMartin Roth
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>
2015-12-04braswell/skylake: Add FspUpdVpd.h to fix compilationStefan Reinauer
Imported from cros repo 18ae19c Change-Id: Ib88ac9b37d2f86d323b9a04cb17a5a490c61ff5b Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: https://review.coreboot.org/12467 Reviewed-by: Hannah Williams <hannah.williams@intel.com> Tested-by: build bot (Jenkins)
2015-12-02build system: Add more files through cbfs-files instead of manual rulesPatrick Georgi
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>
2015-11-21chromeos: Fix Kconfig TPM warnings on systems with no LPC TPMMartin Roth
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>
2015-11-19vendorcode/google/chromeos: Cache VPD data into CBMEMHung-Te Lin
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)
2015-11-18fsp1_0: Update rangeley to revision POSTGOLD4Marcin Wojciechowski
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>
2015-11-12AMD Merlin Falcon: update vendorcode header files to CarrizoPI 1.1.0.1zbao
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>
2015-11-10southbridge/intel: Add FSP based i89xx southbridge supportMarc Jones
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>
2015-11-06amd/pi/Makefile: Remove cp option '-u'zbao
"-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>
2015-10-31tree: drop last paragraph of GPL copyright headerPatrick Georgi
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>
2015-10-30Drop unused code from gcc-intrin.hStefan Reinauer
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>
2015-10-30cpu/amd: Fix cbtypes.h to match UINTN conventionStefan Reinauer
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>
2015-10-30vendorcode/amd: 64bit fixesStefan Reinauer
Change-Id: I6a0752cf0c0e484e670acca97c4991b5578845fb Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11081 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2015-10-28vboot2: Fix flows for TPM_E_MUST_REBOOTFurquan Shaikh
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)
2015-10-28vboot: check vb2_shared_data flags for manual recoveryDaisuke Nojiri
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>
2015-10-24amd/sb800: Make UsbRxMode per-board customizableTobias Diedrich
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>
2015-10-22Revert "Remove sandybridge and ivybridge FSP code path"Martin Roth
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 fb50124d22014742b6990a95df87a7a828e891b6. 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>
2015-10-19vendorcode/google: Deal with MULTIPLE_CBFS_INSTANCESPatrick Georgi
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>
2015-10-14Revert "Remove FSP Rangeley SOC and mohonpeak board support"Martin Roth
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 959478a763c16688d43752adbae2c76e7764da45. 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>
2015-10-14x86: add standalone verstage supportAaron Durbin
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>
2015-10-14vboot: allow more flexibility when adding verstageAaron Durbin
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>
2015-10-11vboot: prepare for x86 verstageAaron Durbin
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>
2015-10-11vboot: restructure vboot work buffer handlingAaron Durbin
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>
2015-10-07cbfs: add struct cbfsfAaron Durbin
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>
2015-10-06vboot2: Look up actual CBFS in MULTIPLE_CBFS configurationPatrick Georgi
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>
2015-10-03Remove FSP Rangeley SOC and mohonpeak board supportAlexandru Gagniuc
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>
2015-10-03Remove sandybridge and ivybridge FSP code pathAlexandru Gagniuc
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>
2015-10-02vboot: provide CHIPSET_PROVIDES_VERSTAGE_MAIN_SYMBOL optionAaron Durbin
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>
2015-10-02fsp1_1: move relocation algorithm to commonlibAaron Durbin
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>
2015-09-30chromeos: vboot_common: Avoid code duplication when grabbing the handoff infoPaul Kocialkowski
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>
2015-09-30vboot: provide a unified flow for separate verstageAaron Durbin
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>
2015-09-29chromeos: vboot-related functions move to common vboot codePaul Kocialkowski
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>
2015-09-23chromeos: vboot and chromeos dependency removal for sw write protect statePaul Kocialkowski
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>
2015-09-22coreboot: introduce commonlibAaron Durbin
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>
2015-09-17vbnv: check alignment of nvram in advanceDaisuke Nojiri
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>
2015-09-16AMD Merlin Falcon: update vendorcode header files to CarrizoPI 1.1.0.0WANG Siyuan
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>
2015-09-16AMD Steppe Eagle: update vendorcode header files to MullinsPI 1.0.0.AWANG Siyuan
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>
2015-09-10fsp1_1: provide binding to UEFI versionAaron Durbin
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)
2015-09-09verstage: use common program.ld for linkingAaron Durbin
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>