summaryrefslogtreecommitdiff
path: root/src/vendorcode
AgeCommit message (Collapse)Author
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>
2015-08-26Chromeos: Remove Kconfig workaround for VIRTUAL_DEV_SWITCH warningsMartin Roth
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>
2015-08-11chromeos: Allow for VB_SOURCE overridePaul Kocialkowski
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>
2015-08-10chromeos: vboot: Adaptations for using a separate object out directoryPaul Kocialkowski
$(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>
2015-08-09f10/f12: Remove whitespace from gcccar.incStefan Reinauer
:'<,'>s,\ *$,, Change-Id: I9fca0e12f02d6fff4644abacecd4a31cea64bbc1 Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-on: http://review.coreboot.org/11024 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2015-08-07vendorcode: Move AMD sources from blobs to vendorcodeMarc Jones
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>
2015-08-05vendorcode: Fixup AGESA PI Kconfig variablesMarc Jones
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>
2015-07-30vendorcode: 64bit fixes for AMD CIMX SB800Stefan Reinauer
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>
2015-07-30vendorcode: Port AMD Agesa for Fam14 to 64bitStefan Reinauer
Change-Id: Ic6b3c3382a6d3fdc6d716ea899db598910b4fe3e Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Signed-off-by: Scott Duplichan <scott@notabs.org> Reviewed-on: http://review.coreboot.org/10581 Tested-by: build bot (Jenkins) Tested-by: Raptor Engineering Automated Test Stand <noreply@raptorengineeringinc.com>
2015-07-30amd/bettong: Enable fan controlWANG Siyuan
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>
2015-07-30AMD binary PI: add vendorcode support for fan controlWANG Siyuan
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>
2015-07-29arm, arm64, mips: Add rough static stack size checks with -Wstack-usageJulius Werner
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>
2015-07-23vboot: set software write protect flagDaisuke Nojiri
TEST=built for samus and veyron_jerry Change-Id: I7173f46d2ed2e323bff227a484c32c4bb6f6c828 Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: http://review.coreboot.org/11028 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-21intel/fsp_baytrail: Support Baytrail FSP Gold4 releaseYork Yang
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>
2015-07-15cbfs: hardcode file alignmentPatrick Georgi
Assume that it's 64 byte. Change-Id: I168facd92f64c2cf99c26c350c60317807a4aed4 Signed-off-by: Patrick Georgi <pgeorgi@chromium.org> Reviewed-on: http://review.coreboot.org/10919 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@chromium.org>
2015-07-15intel/fsp_baytrail: Remove PcdEnableLan optionYork Yang
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>
2015-07-08vboot: Don't count boot attempts if lid is closedPatrick Georgi
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>
2015-07-08vendorcode/intel/edk2: Fix EFI_PEI_GRAPHICS_INFO_HOB structureLee Leahy
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>
2015-07-07x86: Drop -Wa,--divideStefan Reinauer
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>
2015-06-30vboot: move vbnv_* sources around a bit more.Patrick Georgi
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>
2015-06-30chromeos: push vbnv_* accessors from verstage to libverstagePatrick Georgi
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>
2015-06-30Add Kconfig flag to specify if there's a lid switchPatrick Georgi
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>