summaryrefslogtreecommitdiff
path: root/src/vendorcode
AgeCommit message (Collapse)Author
2014-11-21intel/fsp_baytrail: add Gold3 FSP supportYork Yang
Baytrail Gold3 FSP adds a couple of parameters in UPD_DATA_REGION making platform more configurable via devicetree.cb Update the UPD_DATA_REGION structure and pass settings to FSP Add Baytrail Gold2 and earlier FSP backward compatible, as Gold3 FSP changes UPD_DATA_REGION struct Change-Id: Ia2d2d0595328ac771762a84da40697a3b7e900c6 Signed-off-by: York Yang <york.yang@intel.com> Reviewed-on: http://review.coreboot.org/7334 Reviewed-by: Martin Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins)
2014-11-20AMD: Isolate AGESA and PI build environments for southbridgeKyösti Mälkki
To backport features introduced with recent Chromebooks and/or Intel boards in general, heavy work on the AMD AGESA platform infrastructure is required. With the AGESA PI available in binary form only, community members have little means to verify, debug and develop for the said platforms. Thus it makes sense to fork the existing agesawrapper interfaces, to give AMD PI platforms a clean and independent sandbox. New directory layout reflects the separation already taken place under 3rdparty/ and vendorcode/. Change-Id: Ia730f0e45e7c1bdfc0c91e95eb6729a77773e2b9 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7388 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins)
2014-11-20AMD: Isolate AGESA and PI build environmentsKyösti Mälkki
To backport features introduced with recent Chromebooks and/or Intel boards in general, heavy work on the AMD AGESA platform infrastructure is required. With the AGESA PI available in binary form only, community members have little means to verify, debug and develop for the said platforms. Thus it makes sense to fork the existing agesawrapper interfaces, to give AMD PI platforms a clean and independent sandbox. New directory layout reflects the separation already taken place under 3rdparty/ and vendorcode/. Change-Id: Ib60861266f8a70666617dde811663f2d5891a9e0 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7149 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Tested-by: build bot (Jenkins)
2014-11-20vendorcode/amd/agesa/f15?tn: Reduce useless differencesSara Lelliott
Reduce inconsequential differences between fam15 and fam15tn to better prepare for possible merger. Change-Id: I016aa1a4cc45553d51190988d48c8a54cfd85f5a Signed-off-by: Sara Lelliott <sara@jupitercrash.org> Reviewed-on: http://review.coreboot.org/7503 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-11-20vendorcode/amd/agesa/f*/Porting.h: Sync files across fam'sEdward O'Callaghan
Sync up these 'Porting.h' headers to include fixes from each family on botched-up typedef's for primitive data types. Fix corresponding breakage introduced by typecasts in mainboards. Change-Id: I003b155cc6c860f6b0cd75667083634a04814473 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7512 Tested-by: build bot (Jenkins)
2014-11-19vendorcode/amd/agesa/f15tn: Fix assembly bugsDamien Zammit
Found missing '$' symbol on variable. Change-Id: I748c315adc44598e16283f8e629be0ecfe9cb6a9 Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: http://review.coreboot.org/7514 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-11-19vendorcode/amd/agesa/f15tn: Remove extraneous bracketDamien Zammit
Found an extra bracket that appears it should not be there. Change-Id: I66b7967833afd25f12bd4eaaf6419a6ed3ad544b Signed-off-by: Damien Zammit <damien@zamaudio.com> Reviewed-on: http://review.coreboot.org/7515 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-15vboot: allow non-relocatable ramstage loadingAaron Durbin
The vboot implementation previously assumed that ramstage would be a relocatable module. Allow for ramstage not being a relocatable module. BUG=chrome-os-partner:27094 BRANCH=None TEST=Built nyan with vboot. Original-Change-Id: Id3544533740d77e2db6be3960bef0c129173bacc Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/190923 Original-Reviewed-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 756ee3a6987097c65588c8784ee9653fd6e735e4) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: I813b07e1bec75640ad4066aca749ba8dccec31d4 Reviewed-on: http://review.coreboot.org/7220 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-11-15chromeos: provide stub functions for !CONFIG_VBOOT_VERIFY_FIRMWAREAaron Durbin
Instead of checking #if CONFIG_VBOOT_VERIFY_FIRMWARE #else #endif provide empty stub functions for !CONFIG_VBOOT_VERIFY_FIRMWARE. BUG=none BRANCH=baytrail TEST=Built and booted. Original-Change-Id: Id9d1843a0ec47c5a186c9a22ea3e4c13c89ec379 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/184841 (cherry picked from commit f6d95cf4ba6ce1bc0e1df4a0e9f655ad9fea9feb) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Change-Id: If35ace863243e36399fc40c2802a2f7f2711e83b Reviewed-on: http://review.coreboot.org/7395 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-11-13AMD Trinity: Update the Trinity SMU FirmwareZheng Bao
Change-Id: I059047390e80e084f5d7763259d918446d96931e Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/7294 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-11-13vboot: provide empty vboot_verify_firmware()Aaron Durbin
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being selected allow for calling vboot_verify_firmware() with an empty implementation. This allows for one not to clutter the source with ifdefs. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded call to vboot_verify_firmware(). Original-Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5 Original-Signed-off-by: Aaron Durbin <adurbin@chromium.org> Original-Reviewed-on: https://chromium-review.googlesource.com/172711 Original-Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> (cherry picked from commit c1e0e5c7b39c947b2a0c237b4678944ab86dd780) Signed-off-by: Marc Jones <marc.jones@se-eng.com> Conflicts: src/vendorcode/google/chromeos/chromeos.h Change-Id: Iaaa3bedbe8de701726c28412e7eb75de0c58c9c9 Reviewed-on: http://review.coreboot.org/7394 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-11-13vendorcode/amd/agesa/f1{0,2,4,5}: Typo in header guardEdward O'Callaghan
Change-Id: I05d568f27f610c395e2638e79a7fd6646a407955 Found-by: Clang preprocessor wizard powers Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7441 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-11-11AMD Kabini: Update SMU firmware from 0.4 to 0.9Zheng Bao
Version 0.9 contains a fix for a security issue. A more detailed changelog is not available. Change-Id: I1a66c9da900f89ba9b4c13f3457582278d3793e2 Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/7293 Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Rudolf Marek <r.marek@assembler.cz> Tested-by: build bot (Jenkins)
2014-11-10AGESA f14: Add "const" modifiersEdward O'Callaghan
Apply commit 283ba78415 to f14 (literally, plus one adaptation). Change-Id: Ieea47470e5852ec8a46596ce23a2d18444618624 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7361 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-11-09src: Too many terminators ';;' at end of stmts, stop SkynetEdward O'Callaghan
Change-Id: I3e9b7e0e5558a6942067dcea04b83fe3bccbbaf9 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7362 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
2014-11-04amd/agesa/f16kb: Invalid inline asm in gcc-intrin.hEdward O'Callaghan
Forward port commit: db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm Change-Id: Ia857f76d3782aea07e09df1352eeb286e40b2689 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7302 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-11-03AGESA f12: Add "const" modifiersPatrick Georgi
Apply commit 283ba78415 to f12 (literally, plus one adaptation). Change-Id: Ied7891806e269320caf968cae3de3dc792c5f8fd Signed-off-by: Patrick Georgi <pgeorgi@google.com> Reviewed-on: http://review.coreboot.org/7312 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-11-02amd/agesa/f15: Invalid inline asm in gcc-intrin.hEdward O'Callaghan
Forward port commit: db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm Change-Id: I52da16b39293c8aeff150db83b8b1aeaa232c205 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7299 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-11-02amd/agesa/f12: Invalid inline asm in gcc-intrin.hEdward O'Callaghan
Forward port commit: db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm Change-Id: Ife26fb5eca5164e72b5e55eba90757253765b633 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7300 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-11-02amd/agesa/f10: Invalid inline asm in gcc-intrin.hEdward O'Callaghan
Forward port commit: db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm Change-Id: Ic1bd19087a4500ba0ca9e312ea351e301ab42518 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/7301 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-10-22AGESA fam15tn fam16kb: Fix missing FCH function prototypesKyösti Mälkki
Change-Id: I242664032d368794d828fce73a20f75ded45051d Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/7151 Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-10-09AGESA stub 00730F01: Add config.h and kconfig.h to Makefile.incBruce Griffith
The static library builder for the stub that interfaces to the AGESA binary does not include config.h and kconfig.h, so any header file changes that depend on Kconfig variables fail. Force these two system headers to be included in the build of any AGESA stub files. Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Change-Id: I2e8d38fa5aa21cc31b995ee3abe68ab3c3c55a68 Reviewed-on: http://review.coreboot.org/6979 Reviewed-by: Martin Roth <gaumless@gmail.com> Tested-by: build bot (Jenkins)
2014-10-07vendorcode: Add ChromeOS VPD parser.Hung-Te Lin
Copied (and unmodified) the minimal bits from ChromeOS libVPD: https://chromium.googlesource.com/chromiumos/platform/vpd Old-Change-Id: Id75d1bfd16263ac1b94c22979f9892cf7908d5e6 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/187411 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> (cherry picked from commit a10ca23686299f3fd5b639631242cadaa2ca9e8a) vendorcode: Update ChromeOS VPD Parser. Merge recent changes in ChromeOS VPD that allows non-memory-mapped firmware to load VPD easier and faster (ref: https://chromium-review.googlesource.com/188134 ). Old-Change-Id: I3ee0b89c703f476f3d77cdde52cc7588724f7686 Reviewed-on: https://chromium-review.googlesource.com/188743 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> Commit-Queue: Hung-Te Lin <hungte@chromium.org> (cherry picked from commit 03f4d521a7fa711b963b0e1822e92eac16a691b1) vendorcode: Access to ChromeOS VPD on default CBFS media. The new function "cros_vpd_gets(key, buf, size)" provides an easy and quick way to retrieve values in ChromeOS VPD section. Old-Change-Id: I38e50615e515707ffaecdc4c4fae65043541b687 Signed-off-by: Hung-Te Lin <hungte@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/187430 Reviewed-by: Yung-chieh Lo <yjlou@chromium.org> (cherry picked from commit bcd3832c06e8ed357c50f19396da21a218dc4b39) Squashed 3 related commits for a ChromeOS VPD parser. Change-Id: I4ba8fce16ea123c78d7b543c8353ab9bc1e2aa9f Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6959 Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Tested-by: build bot (Jenkins)
2014-09-10tpm: Clean up I2C TPM driverStefan Reinauer
Drop a lot of u-boot-isms and share common TIS API between I2C driver and LPC driver. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: I43be8eea0acbdaef58ef256a2bc5336b83368a0e Reviewed-on: https://chromium-review.googlesource.com/175670 Commit-Queue: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: David Hendricks <dhendrix@chromium.org> (cherry picked from commit 3fc8515b9dcef66998658e1aa5c020d22509810c) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6855 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-09-08ARM: Generalize armv7 as arm.Gabe Black
There are ARM systems which are essentially heterogeneous multicores where some cores implement a different ARM architecture version than other cores. A specific example is the tegra124 which boots on an ARMv4 coprocessor while most code, including most of the firmware, runs on the main ARMv7 core. To support SOCs like this, the plan is to generalize the ARM architecture so that all versions are available, and an SOC/CPU can then select what architecture variant should be used for each component of the firmware; bootblock, romstage, and ramstage. Old-Change-Id: I22e048c3bc72bd56371e14200942e436c1e312c2 Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://chromium-review.googlesource.com/171338 Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 8423a41529da0ff67fb9873be1e2beb30b09ae2d) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> ARM: Split out ARMv7 code and make it possible to have other arch versions. We don't always want to use ARMv7 code when building for ARM, so we should separate out the ARMv7 code so it can be excluded, and also make it possible to include code for some other version of the architecture instead, all per build component for cases where we need more than one architecture version at a time. The tegra124 bootblock will ultimately need to be ARMv4, but until we have some ARMv4 code to switch over to we can leave it set to ARMv7. Old-Change-Id: Ia982c91057fac9c252397b7c866224f103761cc7 Reviewed-on: https://chromium-review.googlesource.com/171400 Reviewed-by: Gabe Black <gabeblack@chromium.org> Tested-by: Gabe Black <gabeblack@chromium.org> Commit-Queue: Gabe Black <gabeblack@chromium.org> (cherry picked from commit 799514e6060aa97acdcf081b5c48f965be134483) Squashed two related patches for splitting ARM support into general ARM support and ARMv7 specific pieces. Change-Id: Ic6511507953a2223c87c55f90252c4a4e1dd6010 Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6782 Tested-by: build bot (Jenkins)
2014-08-30AMD Steppe Eagle: Add binary PI vendorcode filesBruce Griffith
Add all of the PI source that will remain part of coreboot to build with a binary AGESA PI BLOB. This includes the gcc makefiles, some Kconfig, and the AGESA standard library functions. Change vendorcode Makefile and Kconfig so that they can compile AMD library files and use headers from outside the coreboot/src tree. The AGESA dispatcher is built using its own rules rather than generic library generation rules in coreboot/Makefile and coreboot/Makefile.inc. The AGESA source files are initially copied from whereever they live into coreboot/build/agesa. They are compiled from there. The binary PI directory has a mandatory structure that places the AGESA BLOB into the same directory as the support headers. These will nominally be placed in the 3rdparty directory in coreboot.org. The copy commands that were added to the the vendorcode Makefile.inc ensure that only one thread will operate on each source file by using a macro to generate the copy targets. After the change, each copy target will operate on exactly one source file. Due to API issues, coreboot has no way to control the IMC to set up fan control. Set a Kconfig flag that removes the ability to install an IMC BLOB into CBFS. Change-Id: I050b72a19086aaeba6cb65ce165297b10e3cfc45 Signed-off-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-on: http://review.coreboot.org/6595 Tested-by: build bot (Jenkins) Reviewed-by: WANG Siyuan <wangsiyuanbuaa@gmail.com> Reviewed-by: Zheng Bao <zheng.bao@amd.com>
2014-08-13chromeos: On ARM platforms VBNV lives in the ECStefan Reinauer
This patch renames the x86 way of doing things to explicitly mention CMOS (which is not available on our ARM platforms) and adds an implementation to get VBNV through the Chrome EC. We might want to refine this further in the future to allow VBNV in the EC even on x86 platforms. Will be fixed when that appears. Also, not all ARM platforms running ChromeOS might use the Google EC in the future, in which case this code will need additional work. Signed-off-by: Stefan Reinauer <reinauer@google.com> Change-Id: Ice09d0e277dbb131f9ad763e762e8877007db901 Reviewed-on: https://chromium-review.googlesource.com/167540 Reviewed-by: David Hendrix <dhendrix@chromium.org> Tested-by: Stefan Reinauer <reinauer@google.com> Commit-Queue: Stefan Reinauer <reinauer@google.com> (cherry picked from commit 8df6cdbcacb082af88c069ef8b542b44ff21d97a) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6616 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-08-11vendorcode/intel/fsp/baytrail/absf: add Minnow Max absf filesMartin Roth
The absf files contain the modifications to the default settings in the FSP. They are used as input files for Intel's 'Binary Configuration Tool' (BCT) along with the FSP.bin file to generate customized FSP binaries. The Minnow Max absf files set up the values for the soldered down memory. This requirement will go away with the release of the next Bay Trail FSP, and the memory settings will be configurable at runtime. Change-Id: Id72545d78a7e82d9a5090710a9c7a8a9b1e81208 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/6432 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-08-11coreboot classes: Add dynamic classes to corebootFurquan Shaikh
Provide functionality to create dynamic classes based on program name and architecture for which the program needs to be compiled/linked. define_class takes program_name and arch as its arguments and adds the program_name to classes-y to create dynamic class. Also, compiler toolset is created for the specified arch. All the files for this program can then be added to program_name-y += .. Ensure that define_class is called before any files are added to the class. Check subdirs-y for order of directory inclusion. One such example of dynamic class is rmodules. Multiple rmodules can be used which need to be compiled for different architectures. With dynamic classes, this is possible. Change-Id: Ie143ed6f79ced5f58c200394cff89b006bc9b342 Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/6426 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-08-10vboot: Implement VbExGetTimer using monotonic timersStefan Reinauer
On x86 VbExGetTimer() uses rdtsc. However, on all other platforms, let's just use coreboot's monotonic timers. Change-Id: I0cd359f298be33776740305b111624147e2c850d Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/169620 (cherry picked from commit e910bb17522d5de42c0fc3cc945278e733fa2553) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6534 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-08-08chromeos: Add code to read FMAP on ARMStefan Reinauer
On ARM the SPI flash is not memory mapped. Use the CBFS interface to map the correct portion. Change-Id: I8ea9aa0119e90a892bf777313fdc389c4739154e Signed-off-by: Stefan Reinauer <reinauer@google.com> Reviewed-on: https://chromium-review.googlesource.com/169781 Reviewed-by: David Hendrix <dhendrix@chromium.org> (cherry picked from commit a263d3717e82c43fe91e7c4e82d167e74bf27527) Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com> Reviewed-on: http://review.coreboot.org/6522 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-08-01vendorcode/intel/fsp/rangeley/include: Missing 'fsptypes.h'Edward O'Callaghan
Without the inclusion of 'fsptypes.h' the order of inclusion becomes tentative. Change-Id: I6360e4ebac6c414c380a19ef69d39d658ea203bd Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6423 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <gaumless@gmail.com>
2014-07-18vendorcode/amd/agesa: Use macros already defined in stdlib.hEdward O'Callaghan
We already have these macros define in 'stdlib.h'. Make good use of them here to avoid redefinition conflicts of the pre-processor depending on header inclusion ordering. This has the nice side-effect of syncing up AGESA families in this particular regard. Change-Id: Icf911629a4a1a82b01062fe16af4c8f812b05717 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6199 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2014-07-11vendorcode/amd/agesa/f15tn: Fix erratum #712Rudolf Marek
Implement the fix for the erratum #712. - Processor May Hang During Graphics Memory Controller Sequencing The processor may hang during a graphics memory controller (GMC) sleep state transitioning. The failure may be processor specific and may be sensitive to temperature. Potential Effect on System: System hang. Suggested Workaround: BIOS should set D18F2x408_dct[1:0] bit 31 = 1b. See Publication # 48931 Revision: 3.08 Change-Id: I4346fd4ef3cf554ffdaaad5ab6fc84e73532e885 Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/6216 Tested-by: build bot (Jenkins) Reviewed-by: Martin Roth <gaumless@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
2014-07-10vendorcode/amd/agesa/f14: Trivial - drop whitespaces in .hEdward O'Callaghan
Change-Id: Ic63c456e775ad0863ea773abd957d9399e8e2a13 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6191 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/agesa/f14: Trivial - drop trailing whitespacesEdward O'Callaghan
Change-Id: I716253fe8532a4215e5770cd901ee3b3c4963d3d Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6187 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/agesa/f12: Trivial - drop whitespaces in .hEdward O'Callaghan
Change-Id: Iace2ccfe95bd7f7e5dabbbc69ee4249d80d1cb84 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6190 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/agesa/f12: Trivial - drop trailing whitespacesEdward O'Callaghan
Change-Id: Ieca3358a2a459016b7a38dce7f717100b55baba5 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6186 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/agesa/f10: Trivial - drop whitespaces in .hEdward O'Callaghan
Change-Id: Ie8d74970ef8969cf65b40970cb234399c3db8e56 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6189 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/agesa/f10: Trivial - drop trailing whitespacesEdward O'Callaghan
Change-Id: I8f4b2b555d71dd30f134e41ce998c946c4ac0280 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6185 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/cimx: Trivial - drop trailing whitespaces in .hEdward O'Callaghan
Change-Id: I3af50553191d7df9255be222eaf941b4232955d9 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6188 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-10vendorcode/amd/cimx: Trivial - drop trailing whitespaces in .cEdward O'Callaghan
Change-Id: I485f79ece481210f31b0b6d3c62d7269131e29ab Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6184 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-08vendorcode/google: Trivial - drop trailing blank lines at EOFEdward O'Callaghan
Change-Id: Ib8d26d62566e42a78abc282dc9e351774b8e2faf Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6212 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-07-08vendorcode/intel: Trivial - drop trailing blank lines at EOFEdward O'Callaghan
Change-Id: Iea9e95981e5e87f2890841e7a0cf45ba93ce84eb Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/6211 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-06-14amd/agesa/f15tn: Invalid inline asm in gcc-intrin.hEdward O'Callaghan
Forward port commit: db0e0e2 amd/agesa/*/gcc-intrin.h: Invaild inline asm Change-Id: I87bf101b15bac7c06afa9cec10e2bd4e0cdfd6c7 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5941 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-06-14amd/agesa/f14: Backport f15tn fixes from DDR3 in mtspd3.cEdward O'Callaghan
Change-Id: I710efc3171e1653241f2dba1217a9560d2d99a16 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5802 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-25ChromeOS: Rename chromeos.c in vendorcodeKyösti Mälkki
Rename the file to vboot_handoff.c and compile it conditionally with VBOOT_VERIFY_FIRMWARE. Change-Id: I8b6fd91063b54cb8f5927c6483a398b75e1d262a Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5645 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-23vendorcode/intel/fsp/rangeley: remove extra fileMartin Roth
This is an extra file that is included in the Intel GSP release. It's got a coreboot header on it, isn't used, and looks very platform specific. I'm not sure where it belongs, but it doesn't belong in vendorcode. I've sent the contacts at Intel an email letting them know that this file should probably be removed from their FSP release and is getting removed here. Change-Id: I5ac6649235846ce5716bb180af29a5e422f4cce3 Signed-off-by: Martin Roth <gaumless@gmail.com> Signed-off-by: Martin Roth <martin.roth@se-eng.com> Reviewed-on: http://review.coreboot.org/5809 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-22vendorcode/amd/agesa/f*: Fix typo in header guardsEdward O'Callaghan
_CPU_L3_FEATIRES_H -> _CPU_L3_FEATURES_H Spotted by Clang Change-Id: I1eabebffc7fd5e4f37b28dabcd28984bed64acd8 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5818 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-21amd/agesa/*/gcc-intrin.h: Invaild inline asmEdward O'Callaghan
The 'm' (a memory reference) constraint makes little sense here since we are talking about a fs relative read, rather 'ir' (immediate or register) constraint is more sensible. N.B. The 'p' constraint allows anything which fits the form of an address calculation where the 'ir' constraint is just a register /xor/ immediate. Hence would produce better code here however, unfortunately, clang does not currently support it properly. The %b and %w constraints are also redundant and only hide errors. The functions writefsword() and writefsdword() should use ir instead of iq. iq is unnecessarily restrictive (it is only required for writing bytes). The cld in stosb is redundant (and the constraints are unnecessarily complicated). Note that The ABI guarantees that the direction flag is cleared. i.e. eax, ecx, edx are caller-saved, returned value in eax, eax+edx, st0, yaddayadda, direction flag cleared. In fact bad things can happen if you set it in some asm and do not clear it until the end of the asm. Line wrap these extraneously long lines found with these particular functions. Many thanks to Christoph Mallon <christoph.mallon@gmx.de> from #llvm for helping me with this. Change-Id: Iaf3ad65791640e1060a2029e7ebb043f57b338a9 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5758 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-21amd/agesa/f1?/Lib/amdlib.c: Integer overflow in loop constructEdward O'Callaghan
The semantics of this loop relies on an integer overflow in Index >=0 that implies a return value of (UINT8)-1 which around wraps to 0xFF, or VOLT_UNSUPPORTED. Change-Id: I44d68973d0a80093350b2a8a4d3b46bfbb57917a Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5801 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-21vendorcode/amd/agesa: unsigned enum is strictly positiveEdward O'Callaghan
The typedef'ed BIT_FIELD_NAME enum is type unsigned. The parameter 'FieldName' is decleared with type BIT_FIELD_NAME and thus the redudant comparison of unsigned enum expression >= 0 is always true. BIT_FIELD_NAME is declared in vendorcode/amd/agesa/f14/Proc/Mem/mm.h Change-Id: Id2f03596c44b68e861e939f3528256d4b08c45ce Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5757 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-21amd/cimx/sb?00/SATA.c: Integer overflow in loop conditionEdward O'Callaghan
The conditional comparison in the for-loop construct with the constant 300000 has an index incrementor of type 'UINT16' (aka 'unsigned short') which is always true. Change-Id: I932c168742163be4038728fb40833231a447fa78 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5799 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-21baytrail: Fix some minor errors in FSPDavid Hendricks
- Duplicate declaration of GetFspReservedMemoryFromGuid - Corrupt line that was only compiled for a southbridge that no board in coreboot currently uses. (thanks for Mike Hibbett <mhibbett@ircona.com> for pointing this out) Change-Id: I847e807272acbaa93c87a89c0d2f94829c9121e6 Signed-off-by: David Hendricks <dhendrix@chromium.org> Reviewed-on: http://review.coreboot.org/5798 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-05-19vendorcode/amd/agesa: Logic typo in GfxPowerPlayLocateTdpEdward O'Callaghan
The function GfxPowerPlayLocateTdp() sets MinDeltaSclk to a maximum sentinel value and checks DeltaSclk in a loop to minimize MinDeltaSclk. However, MinDeltaSclk incorrectly self-assigns. Change-Id: Id01c792057681516bba411adec268769a3549aa8 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5752 Tested-by: build bot (Jenkins) Reviewed-by: Dave Frodin <dave.frodin@se-eng.com>
2014-05-19amd/agesa: Implicit assigment between enum without castEdward O'Callaghan
Change-Id: I31632948ce69b2d1ff63b6c920016ed6fdf9e2f8 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5760 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-19amd/agesa/f*: Strip tailing white-spaces from gcc-intrin.hEdward O'Callaghan
Change-Id: I1d801b9d8387e267feeb95563e55910b30ebbc34 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5790 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-05-19build: use CFLAGS_* in more places where they're neededPatrick Georgi
After moving out -m32 from CC_*, 64bit compilers need CFLAGS_* in more places to handle everything in 32bit as appropriate. Change-Id: I692a46836fc0ba29a3a9eb47b123e3712691b45d Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5789 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-19vendorcode/amd: kill some intermediate variables in build systemPatrick Georgi
They don't exactly add clarity, but increase the risk they're used at some obscure place. Change-Id: Ic74f72dae3f9b7eb2343cb5c51bc44c888e1276c Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5787 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-19build: move include paths where they belongPatrick Georgi
They're _not_ part of the compiler binary, so they have no place in $(CC_*) Change-Id: I1e1c3c0be6f75629450a824ea834e1614d48ed9b Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5785 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-19agesa: drop non-existing search pathsPatrick Georgi
With the upcoming CC/CFLAGS/CPPFLAGS split, romcc gets more CPPFLAGS, and it's picky about directories actually existing. Change-Id: Ib9c525296e5be0c8ace935ab8096bc98206cbcc1 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5784 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17build: kill one indirectionPatrick Georgi
No need to first define X86_32 and then replace every single use of it with its lower cased equivalent. Just start out with the lower case versions in the first place. Change-Id: I1e771ef443db1b8d34018d19a64a9ee489cd8133 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5767 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17build: separate CPPFLAGS from CFLAGSPatrick Georgi
There are a couple of places where CPPFLAGS are pasted into CFLAGS, eliminate them. Change-Id: Ic7f568cf87a7d9c5c52e2942032a867161036bd7 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5765 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-17build: CPPFLAGS is more common than INCLUDESPatrick Georgi
Rename INCLUDES to CPPFLAGS since the latter is more commonly used for preprocessor options. Change-Id: I522bb01c44856d0eccf221fa43d2d644bdf01d69 Signed-off-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-on: http://review.coreboot.org/5764 Tested-by: build bot (Jenkins) Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
2014-05-08Declare get_write_protect_state() without ChromeOSKyösti Mälkki
Change-Id: I72471ac68088cd26f8277b27b75b7d44ad72cfc4 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5642 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-08Rename from save_chromeos_gpios() to init_bootmode_straps()Kyösti Mälkki
This feature is no longer specific to ChromeOS builds. Change-Id: If27d4dc7caff8a551b5b325cdebdd05c079ec921 Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5641 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-08ChromeOS boards: Use explicit include of chromeos.cKyösti Mälkki
Change-Id: I7b3d044fad1d6973910e9bef347478a45c149a4f Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5640 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-05-06Introduce stage-specific architecture for corebootFurquan Shaikh
Make all three coreboot stages (bootblock, romstage and ramstage) aware of the architecture specific to that stage i.e. we will have CONFIG_ARCH variables for each of the three stages. This allows us to have an SOC with any combination of architectures and thus every stage can be made to run on a completely different architecture independent of others. Thus, bootblock can have an x86 arch whereas romstage and ramstage can have arm32 and arm64 arch respectively. These stage specific CONFIG_ARCH_ variables enable us to select the proper set of toolchain and compiler flags for every stage. These options can be considered as either arch or modes eg: x86 running in different modes or ARM having different arch types (v4, v7, v8). We have got rid of the original CONFIG_ARCH option completely as every stage can have any architecture of its own. Thus, almost all the components of coreboot are identified as being part of one of the three stages (bootblock, romstage or ramstage). The components which cannot be classified as such e.g. smm, rmodules can have their own compiler toolset which is for now set to *_i386. Hence, all special classes are treated in a similar way and the compiler toolset is defined using create_class_compiler defined in Makefile. In order to meet these requirements, changes have been made to CC, LD, OBJCOPY and family to add CC_bootblock, CC_romstage, CC_ramstage and similarly others. Additionally, CC_x86_32 and CC_armv7 handle all the special classes. All the toolsets are defined using create_class_compiler. Few additional macros have been introduced to identify the class to be used at various points, e.g.: CC_$(class) derives the $(class) part from the name of the stage being compiled. We have also got rid of COREBOOT_COMPILER, COREBOOT_ASSEMBLER and COREBOOT_LINKER as they do not make any sense for coreboot as a whole. All these attributes are associated with each of the stages. Change-Id: I923f3d4fb097d21071030b104c372cc138c68c7b Signed-off-by: Furquan Shaikh <furquan@google.com> Reviewed-on: http://review.coreboot.org/5577 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@gmail.com>
2014-05-01Build without ChromeOSKyösti Mälkki
Change-Id: I1da636573eed62ce693b984917084643787c094b Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/3978 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-05-01ChromeOS: Remove oprom_is_loadedKyösti Mälkki
A global flag oprom_is_loaded was used to indicate to U-boot that VGA option ROM was loaded and run, or that native VGA init was completed on GMA device. Implement this feature without dependency to CHROMEOS option and replace use of global variable oprom_is_loaded with call to gfx_get_init_done(). Change-Id: I7e1afd752f18e5346dabdee62e4f7ea08ada5faf Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4309 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-05-01Declare recovery and developer modes outside ChromeOSKyösti Mälkki
Move the implementation for recovery and developer modes from vendorcode/google/chromes to lib/. Change-Id: I33335fb282de2c7bc613dc58d6912c47f3b5c06c Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/4308 Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-04-15vendorcode/amd/agesa/fam14: Build as a static libraryEdward O'Callaghan
Following the same reasoning as commit ee905a8 vendorcode/amd/agesa/fam15tn: Build as a static library Since AGESA is stage-independent, we can build it just once, and use the resulting static library in both rom and ram stages. Change-Id: I8b78c462f4963fbb3a40d739196529fffedccb4c Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5441 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-04-15vendorcode/amd/agesa/fam15tn: Build as a static libraryAlexandru Gagniuc
Up until now, we were building AGESA by specifying each AGESA source file and adding it to the list of romstage and ramstage source files. As a result, we were compiling each AGESA source twice, despite the fact that it does not depend on the stage we're in. Since AGESA is stage-independent, we can build it just once, and use the resulting static library in both rom and ram stages. We still keep the practice of specifying every single AGESA directory as an include dir and adding the AGESA CFLAGS to our global CFLAGS; this is needed due to the way AGESA builds. Change-Id: I9b23264129d1c08cb67cabc31d15a68d43ed7624 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5430 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Idwer Vollering <vidwer@gmail.com>
2014-04-11Add the Rangeley FSP include & srx directoriesMartin Roth
These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Firmware Support Package for Intel® Atom™ Processor C2000 Product Family (Formerly Rangeley) "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: I9ed94cb92909c3681cc88bf10b85a9ba25e8fc55 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5457 Tested-by: build bot (Jenkins) Reviewed-by: Marc Jones <marc.jones@se-eng.com>
2014-04-11Add the Bay Trail FSP include & srx directoriesMartin Roth
These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Atom™ processor E3800 product family (formerly Bay Trail) "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: I0fa64dbaf640493cdb5e670e8d213a49d9e7dcfb Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5456 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-04-11Add the ivybridge i89xx FSP include & srx directoriesMartin Roth
These are the .h and .c files from Intel that support interaction with the FSP. These have been modified from the FSP distribution only to strip trailing whitespace. Intel® Firmware Support Package for Intel® Xeon® E3-1125C v2, E3-1105C v2, Intel® Pentium® Processor B925C, and Intel® Core™ i3-3115C Processors for Communications Infrastructure with Intel® Communications Chipset 89xx Series Platform Controller Hub (formerly Crystal Forest Refresh: Ivy Bridge Gladden and Cave Creek "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/fsp Change-Id: Ib76e89b2d2f6407cf55a5a664da989c7a7e0eb23 Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5455 Tested-by: build bot (Jenkins) Reviewed-by: David Hendricks <dhendrix@chromium.org>
2014-04-11Update vendorcode/intel/makefile for coming FSPsMartin Roth
Other FSPs have more than just the initial fsphob.c source file. Add any .c files in the srx directory to the ramstage build. Change-Id: I5118bdcca44935b579809c4fc9566ab7914a6e4b Signed-off-by: Martin Roth <martin.roth@se-eng.com> Signed-off-by: Martin Roth <gaumless@gmail.com> Reviewed-on: http://review.coreboot.org/5454 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Aaron Durbin <adurbin@google.com> Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-04-09vendorcode/amd/agesa: Do not hardcode ROM base addressAlexandru Gagniuc
The ROM address range is set up in the LPC PCI device, register 0x6c. Coreboot already sets that up correctly in the bootblock, however AGESA overrides that to 0xffffff00, which will always map the ROM from 0xff000000. This may conflict with other devices which are assigned address space in that range. If a device is assigned a range between 0xff000000 and the real ROM base, accesses to that device will be diverted to the system ROM, regardless of how other BARs are set up. Since we already need to set up the ROM address range in the bootblock, before calling AGESA, just remove the override from AGESA. Note that not all AGESA versions override this mapping. Change-Id: I592e5d087ed830c9604a04a356912c7654ce56d2 Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-on: http://review.coreboot.org/5467 Tested-by: build bot (Jenkins) Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-04-09console: Add printk helper for ChromeOSKyösti Mälkki
Do not expose console_tx_flush() to ChromeOS as that function is part of lower-level implementation. Change-Id: I1e31662da88a60e83f8e5d307a4b53441c130aab Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com> Reviewed-on: http://review.coreboot.org/5347 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-04-05chromeos: fix build breakage when !CHROMEOS_RAMOOPSAaron Durbin
Needed types were being guarded by CONFIG_CHROMEOS_RAMOOPS. Expose those unconditionally. BUG=None BRANCH=None TEST=None Change-Id: Ie858c746307ad3669eab5c35bf219e1a58da2382 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/188714 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/5453 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-03-20rmodules: use rmodtool to create rmodulesAaron Durbin
Start using the rmodtool for generating rmodules. rmodule_link() has been changed to create 2 rules: one for the passed in <name>, the other for creating <name>.rmod which is an ELF file in the format of an rmodule. Since the header is not compiled and linked together with an rmodule there needs to be a way of marking which symbol is the entry point. __rmodule_entry is the symbol used for knowing the entry point. There was a little churn in SMM modules to ensure an rmodule entry point symbol takes a single argument. Change-Id: Ie452ed866f6596bf13f137f5b832faa39f48d26e Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5379 Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org> Tested-by: build bot (Jenkins)
2014-03-11chromeos: provide option to dynamically allocate ram oops bufferAaron Durbin
Fixing the location of the ram oops buffer can lead to certain kernel and boot loaders being confused when there is a ram reservation low in the address space. Alternatively provide a mechanism to allocate the ram oops buffer in cbmem. As cbmem is usually high in the address space it avoids low reservation confusion. The patch uncondtionally provides a GOOG9999 ACPI device with a single memory resource describing the memory region used for the ramoops region. BUG=None BRANCH=baytrail,haswell TEST=Built and booted with and w/o dynamic ram oops. With the corresponding kernel change things behave correctly. Change-Id: Ide2bb4434768c9f9b90e125adae4324cb1d2d073 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5257 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
2014-03-03coreboot: unify infrastructure for loading payloadsAaron Durbin
A payload can be loaded either from a vboot region or from cbfs. Provide a common place for choosing where the payload is loaded from. Additionally, place the logic in the 'loaders' directory similarly to the ramstage loader infrastructure. Change-Id: I6b0034ea5ebd04a3d058151819ac77a126a6bfe2 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5296 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
2014-03-02vendorcode/amd/agesa/f*: Improve gcccar.inc assembler compatibility.Edward O'Callaghan
A comparison with a two's complement in gcccar.inc has dubious GAS/AT&T notation. Clang miss-parses 0x-1 as an invalid hexadecimal number. Change-Id: I88baa5c2513f062ff309df05916a3832b9bd9bb1 Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com> Reviewed-on: http://review.coreboot.org/5277 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-02-15coreboot: infrastructure for different ramstage loadersAaron Durbin
There are 2 methods currently available in coreboot to load ramstage from romstage: cbfs and vboot. The vboot path had to be explicitly enabled and code needed to be added to each chipset to support both. Additionally, many of the paths were duplicated between the two. An additional complication is the presence of having a relocatable ramstage which creates another path with duplication. To rectify this situation provide a common API through the use of a callback to load the ramstage. The rest of the existing logic to handle all the various cases is put in a common place. Change-Id: I5268ce70686cc0d121161a775c3a86ea38a4d8ae Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5087 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-02-15x86: provide stage_exit() like armAaron Durbin
The arm architectures have a stage_exit() function which takes a void * pointer as an entry point. Provide the same API for x86. This can make the booting paths less architecture-specific. Change-Id: I4ecfbf32f38f2e3817381b63e1f97e92654c5f97 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5086 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-02-11amd/cimx: fix sb(8|9)00 NULL type redefineAaron Durbin
It is inappropriate for chipset code to be redefining types -- especially NULL to a non-pointer type. There's only one non-straight forward change. A condition being checked was '!ptr_type == NULL' (0 as int). That check is actually 'ptr_type != NULL'. Change-Id: Iab5733e5a573baba6fec94e0c955ba4fad72c836 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5088 Tested-by: build bot (Jenkins) Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
2014-02-01AGESA f15tn: Fix GPP ports resumeRudolf Marek
The AGESA resumes the GPP ports in the romstage using FchInitResetGpp(), which does FchGppPortInitS3Phase() for S3 resume. The PreInitGppLink() looks into CMOS to figure out what ports to just force to Gen1 or Gen2 PCIe. Then boot continues and in the ramstage the rest of GPP init is executed. There is a problem that nobody sets properly the PortDetected flags in the S3 path. As the consequence FchGppDynamicPowerSaving() thinks the GPP port is not enabled and shut downs it. The best fix would be also to remove the CMOS dependency which might be some left over, because AGESA does not use CMOS much for anything else. There could be also some way how to pass the GPP state structure from romstage to ramstage possibly via hudson/resume.c but I don't know how to do that. Similar problem is that the "late" stage of init again "forgets" the PortDetected state. This fix fixes the resume issue on Asus F2A85-M. With this patch applied both GPP ports (used as PCIe x1 and internal ethernet) are working again after resume. Change-Id: Idaf609043abb09441c6790504d66d23e0637588f Signed-off-by: Rudolf Marek <r.marek@assembler.cz> Reviewed-on: http://review.coreboot.org/4671 Tested-by: build bot (Jenkins) Reviewed-by: Idwer Vollering <vidwer@gmail.com> Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
2014-01-30chromeos: provide option to identify reference code blobAaron Durbin
Certain platforms need to have reference code packaged and verified through vboot. Therefore, add this option. BUG=chrome-os-partner:22867 BRANCH=None TEST=Built. Change-Id: Iea4b96bcf334289edbc872a253614bb1bebe196a Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/180025 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/5022 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins)
2014-01-30vboot: provide empty vboot_verify_firmware()Aaron Durbin
In the case of CONFIG_VBOOT_VERIFY_FIRMWARE not being selected allow for calling vboot_verify_firmware() with an empty implementation. This allows for one not to clutter the source with ifdefs. BUG=chrome-os-partner:23249 BRANCH=None TEST=Built with a !CONFIG_VBOOT_VERIFY_FIRMWARE and non-guarded call to vboot_verify_firmware(). Change-Id: I72af717ede3c5d1db2a1f8e586fefcca82b191d5 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/172711 Reviewed-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: http://review.coreboot.org/4879 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-30VBOOT: Set virtual recovery switch based on EC Software SyncDuncan Laurie
The Virtual Recovery switch flag needs to be set in coreboot since it is passed through directly to VBOOT layer by depthcharge. Rather than add a new config option we can assume that devices with EC Software Sync also have a virtual recovery switch and set the flag appropriately. BUG=chrome-os-partner:25250 BRANCH=all TEST=build and boot on rambi, successfully enter developer mode Change-Id: Id067eacbc48bc25a86887bce8395fa3a9b85e9f2 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/183672 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/5061 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-28rmodule: consolidate rmodule stage loadingAaron Durbin
There are 3 places rmodule stages are loaded in the existing code: cbfs and 2 in vboot_wrapper. Much of the code is the same except for a few different cbmem entry ids. Instead provide a common implementation in the rmodule library itself. A structure named rmod_stage_load is introduced to manage the inputs and outputs from the new API. BUG=chrome-os-partner:22866 BRANCH=None TEST=Built and booted successfully. Change-Id: I146055005557e04164e95de4aae8a2bde8713131 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/174425 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: http://review.coreboot.org/4897 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Aaron Durbin <adurbin@google.com>
2014-01-28chromeos: include stddef to fix compilation errorAaron Durbin
As some of the standard definitions were shuffled around chromeos started failing to build. Correct this. Change-Id: I9927441ccb2d646e8b3395e6e9f8e8166de74ab0 Signed-off-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4844 Tested-by: build bot (Jenkins) Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
2014-01-12CBFS: use cbfs_get_file_content whenever possible rather than cbfs_get_fileVladimir Serbinenko
Number one reason to use cbfs_get_file was to get file length. With previous patch no more need for this. Change-Id: I330dda914d800c991757c5967b11963276ba9e00 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4674 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2014-01-12lib/cbfs_core.c: Supply size of file as well in cbfs_get_file_contentVladimir Serbinenko
Change-Id: I5b93e5321e470f19ad22ca2cfdb1ebf3b340b252 Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com> Reviewed-on: http://review.coreboot.org/4659 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-12-21chromeos: Check for recovery reason code in shared dataDuncan Laurie
When using RW firmware path the proper recovery reason can be retrieved from the shared data region. This will result in the actual reason being logged instead of the default "recovery button pressed" reason. 1) build and boot on falco 2) crossystem recovery_request=193 3) reboot into recovery mode, check reason with <TAB> 4) reboot back into chromeos 5) check event log entry for previous recovery mode: 25 | 2013-07-15 10:34:23 | Chrome OS Recovery Mode | Test from User Mode Change-Id: I6f9dfed501f06881e9cf4392724ad28b97521305 Signed-off-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/61906 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-on: http://review.coreboot.org/4368 Reviewed-by: Patrick Georgi <patrick@georgi-clan.de> Tested-by: build bot (Jenkins)
2013-12-07Correct file permissions.Idwer Vollering
Some files have incorrect/odd permissions, correct them: remove unnecessary +x flags. Change-Id: I784e6e599dfee88239f85bb58323aae9e40fb21c Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/4490 Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-12-07src/vendorcode/amd: remove Visual Studio remnants.Idwer Vollering
Delete files that (were overlooked and) are probably needed to build with Visual Studio. Remove doxygen helper files as well. Change-Id: I6b6cece178917ad9da1081eb6b1bb9be33066a77 Signed-off-by: Idwer Vollering <vidwer@gmail.com> Reviewed-on: http://review.coreboot.org/4489 Tested-by: build bot (Jenkins) Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com>
2013-12-05AMD IMC AGESA: Access the data in stack by correct lengthZheng Bao
The bug is hard to find. We were adding the feature of fan control. We met some strange things which could not be explained. Like, sometimes adding printk let the error disappear. Then we traced the code by hardware debug tool (HDT). It turned out the data in stack was overwritten. The values of AccessWidthxx are { AccessWidth8 = 1, AccessWidth16, AccessWidth32,} For the case of AccessWidth8, we only need to access the index/data once. But ReadECmsg and WriteECmsg did the loop twice, 1 more time than they are supposed to do. The data in stack next to "Value" would be overwritten. For all the cases, the code should be OpFlag = OpFlag & 0x7f; switch (OpFlag) { case 1: /* AccessWidth8 */ OpFlag = 0;break; case 2: /* AccessWidth16 */ OpFlag = 1;break; case 3: /* AccessWidth32 */ OpFlag = 3;break; case 4: /* AccessWidth64 */ OpFlag = 7;break; default: error; } Actually, the caller only takes AccessWidth8 as the parameter. We can ignore other cases for now. That is an AGESA bug. AMD's AGESA team own this code. They have given the response that they are going to update this in next release. I presume let them decide the proper way to fix that. Before that, I change the code as little as possible to make it run without crash. Change-Id: I566f74c242ce93f4569eedf69ca07d2fb7fb368d Signed-off-by: Zheng Bao <zheng.bao@amd.com> Signed-off-by: Zheng Bao <fishbaozi@gmail.com> Reviewed-on: http://review.coreboot.org/4297 Reviewed-by: Bruce Griffith <Bruce.Griffith@se-eng.com> Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net> Tested-by: build bot (Jenkins)
2013-12-04Add Intel FSP northbridge support Sandybridge and IvybridgeMarc Jones
Add support for Sandybridge and Ivybridge using the Intel FSP. The FSP is different enough to warrant its own source files. This source handle the majority of FSP interaction. "Intel® Firmware Support Package (Intel® FSP) provides key programming information for initializing Intel® silicon and can be easily integrated into a boot loader of the developer’s choice. It is easy to adopt, scalable to design, reduces time-to-market, and is economical to build." http://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html Change-Id: Ib879c6b0fbf2eb1cbf929a87f592df29ac48bcc5 Signed-off-by: Marc Jones <marc.jones@se-eng.com> Reviewed-on: http://review.coreboot.org/4015 Tested-by: build bot (Jenkins) Reviewed-by: Ronald G. Minnich <rminnich@gmail.com> Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>